Explain a Technical Concept Without Talking Down

Here's a practical framework. Think of it as five moves, in order. 1. CHOOSE THE ANALOGY - Pick something your listener already knows cold: cooking, plumbing, money, sports, parenting. Not something you know well — something THEY know well. - The analogy should map to the CORE of the concept, not the surface. For "DNS" the core is "lookup by name," so a phone book works; the core is not "distributed database," so don't start there. - Test it: can you state the concept in one sentence using only the analogy's words? If not, the analogy is wrong. - Rule of thumb: one analogy per explanation. Two competing analogies confuse more than they clarify. 2. DEFINE TERMS AS YOU GO, NEVER AHEAD - Don't front-load a glossary. Define each term the moment it first appears, in one plain sentence, using the analogy's vocabulary. - Example: "A 'cache' is just a sticky note you write the answer on so you don't redo the calculation." - If a term can't be defined in plain words, it's either unnecessary or your analogy is weak. Cut it or fix the analogy. - Avoid defining a term with another undefined term. "Latency is the delay" is fine; "latency is the RTT between nodes" is not. 3. USE ONE CONCRETE EXAMPLE, WALKED THROUGH SLOWLY - Pick a single, small, realistic case and narrate it step by step. Don't show three examples; show one well. - Make the example match the analogy. If DNS is a phone book, walk through: "You type 'amazon.com', your phone looks it up in the book, gets the number, dials it." - Include the moment where the concept does something NON-OBVIOUS — that's where understanding actually happens. The example should show the concept earning its keep, not just existing. 4. NAME THE LIMITS OF THE ANALOGY EXPLICITLY - Say it out loud: "The analogy breaks down here." This is the most skipped step and the most valuable one. - Give the specific place it breaks. "A phone book is static, but DNS entries change constantly and expire — that's why there's a 'time to live.'" - This does two things: it prevents the listener from over-generalizing the analogy into a wrong mental model, and it signals you're being honest, which builds trust. - If the analogy breaks in more than two or three places, it's doing too much work. Replace it. 5. CHECK WHETHER IT WORKED - Never ask "Does that make sense?" — people say yes to be polite. Ask for a demonstration. - Best test: "Can you explain it back to me in your own words?" or "What would happen if X changed?" — a prediction test, not a recall test. - A good probe: "Where do you think this analogy stops being true?" If they can name a limit, they've internalized the structure, not just the words. - If they can't, don't repeat yourself louder. Find the specific step that failed (usually step 1 or 3) and fix that one piece. The whole thing compresses to: analogy -> plain definitions -> one walked example -> explicit limits -> prediction test. The two moves that separate good explainers from bad ones are step 4 (naming the break) and step 5 (testing with a prediction instead of a yes/no question).