How to explain complex ideas simply when you're speaking

Nearly every guide on this subject is really a guide to writing clearly. Draft it, cut the jargon, add a diagram, revise. That's good advice for a document, and useless in the situation most people actually face: someone in a meeting turns to you and says "sorry — what does your team actually do?" and you have about three seconds before the silence gets awkward.

Speaking has constraints writing doesn't. You can't revise. Your listener can't re-read the hard sentence. You have no diagram. And you are under enough mild social pressure that your default is to say more, not less — which is exactly backwards. This guide is about that situation: explaining something complicated out loud, live, without preparation.

Here is the sequence, and the rest of the guide unpacks each step:

1. Find out what the listener already knows, with one question.
2. Say what the thing is for in a single plain sentence.
3. Anchor it to something they already own — an example or an analogy from their world.
4. Add only the machinery that changes their decision, and stop.
5. Triage your jargon: replace it, define it in five words, or drop it.
6. Give them a place to push back: "does that match what you were asking?"
7. Watch for the two failure modes — too much detail, and simplification that's now wrong.
8. Rehearse the explanation out loud before you need it.

Why is it so hard to explain something you understand well?

Because knowing something rewrites your memory of not knowing it. Once a concept clicks, you lose reliable access to what it felt like before it clicked — so you can no longer tell which parts of your explanation are doing work and which are landing as noise. Psychologists call this the curse of knowledge, and the classic demonstration is almost comically stark.

In a 1990 Stanford study, Elizabeth Newton had one group of people tap out the rhythm of well-known songs — "Happy Birthday," "Baa Baa Black Sheep" — on a table while a second group listened and tried to name the tune. The tappers predicted that about half of the listeners would get it. The listeners got roughly one in forty.

50% vs 2.5%

Source: Newton, 1990 (via The Psychologist, BPS)

The tappers weren't careless. They could hear the full song in their heads while they tapped, and they genuinely could not imagine hearing only the taps. That is precisely your position when you explain your own work: you hear the whole melody, your listener hears knocking.

This has a useful implication. You cannot fix the curse of knowledge by trying harder to be clear, because the thing you're missing is invisible to you by definition. You fix it structurally — by asking what they know before you start, and by checking at the end. Those two moves do more than any amount of careful phrasing, and they are the two most people skip.

How to explain complex ideas simply: the four moves

This is the whole method, and it takes about forty seconds to run.

1. Ask one calibration question first

You need to know where to start, and guessing wastes the first thirty seconds of every explanation — either you're patronising someone who already knew, or you're building on a foundation they don't have. One question fixes it, and the trick is to ask about their use, not their knowledge:

• Good: "Have you worked with anything like this before?" · "Where are you running into it?" · "Is this for the board deck or for the engineering side?"
• Bad: "Do you know what a vector database is?" — this asks them to admit ignorance, so many people will say yes when the answer is no.

Asking about context rather than knowledge gets you an honest answer, because there's nothing to be embarrassed about in "I'm coming at it from the finance side."

2. Lead with what it is for, not what it is

The strongest single change most people can make is to stop starting at the beginning. Chronology and first principles feel rigorous, but the listener has no frame to hang anything on yet, so every sentence costs them working memory they haven't got.

Start with purpose in one sentence, in words your listener already uses:

"It's the thing that stops us sending the same email to a customer twice."

Not: "It's an event-deduplication layer that sits between the queue consumer and the delivery service." Both are true. Only one of them lets the listener decide whether they care.

3. Anchor it to something they already own

An analogy is not decoration — it's a loan. You're borrowing a structure the listener already has and mapping your idea onto it, which is why a good one does most of the work for you and a bad one quietly ruins the explanation.

Three rules for picking one:

• Borrow from their world, not yours. For a finance audience, reach for budgets and reconciliation; for a clinician, triage; for a parent, a school run. An analogy from your domain is just more jargon wearing a costume.
• Match the relationship, not the object. The useful part of "a cache is like a desk drawer" isn't the drawer, it's the trade-off: fast to reach, small, and sometimes stale. If the relationship doesn't map, the analogy will mislead even when it sounds elegant.
• Say where it breaks, in one clause. "It's like a filing cabinet — except anyone can be reading from it at the same time." Naming the limit costs you four seconds and stops the listener from walking away with a confident wrong model, which is worse than no model.

If you can't find an analogy, use a concrete instance instead: one real, specific case, with real numbers. "Last Tuesday a customer got the same renewal notice four times" explains more than any abstraction of it.

4. Add only what changes their decision, then stop

Now ask yourself what this person is going to do with the answer — approve something, choose between options, explain it onward, or simply stop worrying about it — and include only the detail that moves that. Everything else is for you, not them.

This is the hardest move, because the detail you want to add is usually the part you find most interesting, and cutting it feels like being imprecise. It isn't. It's the difference between an explanation and a briefing nobody asked for. Stopping early also leaves the listener room to ask, which turns a monologue into a conversation — the same dynamic that makes handling questions after a presentation easier when you have deliberately left doors open.

What to do about jargon (it costs more than clarity)

Everyone tells you to avoid jargon. What most people don't know is that the damage isn't only comprehension — jargon changes how your listener feels about your argument.

In a study of 650 participants published in Public Understanding of Science, Bullock and colleagues found that jargon-laden descriptions of emerging technologies didn't just make readers understand less; the difficulty of processing the message made them more resistant to persuasion, more sceptical of the information, and more likely to judge the technology as risky (Bullock et al., Public Understanding of Science, 2019). The struggle to follow you gets misread, at a level below conscious awareness, as a reason to distrust what you're saying.

It also doesn't make you sound smarter. Daniel Oppenheimer's experiments on needlessly complex writing found the opposite — the same argument in simpler language was judged to come from a more intelligent author, and the effect held regardless of the underlying quality of the text (Oppenheimer, Applied Cognitive Psychology, 2006).

So run every technical term through a three-way triage before it leaves your mouth:

The middle bucket is the one people forget. Some terms genuinely earn their place — the listener is going to encounter "runway" or "endpoint" again in this project, and teaching it once is a favour. The rule is that you pay for the word the instant you use it, in five words or fewer, and then move on without ceremony. Defining it three sentences later is too late; they've already stopped following.

How do you explain something complicated on the spot?

Live, unprepared, with someone waiting. Compress the four moves into a shape you can run without thinking:

One sentence of purpose. One anchor. One consequence. Stop.

Worked example. Someone on the sales team asks a data engineer what a data pipeline is.

Before — accurate, and lost by the second clause:

"So we've got an ETL pipeline — extract, transform, load — that pulls from the transactional Postgres instance into our warehouse on a six-hourly cadence, with some dbt models layered on top for the aggregations, though we're moving toward ELT because the transform step is getting expensive…"

After — same person, same knowledge, four moves:

"It's the plumbing that gets data out of the app and into the dashboards you look at. (purpose) Think of it like the post round: it collects from every letterbox on a fixed schedule, sorts it, then delivers. (anchor) Which means the numbers you see are up to six hours old — so if a deal closed this morning, don't panic when it isn't there yet. (consequence) Want me to go into why it's six hours and not instant?" (the check)

The second version is shorter, contains no jargon, and — this is the part that matters — actually changed what the listener will do on Monday. The first version contained more information and transferred less.

Notice the pattern is a mild compression of the same structure that makes any spoken point land: get to the point early, then support it. If you find yourself unable to stop once you start, that's a separate habit worth fixing — see how to stop rambling when you talk, which deals with the structural version of this problem.

The two ways simplifying goes wrong

Almost nobody warns you about these, and they are where most well-intentioned simplification fails.

Failure one: you simplified the words but not the structure. You removed every technical term and the explanation is still impenetrable, because it still has five nested clauses and three things the listener has to hold in mind at once. Spoken sentences have a hard limit that written ones don't — your listener cannot go back. If a sentence has more than one "which" or "because" in it, split it. The plainest possible vocabulary arranged badly is still incomprehensible.

Failure two: you simplified it into something false. This is the more dangerous one. There's a version of every explanation that is beautifully clear and quietly wrong, and the listener will now go and repeat it to someone else with full confidence. The test is not "is this simple enough?" but "if they act on this, will they be right?" If the simplification breaks in a case they will actually meet, you must name the limit — the one clause that says where the analogy stops. If it only breaks in cases they'll never meet, leave it out; that's an acceptable approximation, not a lie.

There is a third thing that is sometimes mistaken for simplification and isn't: dropping your register. Talking more slowly, adding "basically" and "just," or using a softer voice tells the listener you think they're slow. Simplify the idea, keep your respect for the person intact — the two are unrelated, and conflating them is why some experts think plain language is condescending. It only is when you do that.

How do you practise this before you need it?

Explaining well live is a rehearsed skill that looks improvised, in exactly the way that being more articulate is. Three drills, in order of how much they'll help:

1. The out-loud version of the Feynman technique. Pick something you know well, set a two-minute timer, and explain it aloud to an imaginary twelve-year-old — no notes, no jargon. The places you stall are not gaps in your delivery; they are gaps in your understanding, which is why this drill is diagnostic rather than cosmetic. Fill the gap, then run it again.
2. Build a small stock of anchors. For the five things you get asked about most, find and refine one analogy each, and note the clause where it breaks. This is the single highest-leverage preparation, because "on the spot" almost never means genuinely novel — it means a question you've had before and never rehearsed an answer to.
3. Record one explanation a week and listen back. You will hear the jargon you didn't notice saying, and you'll hear exactly where you should have stopped. Nothing else exposes the gap between the explanation in your head and the one that left your mouth. Practising out loud in general — see how to practice public speaking — is what converts this from a thing you know into a thing you do.

Key takeaways

• Lead with what the thing is for, in one plain sentence, before any mechanism. Starting at the beginning is what loses people.
• Ask one calibration question first, about their context rather than their knowledge — "where are you running into it?" gets an honest answer; "do you know what X is?" doesn't.
• Anchor to something the listener already owns, borrowed from their world, and name in one clause where the analogy breaks.
• Include only what changes their decision, then stop and check: "does that answer what you were asking?"
• Jargon doesn't just reduce comprehension — it increases scepticism and resistance to your point, and it makes you sound less intelligent, not more.
• The two failure modes: plain words in tangled sentences, and a simplification that is clear but wrong. Test with "if they act on this, will they be right?"

Frequently asked questions

How do you explain complex ideas simply without dumbing them down?

Simplify the structure and the vocabulary, not the substance. Cut nested clauses, replace terms that have plain equivalents, and drop detail that doesn't change what your listener decides — but keep every constraint that would make them wrong if they acted on your explanation. The test is not "is this simple?" but "if they go and act on this, will they be right?" Dumbing down is when you remove something load-bearing; simplifying is when you remove something decorative.

What's the best way of explaining technical concepts to non-technical people?

Lead with the purpose in one sentence using words they already use, anchor it to an example or analogy from their world rather than yours, give the one consequence that affects their work, and stop. Ask a calibration question first — "where are you running into this?" — so you know where to start. Avoid the instinct to build up from first principles: non-technical listeners need the destination before they will follow any route to it.

How do I avoid jargon when speaking if the technical term is the accurate one?

Give the term a five-word definition inline the first time you use it, then use it freely: "the runway — how many months of cash is left." That works when the listener will meet the word again. If they won't, replace it with the plain equivalent; if it changes nothing about what they decide, cut the clause entirely. The mistake is using the term and defining it several sentences later, by which point they have already stopped following.

What is the curse of knowledge and how do I get around it?

The curse of knowledge is the cognitive bias where knowing something makes you unable to reconstruct what not knowing it felt like, so you can no longer judge which parts of your explanation are landing. In Elizabeth Newton's 1990 experiment, people tapping out well-known songs predicted around 50% of listeners would identify them; about 2.5% did. You cannot fix it by concentrating harder, because the missing information is invisible to you — you fix it structurally, by asking what the listener already knows before you start and checking their understanding at the end.

How do you explain something complicated on the spot with no preparation?

Run a compressed version: one sentence of purpose, one anchor from their world, one consequence for them, then stop and offer more. It takes about twenty seconds and beats any improvised build-up. Most "on the spot" questions are ones you have been asked before, so the real preparation is having one rehearsed analogy for each of the five things people ask you about most. If you genuinely can't answer, say you'll come back with a straight answer later — that reads as competence, not evasion.

Conclusion

Explaining something complicated well is not about finding smaller words — it's about giving the listener the destination first, one anchor they already own, and only the detail that changes what they do. Pick the thing you get asked about most often and say the four-move version out loud once, right now. You will hear immediately where it collapses, and that is the whole lesson.