Explaining Technical Things to Non-Technical People
"It's a DNS issue." The user nods, because nodding is polite. They go back to their desk no wiser than before and now slightly worried that they have an issue called DNS. The technician, who explained it correctly, concludes that the explanation went well. Three sentences would have done it: your computer could not find the address of the server, like a phone with the wrong number for a friend; it has the right number now; if it happens again, tell us and we will know where to look. Nobody in that conversation was being stupid. One of them knew a word the other did not, and the word did all the talking.
This series is about talking so the other person leaves knowing something. It covers why technical explanations fail, usually because the explainer answered a different question. It covers analogies that work, one per concept, and the moment to drop them, and skipping the jargon without dumbing anything down. Then comes the three-sentence explanation of what happened, what it means for you and what happens next. It covers confirming they understood without turning it into a quiz. And it covers explaining technical things to management, who want a decision and not a mechanism. The test of an explanation is not whether it was correct. It is whether the listener can repeat it to someone else.
Articles in This Series
- Why Technical Explanations Fail, and the Question They Miss
The curse of knowledge, jargon, too much detail, the wrong level, answering the question you wish they had asked. Also covers the listener's real question, and an explanation pre-check. - Analogies That Work, and When to Drop Them
One physical analogy per concept, tested, then dropped. Covers a bank of safe analogies for name lookup, a VPN, a cache, permissions, backups, a certificate and a queue. Also includes the analogy bank table. - Skipping the Jargon Without Dumbing It Down
Plain-word substitutions, naming the technical term once then using the plain one, the acronym rule, precision without vocabulary, and a jargon-to-plain table. - The Three-Sentence Explanation for Any Ticket
What happened, what it means for you, what happens next; six worked examples from common tickets; when three sentences are not enough; and the frame to copy. - Confirming They Understood Without a Quiz
The teach-back in a question, the follow-up that reveals a gap, watching for the polite nod, writing it down for them, and the confirmation phrases. - Explaining Technical Things to Management
Risk, cost, time and options rather than mechanisms; the one-page decision brief; the question they are really asking; and the brief to copy.
Explore More Topics
This series is part of the QuerySolv helpdesk topic library. It covers the foundations, processes, communication, knowledge, tooling, metrics, classic ticket domains, people and strategy behind a support desk that works. The library pairs well with the software we build: QuerySolv. It is a self-hosted help desk that runs as one Windows service on your own network. It is licensed once per installation, not per agent per month.