Why This Competency Matters

Communicating-to-non-technical questions are deceptively easy to fail. On the surface they invite the candidate to talk about an explanation they gave to a PM or executive, which most engineers have done. Underneath, the rubric is grading something quite specific: whether the candidate can put the listener's question first and the candidate's technical interest second, and whether the candidate can hold the line between simplification and distortion.

Three signals dominate strong communicating-to-non-technical answers:

[ Audience first ]      Did the explanation start from the listener's question, not the candidate's interesting detail?
[ Calibrated abstraction ]  Did the candidate find the right level of abstraction for the audience and the decision?
[ Trade-off surfaced ]  Did the candidate name the choice the listener had to make, not just the technology?

The failure mode that dominates weak answers is the deep-dive reflex. The candidate, asked about an explanation they gave, retells the technical content of the explanation: 'I explained how the caching layer worked, then I explained how the consistency model worked, then I explained how the failover worked.' The interviewer hears technical depth, but the rubric is grading whether the listener walked away able to make the decision they came in with, and the deep-dive answer rarely shows that.

The other failure mode is over-simplification that becomes inaccurate. The candidate, trying to make the explanation accessible, removes so much of the structure that the resulting model would lead the listener to a wrong decision. Over-simplifying to the point of distortion is worse than not simplifying at all, because the listener now has confidence in a model that is wrong.

The strong communicating-to-non-technical answer demonstrates three things together: a starting frame anchored in what the listener cares about, a deliberate abstraction level chosen for the decision at hand, and an honest representation of the trade-off without losing the structure that makes the trade-off real. The lesson below covers each of these in turn, the abstraction ladder for moving up and down levels of detail, the discipline of trade-off-not-deep-dive, when over-simplifying becomes lying, and the patterns that distinguish written from verbal explanations.

What Great Looks Like

Strong communicating-to-non-technical answers tend to score on five named rubric signals.

1. The opening frames the listener's question, not the technology.

The candidate does not start by describing the system; the candidate starts by naming the question the listener walked in with. 'The PM came to me asking whether we could ship the personalisation feature in the same quarter as the migration. The honest answer was no, but the more useful version was a calibrated yes-with-conditions, and the conversation needed to surface the conditions.' Strong openings read as listener-first; weak openings read as system-first.

2. The abstraction level matches the decision the listener has to make.

The candidate picks the level of detail deliberately, not by default. For a CFO deciding on funding, the right level is dollars and incidents. For a PM deciding on scope, the right level is which features are at risk and why. For a designer deciding on UX flow, the right level is what the latency profile feels like, not how the latency is produced. Strong answers name the level the candidate chose and why; weak answers default to the candidate's natural depth.

3. The trade-off is named explicitly.

The candidate surfaces the choice the listener has to make: 'we can ship in four weeks with the caching shortcut, which is faster but means we will pay it back in two quarters; or we can ship in seven weeks with the proper indexing change, which is slower now but does not accrue debt.' Strong answers make the trade-off visible enough that the listener can choose; weak answers describe the technology without surfacing the choice.

4. Concrete-before-abstract is the default direction.

The candidate leads with a concrete example, then generalises if needed. 'When a user clicks search, our service has to call three downstream APIs, and one of them takes about 800ms. That is why the page feels slow.' The concrete example anchors the listener's understanding; the abstraction comes after, only if the listener needs it. Strong answers earn the abstraction by leading with the concrete; weak answers start abstract and lose the listener.

5. The listener's takeaway is named at the end.

The candidate closes by stating, in plain language, what the listener should now know or do. 'So the recommendation is option B, with the caveat that we will need an extra week if the latency budget moves.' The closing takeaway is what makes the explanation useful as a decision input rather than as a lecture.

At senior levels (staff and above), a sixth signal often shows up: the candidate names what they chose to leave out and why. 'I did not get into the details of the consistency model because the decision did not depend on it; if it had, I would have walked through it.' Naming the omission signals that the candidate has thought about the abstraction choice deliberately, not just compressed by accident.

The Abstraction Ladder

The most useful single frame for this competency is the abstraction ladder. The ladder has four rungs, and strong communicators move up and down it deliberately based on the audience and the decision.

[ Rung 1 ]   Concrete example  ('When a user clicks search, the page takes 2.3s before results show up.')
[ Rung 2 ]   Abstraction       ('The bottleneck is the downstream API that ranks results.')
[ Rung 3 ]   Diagram or model  ('Here is the request path; the slow step is highlighted.')
[ Rung 4 ]   Analogy           ('Think of it like a librarian who has to check every shelf before answering.')

Rung 1 is where most explanations should start. A concrete example grounds the listener in something they can picture. The example should use the listener's vocabulary (search, page, results) rather than the candidate's vocabulary (request path, latency budget, p99). Rung 1 is universally accessible.

Rung 2 generalises from the example. After the listener understands the concrete case, the abstraction names the pattern: 'The bottleneck is the ranking step, and it shows up everywhere we use ranked results.' Rung 2 is where the listener begins to be able to apply the explanation to other cases.

Rung 3 introduces a diagram or a structural model when the explanation has more than one moving part. Diagrams should be designed for the audience, not lifted from a design doc. For an executive, a diagram should have three or four boxes; for a PM, it can have five or six; for an engineering peer, it can have ten. The discipline is that the diagram has only the boxes the listener needs to make the decision.

Rung 4 is analogy. Analogies are powerful but expensive: a good analogy makes a hard concept click instantly, but a bad analogy commits the listener to a wrong mental model that is hard to dislodge later. Strong communicators use analogy sparingly and pick analogies that hold under the kinds of questions the listener is likely to ask. The librarian analogy holds for ranked search; it breaks down for streaming inference. The analogy has to fit the decision, not just the concept.

The practical guidance: start at rung 1, move up only as the explanation requires, and pick the rung that matches the decision. Most non-technical explanations live on rungs 1 and 2; rungs 3 and 4 are tools for specific situations.

Trade-Off-Not-Deep-Dive

The single most senior-level move in this competency is the discipline of surfacing the trade-off rather than deep-diving into the technology.

When a non-technical stakeholder asks a technical question, they almost always have a decision behind the question. The CFO asking 'why does this need 300K of headcount' is not asking for an org chart; they are asking whether the spend is justified. The PM asking 'why is the page slow' is not asking for a latency breakdown; they are asking whether to push for the fix this quarter. The designer asking 'why does the loading state look like that' is not asking about React rendering; they are asking how to design around the latency.

The deep-dive reflex answers the question literally: the candidate explains the org chart, the latency breakdown, the rendering model. The trade-off-not-deep-dive move answers the underlying decision: 'the spend is justified because the alternative is to keep paying $1.2M a year in incident response,' 'the page is slow because of a downstream API we do not control, so the fix this quarter would be to redesign the loading flow rather than the latency,' 'the loading state can be designed to hide the latency, here are two patterns that work.'

The trade-off framing has three parts:

• What are the options. Usually two or three; if the candidate names ten, the listener cannot choose.
• What changes between them. Cost, time, risk, scope, debt. The listener needs the axis on which the options differ.
• What is the recommendation, with the reason. The candidate names a recommendation; if asked for it, the candidate has thought about it. Naming the recommendation is the move that converts an explanation into a decision input.

Strong candidates default to the trade-off frame even when the listener has not explicitly asked for it, because the trade-off frame is almost always what the listener actually needs. Weak candidates wait for the listener to ask for a recommendation, by which point the conversation has often consumed the time budget on the deep-dive instead.

When Over-Simplifying Becomes Lying

A harder discipline is the line between simplification and distortion. Simplification removes detail to make the model accessible; distortion removes structure that the listener needs to make a correct decision. The line matters because a distorted model gives the listener confidence in a wrong direction, which is worse than no model at all.

Three common ways simplification crosses into distortion:

• Dropping a constraint that changes the decision. 'It is just a configuration change' when in fact the configuration change requires a database migration that takes a weekend window. The listener now thinks the work is small; they are wrong.
• Collapsing a probabilistic outcome into a deterministic one. 'The cache will fix the latency' when in fact the cache will fix the latency for hot keys but not cold keys. The listener now expects a guarantee; they will be surprised in three months.
• Removing a dependency that is load-bearing for the recommendation. 'We can do this in the platform team' when in fact it requires a contract change with the data team that has not happened yet. The listener now thinks the work is unblocked; it is not.

The discipline: when simplifying, ask whether the listener could make a correct decision with the simplified model. If yes, the simplification is fair. If no, the simplification has crossed into distortion and needs to be expanded enough to restore the structure the decision requires.

The phrasing strong candidates use to mark the boundary: 'I am simplifying here; the underlying behaviour is more nuanced, but the nuance does not change the decision in front of us.' Or: 'I want to flag a complication: the cache fix works for the hot keys but not the cold keys, which means we need a second piece of work to cover that case.' Naming the simplification, or naming the structure that has to stay in even if simplification is the goal, is the move that keeps the explanation honest.

Written vs Verbal Patterns

Written and verbal explanations have different mechanics, and senior candidates know which patterns to deploy where.

Verbal explanations are turn-based. The listener can ask questions in real time; the candidate can read the room and adjust. The structure that works:

• Open with the listener's question, restated in their language.
• Lead with a concrete example (rung 1).
• Move up the ladder only if the listener's questions pull you there.
• Close with the trade-off and recommendation.
• Total time: usually two to three minutes for the initial explanation, then question-driven.

Written explanations are one-shot. The reader cannot ask questions; the candidate cannot read the room. The structure that works:

• A one-line summary at the top stating the recommendation and the cost.
• A short context paragraph (three to five lines) framing the question.
• The trade-off, with the options and what differs between them.
• The recommendation, with the reason.
• An appendix with the technical detail the candidate chose to leave out of the body.

The one-page exec memo is the canonical written form. The discipline of the one-pager is that the recommendation, the cost, and the reason all fit in the first paragraph the executive reads; the technical detail goes in an appendix the executive may or may not read. The one-pager is a forcing function: if the recommendation cannot be stated in two lines, the candidate has not yet decided what they are recommending.

At senior levels, the candidate is increasingly responsible for the written form. A staff engineer who can produce a clear one-pager that an executive reads and acts on is producing leverage that compounds; a staff engineer who can only produce design docs is producing artefacts that lose the conversation upstream of the technical decision.

Common Questions & Model Answers

The five prompts below cover roughly 95% of how this competency is probed. Each model answer is a two-minute STAR answer that scores on the rubric above.

Prompt 1: 'Tell me about a time you explained a technical concept to a non-technical stakeholder.'

Model answer (strong, audience-first framing with explicit trade-off)

'About a year ago our PM came to me asking why the search-results page felt slow on mobile. The product team had been debating whether to invest in a redesign of the loading state or push the engineering team to fix the latency. They needed a recommendation, not a latency breakdown.

I started by reframing the question in her language. The page felt slow because the ranking call took about 800ms on mobile networks; the page itself rendered in under 100ms once the ranking returned. So the bottleneck was a single downstream call we did not own, and the fix had two paths: change the call (slow, took two quarters and required negotiation with the ranking team) or change the experience around the call (fast, could ship in two sprints, would not move the actual latency but would change how the latency felt).

I drew her a four-box diagram on the whiteboard: user clicks, request goes out, ranking call (highlighted), results render. The diagram had four boxes, not the ten boxes our internal design doc had, because she did not need the ten. She asked two questions, both about whether the ranking team would prioritise the change; I had pre-empted both because I had spoken to the ranking lead before the meeting.

I closed with a recommendation: ship the loading-state redesign this quarter (fast, low-cost, addresses the perception), and put the ranking-team conversation on the roadmap for next quarter (slow, higher cost, addresses the underlying latency). The PM took the recommendation; the loading-state redesign shipped in six weeks and moved the perceived-latency NPS by 8 points.

What I learned. The PM did not need the latency breakdown; she needed the choice. Leading with the choice rather than the technology made the conversation about 15 minutes long instead of 45, and produced a clean decision instead of a deferred one.'

What lands: opening framed in the listener's question (why does the page feel slow), abstraction calibrated to the decision (four-box diagram, not ten), trade-off surfaced explicitly (two paths with cost and time on each), concrete recommendation, observable output (loading-state redesign shipped, NPS moved by 8 points), and a generalisable lesson about leading with the choice.

Prompt 2: 'Walk me through a difficult technical communication.'

Model answer (strong, calibrated explanation under disagreement)

'About 18 months ago I had to explain to our head of customer success why we could not turn on a feature for a customer who had been promised it. The customer was a six-figure account; the feature was an integration with their authentication provider; the engineering reality was that turning it on without the right rate-limiting would have caused a cascading failure across our auth service for all customers.

The head of CS was upset, reasonably; she had been on the customer call where the promise was made, and she was looking at a relationship she would have to manage backwards. The temptation was to defend engineering by deep-diving into the rate-limiting model. I did not do that.

Instead I framed it as a calibrated risk question. I said: if we turn this on today, there is roughly a 30% chance we cause a 30-minute outage for all auth users in the next two weeks, because the rate-limiting on the integration cannot handle the customer's burst pattern. If we delay it by three weeks, we can ship the rate-limiting fix and the risk drops to under 1%. The choice was not between the customer being happy and the customer being unhappy; it was between a 30% chance of a much bigger problem and a three-week delay we could explain.

I named the simplification: I said the 30% number was a rough estimate, not a measured probability, and that I was confident in the order of magnitude rather than the exact figure. I did not pretend it was precise.

She pushed back on the three weeks. We talked through whether we could ship a partial enablement (the customer's read traffic but not their write traffic, which had the burst pattern) in one week. I had not pre-considered that option; we walked it through together and concluded it would work. The customer got partial enablement in eight days and full enablement in three weeks.

What I learned. The hard communication was not the technical explanation; it was the framing of the choice. The head of CS did not need the rate-limiting model; she needed the risk arithmetic in language that let her decide. The 30% language was a deliberate choice; if I had said 'the system might fail under load' she would not have been able to weigh the choice against the customer relationship.'

What lands: difficult communication framed as a choice rather than a defence, abstraction calibrated to the decision (probability language rather than rate-limiting model), explicit naming of the simplification (the 30% is rough), responsiveness to the listener (the partial-enablement option emerged from her pushback), and a clean output (eight-day partial, three-week full).

Prompt 3: 'Describe simplifying a complex topic for an executive.'

Model answer (strong, executive-level abstraction with appendix discipline)

'About a year ago our VP of engineering asked me to write a one-pager for the CTO on whether we should adopt a new internal data platform that the platform team was building. The decision was load-bearing for our team's roadmap; the technical detail was substantial, and the CTO had about ten minutes to read.

I started by deciding what the CTO needed to walk away with. He needed to know whether to fund the migration, what the cost was, and what the risk was if we did not migrate. He did not need the architecture; he needed the decision.

The one-pager opened with a two-line recommendation: migrate over the next two quarters, at a cost of approximately one engineer-quarter of effort and a month of feature-freeze in the third sprint, with the alternative being approximately $400K of additional infrastructure spend over the next year if we stayed on the legacy stack. Those two lines were the load-bearing content; everything else was supporting.

The body had three sections: the cost (one engineer-quarter, named milestones), the risk (one named risk: the schema migration was a one-way door), and the alternative (the $400K number, with a footnote on the calculation). Total body: about 350 words.

The appendix had the technical detail: the architecture diagram, the comparison table of features, the migration sequence. The appendix was for the CTO to look at if he wanted; the body was complete without it.

The CTO read the one-pager, asked one question (whether the schema-migration risk could be reduced with a feature-flag approach), and approved the migration. The migration shipped on the two-quarter timeline; the $400K alternative cost was the right order of magnitude, which we were able to confirm two quarters later.

What I learned about the one-pager form. The discipline of the two-line opener is what forced me to decide what the recommendation actually was. If I had not been able to fit it in two lines, I would have known I had not yet decided. The appendix is also a discipline: it is the place where the technical detail goes that I want to be available but do not need the executive to read.'

What lands: explicit framing of what the executive needed to decide, calibrated abstraction in the body (cost, risk, alternative, with the appendix carrying the detail), the discipline of the two-line opener as a forcing function, observable output (CTO approved, migration shipped, alternative cost confirmed), and a transferable lesson about the form.

Prompt 4: 'Tell me about communicating bad technical news to a customer or PM.'

Model answer (strong, honest delivery with options)

'About six months ago I had to tell our PM that the feature he had committed to a customer was going to slip by three weeks because of a constraint we had missed in design review. The miss was real; we had underestimated the work to integrate with the customer's identity provider, and the gap surfaced in the second sprint.

The temptation was to soften the news with technical language. I did not do that. I opened with the headline: the feature was going to ship three weeks later than the date we had given the customer, the cause was a design-review miss on the identity-provider integration, and the question was how we wanted to communicate the slip to the customer.

I had three options ready. Option one: tell the customer about the slip immediately, accept the relationship cost, and use the three weeks to build the feature properly. Option two: ship a stripped-down version on the original date (without the identity-provider integration, which the customer would have to set up manually), then ship the full version three weeks later. Option three: hold the news until we had the full version ready, ship two weeks late, and frame it as a polish delay. I had a recommendation (option two) but I named the trade-offs on each.

The PM asked two questions: whether option two would work for the customer's launch timeline (yes, with the manual setup), and whether option two would damage the relationship (less than option one, more than option three; I was honest about the uncertainty). He chose option two.

The communication to the customer happened that afternoon. The customer accepted the partial version, set up the integration manually, and the full version shipped on day 21 of the slip. The relationship was bruised but not damaged; the PM told me afterwards that the explicit options had made the conversation with the customer much easier.

What I learned about delivering bad news. The headline first is the discipline; if I had buried the slip three paragraphs into the explanation, the PM would have spent the conversation looking for it. The options are what convert bad news into a workable conversation; without them, the conversation is just bad news.'

What lands: bad news delivered headline-first without softening, three concrete options with named trade-offs, a stated recommendation with calibrated uncertainty, listener-responsiveness (the PM's two questions), observable output (option two shipped on day 21, relationship preserved), and a generalisable practice (headline first, options always).

Prompt 5 (weak / contrast answer): 'Tell me about a time you explained a technical concept to a non-technical stakeholder.'

Weak answer (deep-dive reflex, no listener framing, no trade-off)

'I had to explain how our caching layer worked to our PM. I started by walking through how the cache was populated, then I explained the eviction policy (we used LRU with a TTL), then I covered the consistency model, then I went through the failover behaviour. The PM seemed to understand most of it. I think technical communication is really important and I always try to make sure people understand the systems they are working with.'

Why this fails the rubric: the opening is system-first, not listener-first (the candidate does not name what decision the PM was making); the abstraction level is the candidate's natural depth, not a deliberate level chosen for the audience; there is no trade-off surfaced (the PM is left with a tour of the cache, not a choice she can act on); the closing is generic philosophy, not a takeaway. The interviewer hears technical depth but cannot grade audience-first communication, because the candidate has not shown the move that distinguishes communication from teaching.

Pitfalls Specific to This Competency

Four traps that show up most often in communicating-to-non-technical stories.

1. The deep-dive reflex. The candidate retells the technical content of the explanation rather than the choice the listener had to make. The interviewer hears depth but cannot grade communication. The fix is to anchor the answer in the listener's question and the choice the explanation enabled. If you cannot name the listener's question, you have not yet found the framing that scores.

2. Over-simplification that becomes distortion. The candidate, trying to make the explanation accessible, removes structure the listener needed to make a correct decision. The fix is the simplification audit: ask whether the listener could decide correctly with the simplified model. If no, the simplification has crossed into distortion. The phrasing that marks the boundary: 'I am simplifying here, but the underlying behaviour does not change the decision' or 'I want to flag a complication that does change the decision.'

3. Defaulting to the candidate's natural depth. The candidate explains at the level of detail that comes naturally rather than the level the audience needs. The fix is to pick the level deliberately: dollars and incidents for finance, scope and risk for product, perceived behaviour for design, request paths and trade-offs for engineering peers. Naming the level you chose (and why) in the answer is a senior-level signal.

4. Burying the headline. The candidate explains the situation, the analysis, and the constraints before getting to the recommendation or the bad news. By the time the headline arrives, the listener has lost the thread. The fix is the headline-first discipline: the recommendation or the news goes in the first sentence, with the supporting structure following. In writing, this is the one-pager opener; in conversation, this is the first 30 seconds.

Practice Prompts & Exercises

For each prompt below, draft a 200 to 300 word STAR answer. For every story, mark explicitly: the listener's question (what decision were they making), the abstraction level you chose and why, the trade-off you surfaced (or the headline you led with), and the takeaway the listener walked away with. The exercise is the framing audit, not the technical detail.

1. Tell me about a time you explained a technical concept to a non-technical stakeholder.
2. Walk me through a difficult technical communication.
3. Describe simplifying a complex topic for an executive.
4. Tell me about communicating bad technical news to a customer or PM.
5. Walk me through how you write a one-pager for an executive.
6. Tell me about a time your explanation did not land, and what you did next.

For every story, also do the language audit. Read the answer out loud and ask: does the opening name the listener's question, or does it start with the system? does the abstraction level match the audience, or am I defaulting to my natural depth? does the answer surface the trade-off, or is it a tour of the technology? does the closing name the takeaway, or does it trail off in technical detail? Strong communicating-to-non-technical answers open with the listener's question, calibrate the abstraction to the decision, surface the trade-off, and close with the takeaway.

Bridge / Cross-References

This lesson opens the Communication & Influence category. The most useful Foundations companions:

• quantifying-impact is a strong companion because the right-level abstraction for finance and exec audiences is almost always dollars and incidents; the discipline of converting technical work into business numbers is what makes the explanations land at exec level.
• crafting-compelling-stories provides the hook-conflict-resolution structure that the listener-first opening borrows from. The opening of a strong communicating-to-non-technical answer is structurally a hook framed in the listener's vocabulary.
• tailoring-stories-to-role shares the audience-calibration discipline; the same story is told differently for a CFO than for a designer, just as the same competency is demonstrated differently for an IC role than for a staff role.

Within this category, the next lesson (persuading-and-negotiating) takes the audience-first framing and pushes it into the persuasion space: how to surface the listener's criteria and propose with their criteria, not just explain in their language. The lesson after that (managing-stakeholders) extends the discipline to the multi-stakeholder case, where the candidate has to hold consistency across audiences with different contexts and incentives. The thread that carries through all three is calibrated audience discipline: the candidate is not telling their story; the candidate is shaping how their work lands with people whose questions and incentives the candidate has had to learn.