The IT Professional's Guide to Explaining Things to Non-Technical People
At some point in every IT professional's career, they are asked to explain something technical to someone non-technical. This might be a manager who needs to understand why a system migration will take six weeks. It might be a client who wants to know why their website went down. It might be a relative at a holiday dinner who heard you work with computers and has questions about whether Bitcoin is a good investment. Whatever the context, technical communication is a skill that is worth developing deliberately, because the alternative — being correct but unintelligible — is functionally the same as being wrong.
Start With Why, Not What
The most common technical communication mistake is leading with mechanism rather than meaning. "We need to upgrade the TLS certificates before they expire and our HTTPS connections break" is technically accurate and tells a non-technical listener almost nothing useful. "If we don't do this maintenance, your customers will see a scary warning when they visit your website and many of them will leave" tells them everything they need to make a decision. Lead with the consequence or the benefit — the why — and follow with as much technical detail as the conversation actually requires. Usually, that's less than you think.
Analogies Are Your Primary Tool
The human brain understands new things by relating them to things it already understands. A good analogy does more work than any amount of precise technical description. Bandwidth is like the width of a water pipe — more width means more water can flow at once. A server is like a restaurant kitchen — the more orders come in, the slower each one is processed. Encryption is like a locked box that only the intended recipient has the key to. These analogies are not perfectly accurate, but they are useful, and useful beats accurate when your goal is decision-making rather than examination.
Calibrate to Your Audience
Not all non-technical people are equally non-technical. Before launching into an explanation, it's worth spending thirty seconds finding out what your listener already knows. "Have you dealt with this kind of issue before?" or "How much background would be helpful here?" saves you from either talking down to someone who has been managing IT budgets for twenty years or losing someone who genuinely doesn't know what a server is. Meeting people where they are rather than where you assume them to be is the single biggest improvement you can make to your technical communication.
The One-Sentence Summary Rule
Before any technical explanation, spend ten seconds drafting a one-sentence summary of what you're about to say. If you can't summarize it in one sentence, you don't yet understand it clearly enough to explain it to someone else. The summary doesn't replace the explanation — it guides it. "We had a security breach and need to reset everyone's passwords" is a summary that tells the listener what they need to know before you get into the details of what happened, why, and what you're doing about it.
Admit What You Don't Know
Technical people sometimes feel pressure to have all the answers immediately, particularly when explaining things to management. Resisting this pressure pays dividends. "I don't know yet, but I'll have an answer for you by Thursday" is far better than a confident-sounding answer that turns out to be wrong. Trust, once lost through overconfident misinformation, is much harder to rebuild than it would have been to maintain by simply saying you needed more time to investigate.
For more on IT communication and culture, read our post on the unnecessary meeting and our look at WiFi troubleshooting psychology.