Explain a Technical Problem to Someone Non-Technical
If it does not land, the usual cause is not that they do not understand technology. It is that the “so what” was never made explicit.
How to do it
Step 1: Explain it to someone who knows nothing, until you get stuck
Use “Feynman-Style Explanation” and go through the problem without a single term of art. Where you get stuck is where your own understanding has a hole; go back and fill it instead of polishing the wording. Wording is the last step, not the first.
Step 2: Swap each term using “Turning Jargon into Plain Language”
Turn “the API timed out” into “the user taps once and waits a long time, or it fails”. Turn “refactor” into “replace the foundation without changing the features”. After each swap, ask what decision the listener can now make. A term you cannot swap means you have not connected it to an impact yet.
Step 3: Anchor it with “An Analogy With Its Limits”
The analogy has to say where it stops working, for example “like repaving a road, except this road cannot be closed”. An analogy without its limits gets used for further reasoning, and the listener reaches a wrong conclusion in the wrong place. That is worse than no analogy.
Step 4: Write the three-sentence version with “Rewrite technical docs for non-technical readers”
Sentence one: what happened. Sentence two: who is affected and how much. Sentence three: what decision or resource you need. Put technical detail in an appendix, never in the first paragraph. Read it back; if the first paragraph is still explaining the mechanism, the rewrite is not done.
Step 5: Order the conversation with “Reporting Upward”
Conclusion first, then impact in numbers you can stand behind, then risks and options, then the option you recommend and what it costs. Reporting a problem with no options hands the decision back to someone who lacks the information you already have.
Prompts used
FAQ
What if my manager only gives me five minutes?
Lead with the conclusion and the decision you need, then keep one page of “why” in reserve. If five minutes is not enough, it is not compressed yet; the listener is not the problem.
Does simplifying make me look less professional?
No. Explaining a complex problem so the listener can repeat it back usually signals depth. Keep the omitted detail in an appendix for when they ask.
What if my manager does not understand but will not admit it?
Ask them to repeat it back, or ask them to choose between two options. The missing piece is usually a concrete consequence, not a missing term.