You know the technical detail. That is rarely where things go wrong.
The problem starts when someone asks you to explain it quickly, in a room full of people with very different contexts.
Let’s say you are in a project meeting. You have been working through a messy system migration for weeks. You understand the old platform, the new workflow, the data integrity risk, the testing gap, and the reason the timeline has slipped.
Then the head of finance asks: “Can you quickly explain why this migration is taking longer than expected?”
You know exactly why. Several answers arrive at the same time. The architecture answer. The resourcing answer. The testing answer. The data answer. The stakeholder answer. And the one you can’t say out loud, which is that the delay is partly his fault for sitting on a budget approval for a week.
You can feel all of that at once. Now the room is waiting.
Why your answer starts to ramble
Technical explanations often break down because you are trying to protect accuracy. If you know the complexity, you want to avoid flattening it into something misleading.
So you start with one useful detail: “The migration is taking longer because the old system still has dependencies…”
As you speak, the answer gathers more pieces. The testing concern. The data issue. The caveat about another team. The downstream reporting impact.
Halfway through, you can feel the room slipping away. People are still listening, but they are working too hard.
The listener may understand that the situation is complicated and still miss what matters most. You’ve said a lot, but you’re not yet clear.
Give the listener only the map they need
When you understand something deeply, you can see the whole map: the history of the decision, the edge cases, the trade-offs, the hidden constraints, the problems that will appear three steps later if someone makes the wrong call now.
That knowledge is useful and it’s part of why people trust you. And it can make your explanations harder to give.
When you are put on the spot, the instinct is to transfer the whole map. You start explaining how everything connects because you want the listener to see the situation properly.
But most listeners only need the part of the map that helps them act. They need orientation, a sense of what is at stake, and a path forward.
In the migration example, the senior leader does not need the architecture history. They need to know whether the delay reflects poor execution, a real technical risk, or a responsible call.
Those are different answers. Choose the wrong one and the explanation stops being a useful explanation.
Ask what the listener needs from you
Before you explain, take a breath and think about who you’re responding to:
“What does this person need from me right now?”
That question makes the answer easier to choose. For example, the same migration delay can become four different explanations:
- An engineer may need the dependency.
- A product manager may need the release impact.
- A senior leader may need the risk and recommendation.
- A customer may need the consequences and next steps.
In the migration meeting, the senior leader needs to know: is the delay justified?
Everything else can follow if they ask. That is where the answer should start.
Use this three-part structure
When you are put on the spot, give the listener three things:
- Where are we?
- What matters?
- What should happen next?
This keeps the explanation useful without making the listener carry the whole technical map.
1. Where are we? Start with the situation
Start by orienting the listener.
In the migration meeting, the first useful sentence might be:
“We are in the final stage of the migration, but one older system is still feeding customer records into the new workflow.”
That sentence gives the room a place to start from. You are not starting with the whole background. You are telling people where the issue sits right now.
This helps because many technical explanations fail before the listener knows what part of the system they are looking at.
2. What matters? Name the risk and consequence
Once the listener is oriented, explain the risk that matters most.
“If we move too quickly, we risk corrupting that data. Customers could see incorrect account records, and support would spend the next two weeks cleaning up errors we could have avoided.”
This is where you can give some technical details, as long as they are helpful for the listener.
For instance, “data integrity risk” is technically accurate, but feels abstract. “Customers could see incorrect account records” better conveys the idea to someone from a non-technical background.
By giving the stakes, you make it clear why the information is important.
3. What should happen next? End with a recommendation
A clear technical explanation should point towards what’s next.
In the migration meeting, you might finish with:
“My recommendation is to take the extra week, finish the validation, and avoid a messier rollback later.”
That gives the room something to do. Without a next step, technical explanations can trail off into information. The listener may understand more than they did before and still feel unsure what decision should follow.
If you have a recommendation, say it. If you have not formed one yet, say what the next decision point is:
“I would wait until Friday to make the call. Give the team time to finish the validation, then decide whether the extra week is necessary.”
That is still useful. It gives the room a path.
If the listener wants the dependency tree, the full migration plan, or the testing history, they can ask.
Practise the same idea for three audiences
If you want to get better at explaining technical ideas live, choose one idea you regularly need to explain – a migration delay, a policy trade-off, a product constraint, a security risk. Something that comes up on a Tuesday afternoon when everyone is half a step behind and trying to make a call.
Then explain it three ways:
- To your own team. You can use more technical language because they share more context.
- To a senior leader. The emphasis changes. They need the risk, the consequence, and the recommendation.
- To a customer. Here, the technical detail matters only if it helps them understand what will happen, why, and what they need to do next.
The idea stays the same, but the explanation changes because the listener changes.
Keep it clear without dumbing it down
A lot of technical people resist simple explanations because they care about the work. They don’t want to flatten it, or wave away the parts that were hard.
That instinct is worth keeping.
But clarity isn’t the same as dumbing something down. It’s giving the work structure so that someone else can hold it and understand what matters, and what needs to happen next.
When you’re put on the spot, the temptation is to empty your entire brain into the room. Resist that. Your job in that moment isn’t to transfer everything you know. It’s to make the next useful piece of understanding available.
Start there. The details can follow.
If your team has strong technical thinking but struggles to make ideas land under pressure, explore Think and Speak Under Pressure: a practical workshop for experts, founders, and emerging leaders who need to explain complex work clearly in meetings, calls, Q&A, and high-stakes conversations.
