The one idea
You are not simplifying the topic. You are building a bridge from something they already know to the one thing they need.
That reframes the task completely. "Explain the migration" is impossible — there is no end to it. "Get the finance director to the point where she can tell the CFO why this money is needed" is a specific, finite job, and it takes about ninety seconds.
So the first question is never "how do I simplify this?" It is: what do they need to be able to do afterwards? Decide, approve, use, repeat it to someone else, or stop worrying about it? Everything you say is chosen against that answer, and everything else is left out — not dumbed down, left out.
Work out what they need to do with the information, then say only the parts that get them there.
Start from the outcome, build on what they already understand, add detail in layers, and stop when they can act.
You are constructing the smallest accurate model sufficient for their decision. Accuracy is bounded by the decision, not by the domain — a model that is incomplete but leads to the correct choice has done its job.
The mental model: layers, not summaries
Beginners try to compress. They take the full explanation and squeeze it, which produces something both incomplete and still incomprehensible.
Layering is different. Each layer is complete and true at its own level. You stop when they have enough.
| Layer | Length | Content |
|---|---|---|
| 1. The headline | One sentence | What it is and why it matters to them |
| 2. The shape | Three or four sentences | How it works, one level down, no jargon |
| 3. The mechanism | A paragraph | What actually happens, terms defined as used |
| 4. The detail | On request only | The parts an expert would want |
Most conversations end at layer 2. Interviews usually go to 3. Layer 4 comes out only when someone asks, and one of the strongest professional signals there is, is stopping at the right layer instead of emptying your head.
The database migration, layered.
Layer 1: "Our customer database is at its limit. Migrating it means orders stop failing at peak — which is what caused the Diwali outage."
Layer 2: "Right now customer information is spread across three tables that all have to be updated together. During a sale, thousands of orders try to do that at once, and they end up queuing behind each other. Orders time out. The new setup keeps the information in one place, so there is nothing to queue for."
Layer 3: Locking, transactions, why the current design was reasonable when it was built and stopped being so at this volume.
Layer 4: Schema design. Nobody in that room wants layer 4.
Layer 1 is what the finance director repeats to the CFO. That sentence — not your architecture diagram — is what gets the money approved.
Analogy: useful, and dangerous
A good analogy is the fastest tool you have, and the one most likely to backfire.
It works by mapping the new thing onto something the listener already has in their head. "A database index is like the index at the back of a book — instead of reading every page, you look up the word and it tells you which pages to check." Instant, and structurally correct.
It fails in two ways. If it comes from your world instead of theirs — "it's like a hash map" to an accountant — you have explained one unknown with another. And every analogy breaks somewhere, so if you do not say where, the listener will confidently extend it into wrongness.
The habit that makes analogies safe: say where it breaks, in the same breath.
"Think of the API as a restaurant menu — you can order the things on it, and you don't get to walk into the kitchen. Where that stops working is that a menu is fixed and an API changes; when they change it, our order can stop being accepted."
Ten extra words, and you have prevented the misunderstanding that would otherwise surface three weeks later in a meeting you are not in.
Checking understanding without being insulting
"Does that make sense?" is nearly useless. It has one socially acceptable answer and everybody gives it. So does "are you following?", which additionally suggests they might not be.
Ask questions that put the burden on you, not them.
| Instead of | Ask |
|---|---|
| "Does that make sense?" | "Was that useful, or do you want it from a different angle?" |
| "Do you understand?" | "How would you explain this to your team?" |
| "Any questions?" | "What part is still fuzzy? There's usually one." |
| "Is that clear?" | "Which bit would you want more detail on?" |
The strongest of these is asking them to say it back — "how would you put this to the CFO?" — because it is a real, useful task, not a test. You will hear exactly which part did not land, and you can fix that part instead of repeating the whole thing.
The other move: give them permission to not know. "I'll use the word 'schema' a lot — it just means how the data is arranged. Stop me if I use anything else that's unclear, I do it without noticing." This costs you a sentence and makes the entire rest of the conversation safe to interrupt.
Knowing what to leave out
The hardest part, because everything feels relevant to you.
Three things to cut, always:
The history. How you discovered it, what you tried first, why the previous approach existed. Fascinating to you. Irrelevant to their decision. If they want it they will ask.
The precision that does not change the answer. "It takes about a second" is better than "between 800 and 1,400 milliseconds depending on cache state" unless they are deciding based on that number. False precision does not make you sound rigorous; it makes you sound unable to tell what matters.
Your competence. The strongest urge in a technical explanation is to demonstrate that you know more than you are saying. It is the single most common reason explanations fail. The listener does not need proof you are clever — they already assumed it, which is why they asked you.
In an interview: "Tell me about your final year project."
Too much: "So we used a CNN with three convolutional layers and max pooling, trained on a dataset of 12,000 images, we tried ResNet first but the training time on Colab was—"
Right shape: "We built something that reads handwritten forms and pulls the data out automatically. The interesting part was that our first version worked on clean scans and completely failed on phone photos, because of the shadows. Fixing that was most of the project."
The second answer is not less technical. It is ordered for the listener — the outcome, then the interesting problem, then the work. And it invites the next question, which is what you want. The interviewer can now ask about the shadow problem, and you can go to layer 3 knowing they are interested.
Explaining anything, in five moves
1 of 6Name the decision. What do they need to do afterwards? Approve, choose, use, relay, or relax? Write it down if it is a big explanation. Everything else follows from this.
Try this
Explain to a small shop owner why they should not use the same password for their business email and their supplier portal. You have four sentences, no jargon, and they are busy.
Your challenge
Level 3 · IndependentTake the most complicated thing you actually know — your work, your degree project, a system you maintain — and write all four layers of it.
Then test layer 2 on a real person who does not share your background. A parent, a friend in another field, a colleague from a different team.
You have succeeded when they can say it back to you in their own words, correctly enough to make the right decision — not word-perfect. If they cannot, the problem is nearly always that layer 1 was missing or was about the thing rather than about them. Rewrite layer 1 and try on someone else.
What people usually get wrong
- Answering the question you find interesting. They asked why it costs so much; you explained how it works.
- Using an analogy from your own field. "It's basically a cache" explains nothing to someone who does not know what a cache is.
- Not saying where the analogy breaks. They will extend it, confidently, in a meeting you are not in.
- "Basically" and "essentially" as decoration. Usually the sentence after them is not simpler, and the word signals you are about to be approximate without saying how.
- Defining a term after using it three times. Define it the first time, in the same sentence, in six words.
- Reading their silence as understanding. Silence usually means they lost the thread and are too polite to stop you.
- Over-apologising for simplifying. "This is a bit of a simplification but basically, roughly speaking..." Just say the simple true thing.
- Correcting harmless imprecision when they say it back. That is the moment people feel talked down to, and you will not get another explanation from them.
How someone experienced does it
People who are genuinely good at this prepare one sentence and treat the rest as improvisation. They know their layer 1 cold — the sentence that contains the consequence for the listener — because that is the sentence that gets repeated in rooms they are not in. Everything else can be assembled live once that anchor is fixed.
They also listen for the actual question. "How does the recommendation engine work?" from a marketing head almost never means how it works. It means "can I trust it", or "can I change it", or "is it going to embarrass us". Answering the literal question is how you deliver a technically perfect explanation that satisfies nobody. When you are unsure, ask: "Happy to go into it — what's prompting the question?"
And they treat a failed explanation as their own bug, not the listener's. Not out of humility, but because it is the only interpretation you can act on. "They didn't get it" leads nowhere. "My anchor was wrong — I used queues and she thinks in cash flow" leads to a second attempt that works.
When not to use this
Layering is the wrong approach when:
- Precision is the whole point. Medical dosing, legal wording, safety procedures, financial instructions. Say it exactly, then explain the exact version. Never the other way round.
- They are an expert. Layering at someone who knows more than you do is insulting and wastes their time. Ask what they already know, then start there.
- You do not actually understand it. The honest move is "I don't know that well enough to explain properly — let me check and come back." Explaining something you half-know produces confident wrongness, and you will not be able to tell where it broke.
Why the expert is the worst explainer
The difficulty is structural, not a matter of effort. Once you know something well, the steps you took to learn it have collapsed into a single move. You no longer experience the intermediate steps, so you cannot see that they are missing from your explanation. This is often called the curse of knowledge, and it does not go away with practice at the subject — only with practice at explaining.
Two practical consequences. First, the person who learned the thing recently is often a better explainer than the person who has known it for a decade, because the steps are still visible to them. If there is someone on your team who learned it last year, watch how they explain it.
Second, you cannot detect your own gaps by re-reading your explanation — it will look complete to you, every time, because your brain fills the holes automatically. The only reliable detector is a real listener saying it back to you. That is why the say-it-back check appears twice in this lesson: it is not a nicety, it is the only instrument you have.
Prove it
Write the four layers of one thing you know well, on one page.
Then use layer 1 in a real conversation this week, and write down the first question they asked afterwards. That question is the most useful feedback you will get — it tells you exactly what your layer 1 left open, and it is usually not what you predicted.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned explaining a technical concept to a non-technical audience. Assume I am intelligent but relatively new to this — treat me as intermediate level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood explaining a technical concept to a non-technical audience. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at explaining complex things clearly — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.