Explaining Technical Concepts to Non-Technical Audiences Questions

Direct answer

Translate the same underlying numbers into the currency each side actually spends: dollars and payback timing for the CFO, customer impact and mitigation for the customer success leader. Never invent a rosier set of facts for one room and a grimmer set for the other, that gap is what gets you caught later.

Structured elaboration

• Find the audience's real currency. The CFO spends in dollars, timelines, and risk-adjusted return. The customer success leader spends in churn risk, commitment exposure, and what they can tell a customer who asks "why is X delayed."
• State the trade-off once, plainly, before either framing. "Cutting cloud spend 15% costs us about a quarter of our normal feature throughput for one quarter." Say that sentence to both rooms; only what comes after it changes.
• Pair every ask with a mitigation, not just a number. Which features are protected, what customer success can say to a customer waiting on something specific.
• The same move generalizes. This exact discipline, name the technical mechanism once in plain words, then answer what it costs, saves, or risks in the listener's own terms, is what's behind a wide range of asks: a circuit-breaker elevator pitch, eventual consistency versus strong consistency explained in a sales conversation with a customer, defending a message-queue decision to a CTO, walking a buyer through your benchmarking methodology without the underlying statistics, a latency-versus-cost trade-off for a CFO, capability-versus-business-outcome framing, and translating a model's fairness or bias risk into business and legal-risk language for Legal and HR. All of them are the same two sentences: here's the mechanism in plain words, here's what it costs or saves you.

Worked example

Assume the team's cloud spend on this service is $200k/month ($2.4M/year). A 15% reduction saves $360k a year in recurring cost (2,400,000 x 0.15 = 360,000), and it keeps saving every year after, not just this quarter.

Assume the team normally ships about 20 story points per sprint, 6 sprints in a quarter, 120 points a quarter. A 25% velocity cut for one quarter means roughly 90 points shipped instead of 120, a 30-point gap that recovers once the quarter ends.

To the CFO: "This gets us $360k a year in recurring savings, an engineering change that effectively pays for itself within the first quarter. The cost is temporary: this quarter we ship about 30 story points less than our usual 120, then throughput returns to normal."

To the customer success leader: "For one quarter we're shipping roughly a quarter less feature work. Nothing customer-committed or SLA-bound moves, we're deferring lower-priority backlog items instead. Here's the specific list of what's protected, so if a customer asks about something they were promised, you have a direct answer."

Trade-offs & pitfalls

Don't let the CFO conversation slide from legibility into a persuasion pitch ("this is obviously worth it"). Your job here is to give them the real number and the real timeline and let them own the decision, not to sell it. Don't let the customer success framing hide the size of the cut behind vague reassurance ("don't worry, it'll be fine"), a specific list of what's protected and what's deferred is what actually reduces their anxiety, vagueness increases it. And watch the subtler trap: quoting a bigger savings number to the CFO than the actual velocity hit implies, or a smaller velocity hit to customer success than the CFO conversation implies, that inconsistency costs you credibility with both rooms the moment they compare notes.

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

A legend that actually gets used has as few visual dimensions as possible, and each one carries exactly one meaning. I standardize on a small vocabulary (shape means component type, color means one thing like trust boundary or environment, line style means one thing like sync versus async) and I put a short label next to any icon that could plausibly mean two different things, rather than trusting the icon to speak for itself.

Structured elaboration

I organize the legend around a few categories, each with one job:

• Icons and shapes for component type. Rectangle for a compute service, cylinder for a data store, cloud outline for an external managed service, diamond for a decision or manual approval point. Each icon carries a short label with the actual service name and owning team, so the shape alone never has to carry the full meaning.
• Color for exactly one dimension. I pick one axis, most often trust level or environment (for example, green for internal, blue for customer-facing, orange for third-party), and I do not let color also imply something else like risk or status. Color-only meaning also fails for colorblind readers, so every color-coded element gets a redundant label or pattern, not color alone.
• Boundaries and grouping. A solid rounded box marks a deployment or service boundary; swimlanes mark team ownership. Arrow style is reserved for data flow semantics only: solid for synchronous calls, dashed for asynchronous or event-driven calls.
• A visible version and owner on every diagram. Diagrams drift out of date silently unless the legend itself forces a last-updated date and an owner to appear on the page.

The test I apply to every symbol before it goes in the legend: could two people in the room (one from security, one from product) each read this icon and land on a different meaning? If yes, it needs an explicit label, not just a prettier icon.

Worked example

Two genuinely ambiguous elements and how the legend resolves them:

1. An envelope icon on a connecting line. Read literally, this could mean a message queue or an actual email being sent. The legend resolves it by banning the bare envelope icon: a queue is drawn as a cylinder labeled with the actual technology ("Queue: Kafka"), and an outbound email is drawn as an external cloud icon labeled with the provider ("Email: SES"). No icon is left to carry that distinction alone.
2. A blue-colored box. Under a naive scheme, blue could mean "public-facing" or just "this team's color." The legend fixes the meaning: blue is reserved for customer-facing surfaces only, and it is always paired with a solid rounded border for "public-facing service." If a service is public but sits behind a web application firewall, that gets an explicit shield icon added rather than a new color, because color is only allowed to encode the one dimension it was assigned.

Trade-offs and pitfalls

• A notation system with too many dimensions (shape, color, border weight, icon, badge) is worse than a smaller one, because nobody memorizes six conventions; they revert to guessing, which is exactly the ambiguity the legend was supposed to remove. I keep the total vocabulary small enough to fit on one printed page.
• A legend that lives in a separate document from the diagrams decays fast: people update the diagram and forget the legend exists. Embedding the legend on the diagram itself, or enforcing it through a shared template in the diagramming tool, costs more up front but is the only version that survives six months of edits.
• Documenting a convention is not the same as enforcing it. Without a lightweight check (a template default, or a reviewer checklist item on architecture PRs), individual authors will quietly invent their own shorthand, and the legend becomes aspirational rather than actual.
• The legend has to match what the team's actual tool can render. A convention built for draw.io's rich icon set will not survive a move to Mermaid or another text-based diagram tool with a much smaller icon vocabulary, so the notation should be designed around the tool people will really use day to day.

Direct answer

State the facts plainly and completely before any interpretation: what was exposed, how many users, how you know, and what's already been done. Then translate the consequence into each listener's terms, evidence and notification-relevant facts for Legal, cost and exposure for the CFO, resisting both minimizing language and alarmist language on the way there.

Structured elaboration

• Separate three layers, and don't blend them. (1) What happened: plain facts, no jargon ("a bug let some users see another user's email address," not "an IDOR in the batch-export endpoint"). (2) What it means: the legal and business exposure. (3) What's being done: remediation and timeline.
• Calibrate tone with precision, not adjectives. Neither "minor issue" (minimizing) nor "major breach" (panic-inducing) does the job; exact scope numbers do: how many users, which field, how you found it, whether you have evidence of external access.
• Give Legal the facts, not your guess at the legal conclusion. Whether this triggers a mandatory breach notification is their call once they have the exact scope; stating it as settled either way (in either direction) oversteps and can be wrong.
• Give the CFO honest uncertainty where it exists. Quantify remediation cost and effort, which you know. If downstream revenue or reputational exposure isn't defensibly knowable yet, say that directly rather than attach a number to make the room feel more informed than it is.
• The same three-layer discipline scales to a bigger stakeholder list. It's what a cascading-outage incident commander delivers to the CEO, support, legal, enterprise customers, and the public, the same facts, layered the same way, at different depth and formality for each. And it's the same shape whether the trigger is an active exposure or a not-yet-exploited security-patch risk being explained to the CFO and Legal before a fix ships.

Worked example

"Here's what we know. A bug in the account-export feature let a user see another user's email address under a specific, narrow condition. We've confirmed it affects up to about 1,200 accounts out of 400,000 total, roughly 0.3%. We found this through an internal security review, not an external report. We shipped a fix that closes the access path as of this morning, and we're now confirming whether any of those 1,200 accounts were actually viewed, versus just technically exposed. We have no evidence right now of the data leaving our systems.

Legal, I want to hand you the exact scope now so you can make the notification call, I'm not going to guess at the compliance answer here.

Finance, at this stage the remediation itself is about three engineer-days, already done. I don't yet have a defensible number for downstream cost or churn risk, and I'd rather tell you that plainly than invent one to fill the silence."

Trade-offs & pitfalls

The question names both failure directions on purpose: minimizing (soft-pedaling the scope to avoid alarm) destroys credibility the moment the real scope surfaces later, and panic-inducing framing (over-scoping before you have facts) can trigger costly, premature actions that turn out to be wrong. A related pitfall is attaching an invented multiplier or estimate to reputational or revenue exposure just to hand the room a number, once said out loud, that number gets repeated as fact even with a caveat attached. The better move, and the harder one, is to give the real scope with full confidence and the downstream cost with honest uncertainty, in the same conversation. Finally, don't let Legal's need for a precise, defensible scope slow down sharing the facts with Finance, the scope statement doesn't have to wait for the legal conclusion.