How to explain something technical to a non-technical colleague
Reviewed 19 Sept 2026
Experts explain things in the order they learned them: first the background, then the mechanism, and finally the consequence. A colleague from another department needs the reverse. They want to know what changes for them, and only then, perhaps, how it works.
This is harder in a second language, because technical vocabulary is often the vocabulary you know best, so jargon feels like the safe choice. Plain words are safer. If a term is essential, give it and define it once in the same sentence.
The structure: them, idea, picture, next
- Why it matters to them
Start with the effect on the listener's work, their customers or their numbers.
- The idea in one sentence
What you decided or built, without internal names or abbreviations.
- One picture
A comparison with something familiar, or one concrete example. One, not three.
- What happens next
What they will notice, when, and whether they need to do anything.
Before and after
“Basically we're decoupling the ingestion service from the processing workers with a message broker, because the synchronous calls were timing out under load, so now it's asynchronous with retries and a dead-letter queue, which improves throughput.”
- Every key word is jargon: decoupling, broker, synchronous, dead-letter queue, throughput.
- It describes the mechanism and never says what changes for support.
- There is no picture the listener can hold on to or repeat to someone else.
“The short version for your team: uploads will stop failing on busy days. Today, when a customer uploads a file, our system tries to process it immediately, and when many people upload at once, some of them fail. We're adding a waiting line. It works like a ticket system at a bank: every file gets a ticket and is handled in turn, so nothing gets dropped. Customers may wait up to a minute on busy days, but they won't see errors. It goes live on the 12th, and you don't need to change anything.”
Phrases you can use
- “The short version for your team is…”
- “What this changes for you is…”
- “You'll notice one difference:…”
- “It works like…”
- “Think of it as…”
- “A simple way to picture it:…”
- “We call this a queue, which is simply a waiting line for files.”
- “You may hear the word “latency”. It means the delay before something responds.”
- “Does that match what you've been seeing?”
- “Which part should I go into in more detail?”
Common mistakes
Lead with the consequence for the listener. Offer the mechanism only if they ask.
Say the full plain-language thing the first time: “the system that receives uploads”, not “the ingest service”.
Choose one and stay with it. Mixing a bank, a motorway and a kitchen confuses people more than jargon does.
It puts the listener in the position of admitting they did not understand. Ask which part they want more detail on.
A ten-minute drill
- Pick one technical decision from your current work and one real colleague outside your field.
- Record a 60-second explanation for that person. No abbreviations. One comparison.
- Read the transcript and underline every word your colleague would not use themselves. Replace each.
- Record again, and begin with what changes for them.
Questions people ask
Isn't simplifying the same as being inaccurate?
No. You are choosing the level of detail, not changing the facts. A good test: an expert listening would say “yes, that is right, broadly”, and the non-expert could repeat it to someone else.
What if they ask a question I can only answer technically?
Answer the consequence first (“it means no data is lost”) and then offer the detail: “I can go into how, if that's useful.”
How do I find a good comparison?
Look for an everyday system with the same shape: queues, tickets, post, keys and locks, recipes. Try it on one person first. If they repeat it back correctly, keep it.