How to Explain Technical Work to Non-Tech People

The short version of how to explain technical work to non-technical people: say what changed for them first, explain how in one plain sentence, and then stop and let them ask for more. Most explanations run the other way. They start with the mechanism, work through every step, and reach the part the listener cares about at the very end, after the listener has stopped following.

That order is not a character flaw. It is how the work lives in your head. You spent days inside the problem, so the steps feel like the explanation. For the person across the table, the steps are noise until they know why they should care. Give them the reason first and the steps become something they can choose to hear, rather than something they have to sit through.

Why technical explanations run long

There is a well-known illustration of the problem. In 1990, a Stanford psychology graduate student named Elizabeth Newton asked one group of people to tap out the rhythm of a well-known song on a table while another group tried to name it. Across 120 songs, listeners guessed only three. The tappers had predicted they would get it right half the time. Chip and Dan Heath retell the study in Harvard Business Review and name the effect the curse of knowledge: once you know something, it is very hard to imagine not knowing it.

Every technical explanation has a tune only the speaker can hear. When you say "we added an index on the date column," you hear the whole story: the slow query, the full table scan, the fix. Your listener hears a few words that do not connect to anything they own.

So you add context. Then context for the context. The explanation grows because each sentence depends on the one before it, and none of them has told the listener what it is for yet. By the time you reach the result, you have spent most of the minute on the part they did not need.

Step 1: Start with what changed for them

Before you open your mouth, finish this sentence: "Because of this work, you can now ___." Or, if the work is not done: "Until this is fixed, you cannot ___." The blank is something your listener does, sees, pays for, or waits for. It is never a component.

Take a real example. You made the monthly sales report load faster. The mechanism-first version sounds like this: "So the query planner was doing a full table scan on orders because there was no index on the date column, so we added a composite index, and we also cached the totals." Every word is true, and the sales lead has learned nothing they can use.

The result-first version: "The monthly sales report now loads in about two seconds instead of forty." That sentence is complete on its own. If the meeting ended right there, the listener would leave with the only thing they needed.

You know a lot more than that one sentence. The work of this step is choosing which part of what you know is theirs. Everything else is still true, and it is still available, but it is not where you start.

Step 2: Give the how in one plain sentence

Once the result is on the table, most people want to know a little about how, if only to trust it. Give them one sentence, in words they already use.

For the report: "The database used to read every order to find last month's, and now it can jump straight to the right ones." No "index," no "query," no "scan." The idea is the same, and the listener can repeat it to their own manager, which is the real test of whether you explained it.

If an analogy helps, use one, and only one. "It is like a book with an index at the back instead of reading every page to find a name" works because everyone has done it. Two analogies stacked on top of each other start to compete, and the listener spends effort sorting out which one you meant.

Step 3: Cut the words only your team uses

Jargon is not just the obvious terms. It is also the names your team gave to things: the project codename, the name of the service, the ticket number, the abbreviation everyone on your side of the building says without thinking.

A quick test: would this word appear in an email from your listener to their own team? If not, swap it for what it does. "The ingestion job" becomes "the step that pulls in the overnight orders." "P1" becomes "the most urgent kind of problem." You lose a little precision and gain a listener who is still with you.

This is not about talking down to anyone. Your listener is expert in their own work. They simply do not live in yours. The US government's own guidance for its writers defines plain language as content that is clear and easy to understand, and treats it as more efficient, not less serious (Digital.gov plain language guide).

Step 4: Let their question choose the next layer

Here is the part most people skip. After the result and the one-sentence how, stop. Do not keep going on the assumption that more detail is more helpful. Let the listener's question tell you which layer they want next.

Journalists have long written this way. Nielsen Norman Group describes the inverted pyramid as putting the most important information first, followed by supporting details, so a reader gets the main point however much they read (Nielsen Norman Group). A spoken explanation has the same shape, with one advantage: your listener can tell you where to go next.

If the sales lead asks "Will it stay fast when the data grows?", that is the layer they want, so answer that. If they ask "Did this cost anything?", answer that instead. You never needed to explain the composite index. You needed to have it ready.

Step 5: Stop on purpose

Stopping is harder than it sounds. When you finish the second sentence there is a small silence, and the instinct is to fill it with one more detail. That extra detail usually starts with "and basically," and it pulls the explanation back into the mechanism you just worked to avoid.

Pick your last sentence before you start, then say it and stop. A short pause after a clear answer sounds finished, not unsure, and it gives the listener room to ask. If you want more on ending cleanly, how to stop rambling when you answer a question covers it in depth.

The same pattern works when the technical explanation is part of a regular meeting. If you are giving a weekly update on the same work, how to give a status update in a meeting shows the shorter version: where it stands, what moved, what you need.

A five-minute exercise: how to explain technical work to non-technical people out loud

You need your phone's voice recorder and a timer. Pick one piece of work you did in the last month that someone outside your team would care about.

1. Write the result sentence. One line that starts with "Because of this, you can now" or "Until this is fixed, you cannot." Rewrite it until it names something the listener does, not something you built.
2. Write the how sentence. One line with no word your listener would not use in their own email.
3. Record it. Say both sentences out loud, then stop. Keep the take under twenty seconds.
4. Listen back once. Ask one question: could someone repeat this to their manager without you in the room? If not, find the word that would trip them up.
5. Record it again with that one change. Only one. Then stop for the day.

Do the same piece of work again tomorrow and you will notice the second sentence getting shorter on its own. The goal is not a script. It is getting used to hearing the result come out of your mouth first.

If you keep hearing yourself start at the mechanism and only reach the result near the end, that is a habit, and habits change through short, repeated practice more than through reading. Sayforth is an iPhone app, coming soon, built for that: a 30-day program with one short coached spoken answer a day, and one change to carry into tomorrow. You can see how the daily practice works first.

Frequently Asked Questions

How do you explain technical work to non-technical people in a meeting?

Start with what changed for them, in one sentence they could repeat to someone else. Then explain how in one plain sentence, and stop. Let their question decide whether to go deeper.

Should I use analogies when explaining technical things?

One good analogy can help, as long as it comes from something everyone has done, like using the index at the back of a book. Use one at most. Two analogies in a row tend to compete, and the listener spends effort working out which one you meant.

How much detail should I give a non-technical manager?

Less than you think, and in layers. Give the result and the one-sentence how, then let their questions pull out the detail they need. Keep the rest ready, but do not lead with it.

How do I avoid jargon without sounding condescending?

Swap each term for what it does, and speak to the listener as the expert they are in their own work. Plain words are not simple ideas. They are the same idea without the label only your team uses.