Start with who is listening
The same fault needs different explanations for different people. A colleague whose spreadsheet will not open wants to know whether to wait, restart or call you back. A manager who is deciding whether to delay a launch wants the impact, the likely duration and the options. A fellow engineer wants the details.
Before you speak or write, ask yourself two questions: what does this person need to decide or do, and what do they already understand? Answering those usually tells you what to include and, just as importantly, what to leave out.
Lead with the impact, then the cause
Technical people tend to explain in the order they discovered things: symptoms, tests, findings, conclusion. Most listeners prefer the opposite. Start with what it means for them.
Compare these two openings:
- “The authentication service stopped responding after a configuration push, so the directory queries are timing out.”
- “Nobody can sign in at the moment. We know why and we are working on it. I will update you at 2 p.m.”
The second tells the listener what is affected, that someone is in control and when they will hear more. The cause can follow in a sentence or two if they ask for it.
Use everyday words
Jargon is not wrong, but it only works when both people share it. Look for plain replacements:
- “Server” can become “the computer that stores and runs the application.”
- “Latency” can become “delay.”
- “Cache” can become “a saved copy that makes things load faster.”
- “Bandwidth” can become “how much data can move at once.”
If you must use a technical term, explain it once in a short phrase and then use it consistently. Switching between three words for the same thing creates confusion. Acronyms are especially risky; spell them out the first time or avoid them.
Choose analogies carefully
Analogies can make an idea click. A network can be like a road system, with congestion slowing down traffic; a backup is like a spare key kept somewhere else. Good analogies are familiar to your listener, simple and limited in what they claim.
Be careful not to stretch them. Every analogy breaks down somewhere, and a listener may draw a wrong conclusion from the part that does not fit. If you are explaining why a slow connection affects video calls, the road analogy helps. If you try to use it to explain encryption, it will probably mislead. When in doubt, say what the analogy is meant to show and stop.
Be honest about uncertainty
When you do not yet know the cause, say so plainly. “We have narrowed it down to the network but have not found the exact fault” is more useful than a confident guess that turns out wrong. Give what you do know, what you are doing next and when you will report back.
Avoid promising exact fix times unless you are confident. Ranges and checkpoints (“I will check in at noon with a better estimate”) are more honest and usually better received than a deadline you miss. This is part of a wider habit of methodical troubleshooting, where you separate what you have confirmed from what you suspect.
Give a clear next step
People often feel anxious when they are told about a problem but not what to do. End with one of these:
- What they need to do, if anything (“Please save your work and avoid restarting”).
- What you are doing and when they will hear next.
- What choice you need from them, with the options and your recommendation.
When offering a choice to a manager, keep it short: the options, the trade-offs in terms of time, cost and risk, and your suggestion. If the issue touches a commitment such as a service level agreement, say so, since that is likely to matter to them.
Check understanding without talking down
Asking “Does that make sense?” often gets a polite “yes” even when it does not. Try better prompts:
- “What questions do you have?”
- “Can you tell me how you would explain it to your team?”
- “Is there anything about this that would be useful for me to clarify?”
Watch for signs that you have lost someone: silence, a change of topic or very short answers. Slow down and try a simpler framing. Never imply that the listener should already know. They are experts in something else, and your job is to bridge the gap.
Written explanations
Many explanations happen by email, chat or ticket. A few habits help:
- Put the key point in the first line or the subject.
- Use short paragraphs and, where steps are needed, a numbered list.
- Include screenshots or exact error text when asking for help, so no one has to guess.
- Avoid blame. “The update did not install correctly” works better than “you did not restart.”
Messages that explain a security matter deserve particular care. If you are telling someone why they should use a password manager or multi-factor authentication, focus on the benefit and the minimal effort required instead of listing threats. Fear-based messages tend to be ignored or resented.
A worked example
Suppose a shared drive is slow. An unhelpful message might read: “Disk I/O contention on the file server is causing high latency.”
A clearer version might read: “The shared drive is running slowly because the computer that stores the files is very busy right now. Opening large files may take longer than usual. We are working on spreading the load and expect improvement later today. In the meantime, working from a local copy and saving back later may help, but please check with me first for anything important. I will update you by 3 p.m.”
It states the effect, a simple cause, a workaround with a caution, and a time for the next update. It also leaves room for the technical details to be added to the ticket for colleagues who need them.
Practice
Like any skill, this improves with repetition. Try explaining a recent fault to a friend outside IT and notice where they look puzzled. Read your own tickets a week later and ask whether you would understand them. Over time you will build a small set of plain phrases that work for the situations you meet most often.