Explaining Technical Concepts to Non-Technical Audiences Questions

Direct answer
Show one or two numbers translated into what the audience already cares about, fewer bad customer experiences, fewer 2am pages, not the underlying metrics list, back it with a single before/after visual, and close with a specific, sized ask for the next investment.

Structured elaboration

• Choosing what to show: pick the metrics that map directly to something the audience already tracks. Uptime becomes "hours the product was down"; incident count becomes "how many times we paged someone at 2am." Skip metrics that only make sense to an on-call engineer, like error budget burn rate or MTTA, unless someone asks.
• One visual, not a dashboard: a single before/after chart, thirty days before versus thirty days after, beats a full panel of graphs. If a reader can describe the chart back to you in one sentence, it did its job.
• Translating a percentile into a story: a jump from 99.85% to 99.95% uptime means little to most people on its own; translating it into a countable unit, about 43 fewer minutes of downtime over a 30-day month, makes it real.
• Making the case for the next investment: state specifically what you'd do next, what it costs in time or headcount, and what change you'd expect, in the same countable terms as the result above, not a vague request to "invest more in reliability."

Worked example

• Jargon: "MTTR dropped and p99 latency improved after we added automated retries and better alerting."
• Plain: "When something breaks now, we typically fix it in well under half the time it used to take, because the system retries automatically and pages the right person immediately instead of waiting for a customer to report it."
• Analogy: like a smoke detector that used to only work if someone smelled smoke and called it in, it now alerts the fire department directly the moment it detects smoke.
• Where it breaks: if someone asks whether outages don't happen anymore, the honest answer is no, they're caught and fixed faster, but a genuinely new kind of failure could still take as long to diagnose as before, since the improvement is in response speed for known failure patterns, not in problems that haven't happened yet.

The ask, kept concrete: "Extending the same automatic retry logic to two more services would take about three weeks and, based on how often those services fail today, should produce a similar drop in response time there."

Trade-offs and pitfalls
Leading with the full metrics dashboard, uptime, error budget, MTTR, MTTA, latency percentiles, overwhelms a non-technical audience and buries the one number they'd actually remember. Translating a number into a countable unit is honest only if you also say what it doesn't cover, claiming reliability is solved after one good month invites a credibility hit the next time something breaks. An ask framed as "invest more in reliability" is too vague to get funded, size it the same way you sized the result.

Direct answer
State the headline first: the dashboard needs six more weeks before its numbers can be trusted. Explain the risk of shipping early in terms of a decision it could cause someone to get wrong, not a data-engineering term, and offer a real, honestly-labeled interim option so the conversation isn't just "no."

Structured elaboration

• Order: what's happening, why it matters, what you're doing about it, then what you need from them, kept in that order so the audience isn't left waiting through a long explanation before they hear the ask.
• Translating "why": name the consequence a decision-maker would recognize, not the technical cause. Instead of "schema drift and incomplete backfill," say what it does to the number they'd actually look at.
• Where jargon quietly comes back: delay explanations often smuggle in credibility-through-jargon ("we need to run reconciliation and backfill jobs"). Replace every technical noun with what it does to the number on the dashboard.
• Offer a real trade-off: a scoped, honestly-labeled interim version versus the full wait, so the audience has an actual choice instead of just a delay.

Worked example

• Jargon: "The pipeline has schema drift and incomplete backfill, so metrics are currently unreliable until we run reconciliation."
• Plain: "If you refreshed this dashboard twice in the same hour right now, some numbers could show different totals for the same day, because the system feeding it hasn't finished catching up on older data yet."
• Analogy: like a bank statement that still has pending transactions on it, the total looks final but a few charges haven't posted, and it changes if you check again tomorrow.
• Where it breaks: if leadership asks whether today's number is wrong or just recent numbers, the honest answer is that recent days are most affected while older months are mostly stable already, that's more precise than the analogy alone conveys, so say it directly rather than letting the analogy imply everything is unreliable.

The concrete interim offer: "I can turn the dashboard on today with a clear 'preview, not for decisions' label covering just [one segment], while we finish the rest over the next six weeks."

Trade-offs and pitfalls
Softening "the numbers could be wrong" into "the numbers may need refinement" invites leadership to ship anyway, having heard reassurance instead of risk, state the concrete cost of shipping early instead. An interim option is good practice only if it's honestly labeled, quietly shipping a rough version without the caveat defeats the whole conversation. Don't bury the ask at the end of a long explanation, state it early too, so the audience knows what decision they're actually being asked to make.

Direct answer

Encryption in transit protects data while it is moving between two points, for example your laptop and a website. Encryption at rest protects data while it is sitting in storage, for example on a server's hard drive. Both work the same basic way: the data is scrambled using a digital key, and only someone with the matching key can unscramble it back to something readable. HTTPS (the lock icon in a browser) is the everyday example of encryption in transit; a company laptop or database with disk encryption turned on is the everyday example of encryption at rest.

Structured elaboration

When I explain this to a stakeholder who is not technical, I make three deliberate choices:

1. Pick an analogy that survives the obvious follow-up question. "Scrambling data" invites "how do you unscramble it back?" so I go straight to a locked box with a key: the box (the data) can sit on a shelf (at rest) or travel in a delivery truck (in transit), and either way, only someone holding the matching key can open it. This analogy already answers the natural next question ("who has the key?") instead of dodging it.
2. Decide what to omit, not just simplify. I leave out algorithm names, protocol versions, and how the encryption keys themselves are generated and stored. Those details do not change the stakeholder's decision (do we need this, is it enough for compliance). What I keep is the one thing that matters to them: even if someone steals the disk or intercepts the network traffic, they get scrambled data they cannot use without the key.
3. Check understanding without quizzing them. Instead of asking "does that make sense?" (which invites a reflexive yes), I ask them to restate it in their own words, or pose a concrete scenario: "if someone stole this laptop from a parked car, what would they actually get?" Their answer tells me whether the concept landed.

Worked example

Here is close to what I would actually say:

"Think of our data like paperwork in a locked filing cabinet. 'Encryption at rest' means the paperwork sitting in that cabinet, meaning on our servers or backups, is written in a code that only a specific key can decode. If someone breaks into the building and steals the cabinet, they walk away with pages of gibberish. 'Encryption in transit' is the same idea for paperwork that is being carried from one office to another, meaning data moving between your browser and our servers. The little padlock icon you see next to a website address means that trip is protected the same way: even if someone intercepts the envelope mid-delivery, they cannot read what is inside. In both cases the 'key' is just a digital code that locks and unlocks the data. We keep that key separate from the data itself and tightly restrict who can use it, the same way you would not tape the safe combination to the safe."

If they ask a follow-up like "so is our data safe no matter what," that is the moment to add the caveat below rather than let the analogy imply more than it should.

Trade-offs and pitfalls

• The locked-box analogy breaks down around key management: a real safe has one physical key, but a digital key can be copied, and who is allowed to use it (and how that is audited) matters as much as the encryption itself. If the stakeholder is making a security or compliance decision, that caveat has to come back in, even though it complicates the clean story.
• Oversimplifying to "it's encrypted so it's safe" can create false assurance. Encryption at rest does not protect data while an application has it decrypted in memory for processing, and encryption in transit does not protect against someone who is logged in as an authorized user misusing their access. Naming that boundary once, briefly, is worth the extra sentence.
• Dropping all technical vocabulary can cost credibility with a stakeholder who has picked up some of it (for example, someone who has heard the term TLS from a vendor). It is fine to mention the term once, defined in one plain clause ("TLS, the technology behind that browser padlock"), so the explanation still connects to language they may encounter elsewhere.

Direct answer
Structure the twenty minutes like a news report, not a technical timeline: lead with impact and current status, spend the middle explaining just enough of what happened to justify the decisions made, and close with the plan and a specific ask. Technical detail should increase only where it's needed to justify a decision, not to demonstrate the incident was understood.

Structured elaboration

• Opening, impact first: state what broke in terms of what customers or the business experienced, the duration, and current status, in one or two sentences, no jargon.
• Middle, level up only enough to justify the fix: technical detail earns its place here only if it explains why a particular fix was necessary. Naming that a traffic spike overwhelmed one internal service does that job; a deeper mechanism only belongs here if someone needs it to trust the fix.
• Close, asks not minutiae: a short remediation roadmap and any resourcing ask, framed as a decision the room needs to make, not a list of engineering tasks.
• Check the room mid-talk, not just at the end: right after the technical middle section is a natural point to ask "does the cause make sense, or should I back up," rather than waiting until the close.

Worked example

• Jargon: "A recent deploy removed our circuit breaker on the checkout service, so when a downstream dependency slowed down, requests piled up and exhausted our connection pool."
• Plain: "A recent code change accidentally removed a safety switch that normally stops checkout from waiting forever on a slow part of the system. When that slow part had a bad few minutes, checkout kept waiting instead of failing fast, and eventually ran out of room to handle new requests, so customers started seeing errors instead of a slow page."
• Analogy: like a phone line with no busy signal, calls kept queuing instead of getting a fast callback-later, until every line was full and even new callers couldn't get through.
• Where it breaks: if a PM asks whether this happens again the moment something else is slow, the honest answer is that the safety switch is being restored and alerting added, so this specific failure mode is closing, but a different slow dependency in the future could still cause a similar issue if it isn't covered by the same protection. Don't let the analogy imply the whole system is now bulletproof.

Trade-offs and pitfalls
Spending the first five minutes on the technical cause before stating impact loses the room, people tune out or panic before they know how bad it was. Over-explaining the middle section to prove technical rigor tends to read as covering for something; only the detail that justifies the fix belongs there. Ending with a list of engineering tasks instead of a stated ask leaves the room without a clear next action.

Direct answer

Running two active data centres means duplicating the infrastructure that serves users, so if one site fails, the other keeps serving with little to no interruption. That duplication raises fixed costs (hardware, networking, and the ongoing work of keeping both sites synchronized and tested), in exchange for far less user-visible downtime, because a failure that would take a single-site setup fully offline gets absorbed by the second site instead.

Structured elaboration

• Define the trade-off in plain terms first, before any numbers: it is duplicated cost bought to avoid duplicated failure. "Availability" here just means the percentage of the year the service was actually reachable.
• Make the trade-off concrete with a numeric example (below), because "increases cost but reduces downtime" is true of almost any resilience investment and doesn't help leadership decide if this specific one is worth it.
• Note diminishing returns. Going from a single site to two active sites buys a large downtime reduction for a moderate cost increase. Pushing further, from four nines to five nines, typically costs disproportionately more for a much smaller absolute gain, so the decision should track business impact per minute, not availability percentage for its own sake.
• Two format variants worth knowing. The same numeric framing works as a short memo to executives requesting an SLO increase: state the change and its downtime-and-dollar consequence in the first two sentences, then put the derivation below as supporting detail. It also works, largely unchanged, when the audience is an external client evaluating your reliability commitments rather than internal leadership, the difference is that you're now translating into an SLA commitment they can hold you to, not just an internal budget ask.

Worked example

Say a single data centre gets the service to 99.9% availability. A year has 525,600 minutes, so the downtime is 525,600 x (1 - 0.999) = 526 minutes a year (about 8.75 hours), at a cost of $1.0M a year.

A second active site raises availability to 99.99%: 525,600 x (1 - 0.9999) = 53 minutes a year, at a cost of $1.6M a year.

That's 526 - 53 = 473 minutes of downtime avoided for an extra $600k a year, or about $1,270 for every minute of downtime avoided (600,000 / 473 ≈ 1,270). Leadership can weigh that against what a minute of downtime actually costs the business (lost revenue, support load, customer trust) to judge if the trade is worth it.

When business and engineering are in the same room (a consistency-model version of this same trade-off), layer the explanation instead of picking one level: open with the plain-language framing everyone can hold ("does an update show up everywhere instantly, or does it catch up a moment later"), then, once that lands, add one sentence naming the actual mechanism for the engineers in the room, eventual consistency versus strong consistency, so nobody is bored or lost at the same time.

Trade-offs & pitfalls

The cost-per-minute figure is a useful summary, but it's a simplification: not all minutes cost the same (an outage during checkout hours costs far more than one at 3am), and the model should say so rather than imply a flat rate. A second pitfall: two data centres do not eliminate all downtime, correlated failures (a bad config pushed to both sites, a shared upstream dependency) can take both down together, so "two sites" is risk reduction, not risk elimination, and that caveat belongs in the leadership conversation, not just the postmortem.