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

Start with the component diagram. It establishes what pieces exist and who owns each one, before anything about behavior or payloads makes sense; architects can't reason about "what happens when" until they know "what's here."

Structured elaboration

1. Component diagram (what exists). Purpose: boundaries and ownership. Show: application services, cache cluster nodes, the source-of-truth database, an invalidation service, and a message broker. Leave off: exact protocol, message schema, and timing, those belong later.

2. Sequence diagram (what happens, in order). Purpose: the actual interaction for one invalidation event. Show: a write to the database, the database acknowledging it, an event published to the invalidation service, that service publishing an evict message on the broker, the broker fanning out to cache nodes, and one failure path (broker unavailable: what serves stale data, and for how long). Leave off: byte-level payload detail and retention settings, that's the next diagram's job.

3. Data-flow diagram (what exactly, and how stale). Purpose: payloads and guarantees. Show: the invalidation message's schema (key, version, timestamp), time-to-live, message size, and the one metric architects will actually watch, invalidation latency or staleness window. Leave off: anything already covered by the component-level framing.

Why this order helps comprehension: each diagram answers the question the previous one raised. Component diagram: "what is the invalidation service." Sequence diagram: "how does it know to fire." Data-flow diagram: "how stale can a read get before this evicts it." Reversing the order, starting with the sequence diagram, forces you to define every box mid-sentence instead of pointing at one the audience has already seen.

Worked example

The component diagram you'd draw first:

flowchart LR
    App[Application] -->|write| DB[(Database)]
    App -->|read| Cache[(Cache Cluster)]
    DB -->|change event| Invalidator[Invalidation Service]
    Invalidator -->|publish evict msg| Broker[[Message Broker]]
    Broker -->|fan out| Cache
    Cache -->|miss, reload| DB

Narrated: "The application writes to the database. That write triggers a change event to the invalidation service, which publishes an evict message on the broker. The broker fans that message out to every cache node, and the next read that misses reloads from the database."

Translating the core idea for the architects: the jargon term is "cache coherence." Plain version: "keeping the cache from serving an answer that's gone stale since the database changed." Analogy: it's like a library's card catalog. When a book gets re-shelved, someone has to walk over and update the card, or the next person who checks the card gets sent to the wrong shelf. Where the analogy breaks: no single librarian updates every card at once across a building, the fan-out to many cache nodes in parallel, possibly across regions, is exactly what makes this hard in practice, and that's the detail worth naming once the audience has the basic picture.

Trade-offs & pitfalls

The common wrong turn is leading with the sequence diagram because it feels more "technical," which forces you to define the invalidation service, the broker, and the cache cluster mid-sentence instead of pointing at boxes the audience already recognizes. A second pitfall: putting the failure path (broker down) in the component diagram instead of the sequence diagram, error paths are behavior over time and belong where the audience is already reasoning about timing. A third: overloading the data-flow diagram with architectural detail that duplicates the first diagram instead of adding new information (payload size, TTL, staleness), which makes the customer conversation feel repetitive rather than cumulative.

Direct answer

Technical debt is the cost of a shortcut: choosing a faster, less durable way to build something now, which leaves work behind that has to be paid off later, usually with interest in the form of slower future changes and more failures. Worth distinguishing from a plain bug up front: a bug is something simply broken; debt is something that works correctly today but was built in a way that makes tomorrow's changes slower or riskier. That distinction matters because a CFO will otherwise expect debt to be "fixed" the way a bug is fixed, in one pass.

Building the analogy and the cost picture, without turning this into a funding pitch

• The goal here is understanding, not approval. It's tempting to slide straight into a business case for a specific remediation plan; resist that. The job in this conversation is to make the trade-off legible so the CFO or product owner can weigh it, not to argue for a particular remediation budget.
• Pick an analogy with a genuine ongoing cost, not a one-time cost. Debt is the right family of analogy precisely because it compounds; a single "we cut a corner" story without a compounding element understates it.
• State the short-term and long-term costs as two honest lists in the same units the audience already uses (time to ship, and time or cost to change things later), not as a formal return-on-investment model with invented numbers. If real numbers aren't available, state the direction of the effect and let engineering supply an estimate separately.
• The same translate-to-one-line-of-business-impact move applies to smaller technical facts too: a dropping cache hit rate becomes "more requests are now hitting the slow path, which shows up as slower pages under load"; growing replication lag becomes "reports and dashboards can lag behind the live system by longer than before"; a feature flag left on for months becomes "we're running code in production that was meant to be temporary, and nobody is actively deciding whether it should still be there."

Worked example

Analogy: building out office space quickly by using cheap, unlabeled wiring to open the doors sooner. You can occupy the space right away, that's the short-term win. But every time you need to add an outlet or diagnose a flickering light, someone has to trace unlabeled wires by trial and error instead of reading a panel, and that gets slower and riskier every time you touch it, that's the debt compounding.

Short-term cost of accepting the debt (shipping now): none directly, that's the point, you get to market faster and start earning or learning sooner.

Long-term cost of accepting the debt: every future change in that area takes longer than it should, because someone has to understand the shortcut before safely building on top of it; the chance of an outage or defect in that area is higher, because the shortcut usually skipped tests or edge-case handling along with speed; and the eventual cost of paying it down is higher than paying it down now, because more code has since been built on top of the shortcut.

Short-term cost of paying it down now: the feature that would have shipped this sprint ships next sprint instead, the real and immediate trade-off, stated honestly rather than buried in a business case.

Long-term benefit of paying it down now: future changes in that area return to normal speed, and the failure risk drops back down, both of which the CFO can weigh against the delay just described.

Trade-offs and pitfalls

The debt analogy misleads in one specific way worth naming: financial debt has a fixed interest rate and a payment schedule you control; technical debt's "interest rate" is unpredictable and its due date is often whenever the next feature happens to touch that code, not a date the team chooses. Say that difference out loud, or the CFO will reasonably expect a fixed payoff schedule the way they would for a loan. The other pitfall is using this explanation as a wedge to argue for unlimited remediation budget, that's a different conversation, building the actual case and winning the argument for a specific spend, and doesn't belong here. The job in this conversation is making the shortcut and its ongoing cost visible; deciding how much to pay down, and when, is a separate, subsequent conversation.

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.

Direct answer

SLI, SLO, and SLA are three layers of the same idea, stated with increasing weight. An SLI (service level indicator) is what you actually measure. An SLO (service level objective) is the internal target you set for that measurement. An SLA (service level agreement) is the external promise, usually contractual, built on top of that target, with consequences if you miss it. In plain terms: the SLI is the speedometer, the SLO is the speed limit you've set for yourself, and the SLA is the speed limit you've promised a customer you won't exceed, with a penalty if you do.

Picking the example and the threshold

• Choose one measurable thing the executive already cares about, not an internal engineering metric they have no context for. "Percent of requests that succeed" beats a raw latency percentile for this audience, because success or failure needs no further explanation.
• State the SLO as a number deliberately below what looks achievable. This is the part executives most often misread: an SLO of 99.9% isn't "we're at 100% and slipping a little," it's a chosen buffer that leaves room to ship changes and absorb normal failures without over-investing in reliability nobody needs.
• The SLA number sits below the SLO, with a consequence attached, and that gap is itself worth explaining: it exists so that missing the internal target doesn't automatically mean breaking a customer promise.
• The same three-layer structure holds outside web services too, whether you're onboarding a new product manager on a team's SLOs for the first time or defining an SLI/SLO for a streaming data pipeline (there the SLI might be how stale the data is, instead of whether a request succeeded), the relationship between the three layers doesn't change, only what's being measured does.

Worked example

Say the team sets it up this way for a checkout API. SLI: percent of checkout requests that return successfully within two seconds. SLO: 99.9% of checkout requests meet that bar, measured over a rolling 30 days, the number engineering is held to internally. SLA: 99.5% of checkout requests meet that bar, measured monthly, written into the enterprise customer contract; falling below it triggers a service credit specified in the contract.

Business consequence of missing the SLA (say the month comes in at 99.3%): this is a contractual breach. The customer is owed the agreed credit, and depending on the contract, may have grounds to escalate or walk away. It's a direct, quantifiable cost and a trust hit that shows up outside engineering entirely.

Business consequence of exceeding the SLO (say the month comes in at 99.97% against a 99.9% target): this isn't a "consequence" in the SLA sense, it's a signal. Consistently beating the SLO by a wide margin means either the target is stale and could absorb more risk (ship faster, take on more ambitious changes), or the team is over-investing effort in reliability the product doesn't need. Either way it's a prompt to revisit the number, not something to report as a win on its own.

Trade-offs and pitfalls

The most common executive misunderstanding is treating the SLO as the promise, when the SLA is the promise and the SLO is the internal cushion above it. Say that gap out loud every time, or the SLO number will get quoted externally by mistake. The second pitfall is picking a metric that's technically correct but means nothing to the audience, an uptime percentage without saying what "down" costs the business, always translate the metric into what the customer actually experiences before attaching a number to it.