Most unclear explanations start in the wrong place: with the solution and its details instead of the problem and the decision needed. Lead with context and the conclusion, then the reasoning, then details on request. Write before you speak, use a simple structure, and practise in small, low-stakes moments.
What people tell me
I am usually one of the stronger people technically on my team or in my class. I can see the solution and build it. But when I try to explain an idea in a meeting or a design discussion, people look confused, ask questions that I think are obvious, or go with someone else's idea that I think is weaker. I get frustrated and end up just building it my way, which then causes friction. I know this will limit me but I do not know how to get better at it.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Start with the problem and your recommendation, then the reasoning. Details only when asked.
- Explain at the level of the listener, not the level at which you understand it.
- Write a short note before a discussion. Clear writing is the fastest route to clear speaking.
- Check understanding by asking, not by repeating yourself louder.
- An idea nobody else understands has no impact. Communication is part of the technical work.
Why strong engineers often explain badly
When you understand something deeply, you jump straight to the interesting part: the clever structure, the edge case, the implementation detail. The people listening have not made the journey you made to get there. They are still trying to understand what problem you are solving, and you are already three steps ahead talking about caching strategy.
This is not a personality flaw. It is a structure problem, and structure can be learned.
Use a fixed order
For almost any technical explanation, in a meeting, a message or a design document, this order works:
- Context. What problem are we solving and why does it matter now?
- Recommendation. What do you propose, in one or two sentences?
- Reasoning. Why this option, and what did you consider and reject?
- Trade-offs. What does it cost, and what are the risks?
- Details. Only as far as the listener needs.
Compare two versions:
"So I was thinking we could put a queue in front of the email service and have workers pull from it with retries and a dead letter queue..."
"Right now, when the email provider is slow, sign-ups time out. I suggest we send emails in the background through a queue. Sign-up would no longer wait on email. The cost is one more piece of infrastructure and emails arriving a few seconds later."
The second one gets agreement in a fraction of the time.
Explain at the listener's level
Before you speak, ask who is in the room. A fellow backend engineer, a frontend developer, a product manager and a new junior each need a different starting point. A useful habit is to explain the idea first as if to a smart person outside your team. If they would follow it, your teammates will too.
Replace jargon with plain words where you can. If you must use a term, define it once in half a sentence.
Write it down first
For anything non-trivial, write a short note before the discussion. Half a page is enough: the problem, the options, your recommendation, the trade-offs. Writing forces you to find the gaps in your own reasoning, and it gives others something to read at their own pace. Many of the engineers I respect most are known for clear writing rather than clever speaking.
A simple template:
| Section | One or two lines |
|---|---|
| Problem | What is broken or needed |
| Options | Two or three realistic choices |
| Recommendation | Which one and why |
| Risks | What could go wrong, and how we would know |
| Open questions | What you need from others |
Check understanding the right way
When people look confused, the instinct is to repeat yourself faster or louder. Instead, ask:
- "Which part should I go over again?"
- "Does the problem itself make sense, or is it the solution?"
- "What would worry you about this approach?"
Questions reveal where you lost them. Repetition does not.
Treat pushback as information
When someone picks a different idea, it is tempting to conclude they did not understand. Sometimes that is true. Sometimes they are weighing something you did not, such as deadlines, team familiarity or maintenance. Ask what drove their choice. Either you learn something, or you find the real gap in how you explained yours.
Going off and building it your way anyway damages trust far more than losing one discussion.
Practise in small moments
You do not need a big presentation to improve:
- Write clear pull request descriptions: what, why, how to test.
- Post short end-of-day updates with the context-first structure.
- Explain one concept a week to a junior or classmate.
- After a meeting, ask a trusted teammate: "Was my point clear? What would have made it clearer?"
A self-check before you speak
Before a design discussion, try to answer these in one sentence each. If you cannot, you are not ready to explain it yet:
- What problem does this solve, for whom?
- What am I recommending?
- What is the main alternative, and why is mine better here?
- What does my approach cost?
- What do I need from the people in this room?
This takes five minutes and prevents most of the "people look confused" moments.
A script for when you are interrupted or misunderstood
Discussions rarely go in the order you planned. When someone jumps in with a question about details before you have explained the problem, it is fine to steer gently:
"Good question, I will come to that. Let me first say what problem this solves, because it changes how we would answer it."
And when you realise you have lost the room:
"Let me step back. The short version is: sign-ups fail when email is slow, and I want to take email out of that path. Everything else is how."
The step back is the most useful move in technical communication, and strong communicators use it constantly.
Practise on a timer
Pick something you built recently and explain it in two minutes, recording yourself. Then in thirty seconds. The thirty-second version forces you to find the one sentence that matters, and that sentence is usually what your longer explanations were missing at the start.
If you are still stuck
Read The habits that make an engineer worth routing work through and Twelve moves that take you from mid level to senior, where communication shows up again and again. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- Twelve Moves That Take You From Mid Level to SeniorGetting to mid level is mostly time and repetition, and then the path stops being clear. The thing that got you here, doing assigned work well, is not what the next level rewards, and nobody says so directly, so capable engineers respond by doing more of what already worked. Twelve heuristics for the part that is not obvious.
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.