How do I explain a technical problem to someone without a technical background?
Quick answer
Start with the practical effect, not the technical mechanism. In plain language, say what is happening, what it affects, what people may notice, and what you need from the reader. Keep a technical term only if it matters, and explain it. Separate confirmed facts from possibilities, then end with a clear next step, decision, or update trigger.
The question, the details, the next step.
I need to explain a technical problem to a colleague who isn’t technical. I understand the issue, but I’m worried that if I simplify it, I’ll leave out something important. Where should I start?
Start with what the problem means for the person listening. They need to know what is affected, what they might experience, and what happens next—not every detail of how the system works.
Use this order:
- What is happening, in everyday words?
- Who or what is affected?
- What is the current impact?
- What do you need the reader to do, know, or decide?
Keep technical detail that changes the meaning, risk, or decision. Explain any necessary term the first time you use it. Leave deeper mechanics out unless the person asks or needs them to act.
How do I tell which technical details are necessary? For example, the issue involves a process timing out, but I don’t think my colleague knows what that means.
Ask whether the detail helps the reader understand the impact or make a decision. If not, it can usually be left out of the first explanation.
For your example, you could translate “the process times out” as “the system stops waiting after a set period, so the request doesn’t finish.” That preserves the basic meaning without assuming the reader knows the term. If the timing itself matters, include the confirmed limit: “If a request takes longer than [time limit], it stops and needs to be tried again.” Don’t add a cause or duration unless you have verified it.
I also don’t want to make it sound more certain than it is. We know requests are failing, but we’re still investigating why.
Separate what you know from what you are checking. State the observed problem plainly, then mark the cause as unknown or under investigation. Avoid turning a possible explanation into a fact.
For instance: “Some requests are not completing. We’re investigating the cause. People using [affected service or process] may need to try again later. I’ll share an update by [time or date].” Only include the retry instruction or update time if they are appropriate and confirmed. If you don’t know when you’ll have more information, say what will trigger your next update, such as “I’ll update you when we confirm the cause.”
Can you show me how the whole explanation might look? I need to tell a nontechnical team lead, and I want it to be clear without sounding alarming.
Here is a copyable draft with assumptions shown in brackets. Replace them with confirmed details, or remove anything you cannot verify:
“Some requests in [service or process] are not finishing. This means [plain-language effect on the team]. We’re still checking what is causing the problem, so I don’t want to guess at the reason. For now, [confirmed action or workaround, if any]. I’ll share another update by [time/date or stated update trigger]. Please let me know if you notice [specific useful observation].”
The first sentence names the issue; the second connects it to the team’s work. The next sentence makes uncertainty explicit. The ending gives the reader a practical next step and sets an expectation without promising a fix. If the team lead needs to make a decision, replace the last request with a direct choice: “Please tell me whether we should [option A] or [option B] by [time].” Include only options that are genuinely available.
What if they ask for the technical explanation? I don’t want to sound evasive, but I don’t want to overwhelm them either.
Offer one additional layer and let their question guide how far you go. You might say, “I can explain the technical detail too. The short version is that [one-sentence explanation]. Would you like the steps we’re checking, or is the impact and next update enough for now?”
If you use an unfamiliar term, define it in the same sentence. If the cause is still uncertain, say so before describing possibilities: “We haven’t confirmed the cause. One thing we’re checking is [possibility], but it isn’t established yet.” That is direct without presenting a guess as a conclusion.
A practical checklist
Lead with the practical problem, not internal terminology.
Name who or what is affected and describe the observable impact.
Explain necessary technical terms in everyday words.
Separate confirmed facts from causes or outcomes still being investigated.
End with a specific next step, decision, or update trigger.
Remove any detail, timing, or instruction you have not confirmed.
A few more useful answers
Should I avoid technical terms completely?
No. Keep a term when it matters, then define it briefly in the same sentence. The goal is understanding, not removing all technical language.
How can I make a simple explanation accurate?
Keep the facts that affect the reader’s understanding or decision, and label uncertainty clearly. If a simplification would change the meaning, add a short clarification instead of smoothing over the distinction.
What if I don’t know the impact yet?
Say what has been observed and what remains unknown. Avoid guessing at consequences; tell the reader when or under what condition you will provide an update, if you can.