Why Technical Explanations Fail

The central difficulty in explaining technical work is not vocabulary. It is that once you understand something, you cannot reconstruct what it was like not to.

This has been studied. Elizabeth Newton's 1990 Stanford dissertation described an experiment in which participants tapped out well-known songs and predicted how often listeners would identify them. Tappers predicted around fifty percent success. Listeners identified roughly two and a half percent. The tappers heard the melody in their heads and could not experience the tapping as the bare rhythm the listener received.

That gap is what happens in every technical explanation. You have the model in your head. The stakeholder receives the tapping.

What it produces in practice.

You skip steps that feel obvious and are the ones carrying the meaning.

You use terms you no longer notice as terms. Model, feature, drift, pipeline, ground truth, precision: each has an ordinary meaning too, and listeners frequently attach the wrong one silently rather than asking.

You answer at a level of detail calibrated to a colleague.

And you misjudge how much has landed, because the audience nods, which they do whether or not they followed.

The practical consequence is that self-assessment does not work here. You cannot tell from inside whether an explanation succeeded, which means the fix has to be structural: checking what the other person took away, rather than trying harder to be clear.

Technical people answer the question they were asked, which is usually not the question being asked.

When a stakeholder says how does the model work, they are almost never requesting an architecture description. Underneath, they are asking one of a small number of things, and identifying which changes the entire answer.

Can I trust this? The most common one. They want to know whether to rely on the output, and the answer they need is about how it was validated and where it fails, not about how it computes.

What will it do to my area? They are working out whether their team's work changes, whether headcount is affected, or whether their process breaks.

What happens when it is wrong? They are assessing risk and whether they will be exposed.

Why is it saying this about this case? A specific instance, usually one that looked wrong to them, and they want to know whether the system is broken.

Who is accountable? Frequently unstated and frequently the real question.

Or occasionally, genuinely, how does it work, because they are curious or technical.

The practical move is to ask before answering. What would you like to be able to do with the answer, or what prompted the question. That sounds like stalling and it is the highest-return thirty seconds in the conversation, because a well-delivered answer to the wrong question is worse than an awkward answer to the right one: it consumes the meeting and leaves the real concern unaddressed and unspoken.

And the concern that was not addressed does not disappear. It resurfaces later as resistance to your project, which the third lesson deals with.

Any technical explanation can be given at three depths, and the error is choosing by audience seniority rather than by what they will do with it.

The decision level. What it does, whether to rely on it, and what it costs. The system flags applications likely to be fraudulent; it catches most of them and produces some false alarms that a person reviews. Enough to decide whether to fund it, deploy it, or trust it.

The mechanism level. What it uses and roughly how, without implementation. It scores each application on patterns from past confirmed fraud, mainly transaction timing, device history and mismatches between stated and observed behaviour. Enough to reason about where it might fail and whether it fits the domain.

The implementation level. Architecture, algorithms, parameters, infrastructure. Enough to build, maintain or audit it.

The rule that works. Give the decision level first, always, to everyone. Then stop, and offer the next level rather than delivering it.

Why that ordering rather than judging the audience. Seniority does not predict which level someone wants: an executive may be technical, and a manager may need mechanism because they have to explain it onward. Guessing produces either condescension or incomprehension, and both damage trust.

Offering solves it. Here is what it does and whether to rely on it. I can go into what it is picking up on, if that would help. The stakeholder selects their own depth, which they can do accurately and you cannot.

Technical people resist simplifying because it feels like being wrong, and that instinct is worth taking seriously and then correcting.

The concern is real. Simplification does lose information. Saying the model predicts churn omits that it estimates a probability over a defined window for a defined population, and those omissions can matter.

Where the instinct goes wrong is in what it compares against. The alternative to a simplified explanation is not a complete one. It is an explanation that was not understood, which transmits nothing at all and frequently transmits something wrong, because listeners construct their own version from the fragments they caught.

So the comparison is between a partial understanding you shaped and a partial understanding you did not.

The useful distinction is between simplification and misrepresentation.

Legitimate simplification omits detail while leaving the listener's conclusions correct. Saying it identifies customers likely to leave is incomplete and it does not mislead about anything they will act on.

Misrepresentation leaves them with a false belief that affects a decision. Saying it is ninety percent accurate when accuracy is a poor measure for an imbalanced problem lets them conclude something wrong about reliability.

The test to apply. What will this person now believe, and is any of it false in a way that matters for what they will do?

That test permits far more simplification than technical people expect, because most of the detail they resist dropping does not change any conclusion the listener will draw. And it identifies precisely the small number of caveats that genuinely must survive, which are then worth defending properly rather than burying in a list of twelve.

A specific and avoidable failure: terms that have both a technical meaning and an ordinary one, where the listener applies the ordinary meaning silently.

The ones that cause the most trouble.

Accuracy. In ordinary use it means correctness. Technically it is a specific metric that can be high and useless: a system predicting no fraud on a population with one percent fraud is ninety-nine percent accurate. Stakeholders hear correctness and conclude reliability.

Significant. Ordinarily means important. Statistically means unlikely under a null hypothesis, and a statistically significant effect can be far too small to matter. This one causes real misallocation of effort.

Confidence. Ordinarily means how sure you are. Technically a confidence level says something narrower about a procedure's long-run behaviour, and a model's confidence score is frequently not a probability at all.

Bias. Ordinarily means unfairness. Technically it also means systematic deviation, and the two get conflated in exactly the conversations where clarity matters most.

Learning. Suggests understanding and improvement over time. A deployed model typically does neither.

Hallucination. Suggests a malfunction. It is normal operation of a system producing plausible continuations, which changes what mitigation is possible.

And prediction, which suggests foretelling the future rather than scoring against past patterns.

The practical habit. Either avoid these words with non-technical audiences, or define them at the moment of use in half a sentence. When I say significant I mean unlikely to be chance, not necessarily large.

And where a number is involved, give the thing it means rather than the metric. It misses about one in five real cases lands correctly. Recall is eighty percent does not.

Analogy is the main tool for explaining unfamiliar things and it carries a specific risk that is worth managing rather than avoiding.

What makes an analogy work. It maps an unfamiliar structure onto a familiar one, so the listener can reason about it using intuitions they already have. A good one does real work: saying that a model is like a very experienced new employee who has read everything about your industry but has never worked here conveys several true things at once, including that it will be confidently wrong about your specific situation.

Where they fail, and it is predictable. Every analogy is accurate in some respects and wrong in others, and listeners cannot tell which is which. They will extend it. Told that a model learns like a person, they will reasonably conclude that it understands, that it can explain its reasoning, that telling it once is enough, and that it will improve with experience. None of those follow, and the analogy invited every one.

The practical discipline, which costs one sentence.

State where the analogy stops when you offer it. It is like an experienced new colleague, except it will not ask when it is unsure and it does not remember yesterday.

Prefer analogies whose failure modes are harmless. Comparing a model to a person invites overestimation, which is the expensive direction. Comparing it to a very good autocomplete invites underestimation, which is safer and often more accurate for language models specifically.

And watch for the analogy travelling. Stakeholders repeat them onward without the caveats, and a memorable analogy will be quoted back to you in six months, stripped of every qualification you attached.

Which suggests choosing analogies partly for how they survive being repeated by someone who did not understand them.

Since you cannot assess your own explanation from inside it, the only reliable method is checking, and there are ways to do that without being patronising.

What does not work. Does that make sense? Any questions? Both invite yes and no respectively, from people who do not want to appear slow. The nod is not information.

What does work.

Ask them to state it back in their own terms, framed as checking yourself. Can I check I explained that well: how would you describe it to your team? This works because it is genuinely about your explanation and because it produces the actual state of their understanding rather than a signal.

Ask what they would do with it. So if this flags an account tomorrow, what happens? Applied understanding is the only kind that matters and it is directly observable.

Ask what would worry them. This surfaces the concern under the question, and it invites the objection to be spoken rather than carried away silently.

And give them the sentence to repeat. Stakeholders explain your work onward, in rooms you are not in, and they will use whatever phrasing they retained. Supplying it deliberately, in one sentence they can carry, is far better than leaving them to construct it.

That last point is worth emphasising for anyone in a technical team. Most of the transmission of your work happens without you present, through people who understood a fraction of it. The quality of that fraction is something you control, and it determines how your project is described to the people who fund it.

The lesson reduced to habits that change conversations immediately.

Before answering a question about your work, ask what prompted it. Thirty seconds, and it frequently redirects the entire conversation to what the person actually needed.

Lead at the decision level for everyone, regardless of seniority. What it does, whether to rely on it, what it costs. Then offer the next level rather than delivering it.

Apply the misrepresentation test rather than the completeness test. Not have I said everything true, but will they now believe anything false that affects what they do. This permits much more simplification than feels comfortable and identifies the few caveats worth defending.

Watch the double-meaning words. Accuracy, significant, confidence, bias, learning, hallucination, prediction. Define them in half a sentence or avoid them.

Give numbers as what they mean. It misses about one in five real cases, not recall is eighty percent.

Attach the limit to every analogy in the same breath, and prefer analogies that fail toward underestimating rather than overestimating.

Check by asking them to state it back, framed as checking your own explanation, and by asking what they would do with it.

And hand them the sentence you want repeated, because your work will be described in rooms you are not in by people who caught a fraction of it.

None of this is about being a better speaker. It is a small set of structural moves that compensate for a gap you cannot perceive from inside, which is what the tapping experiment established: the problem is not effort, and effort alone does not fix it.