At my current company, there are developers who are genuinely better at writing code than the people above them in the hierarchy. Better abstractions, cleaner implementations, faster debugging. And yet they're stuck at mid-level while less technically impressive engineers are getting promoted to senior and staff roles.
The difference, almost every time, is communication. Which sounds like one of those obvious statements everybody agrees with and nobody acts on. But I want to be specific about what I mean, because "communication" is one of those words that's so broad it's almost useless.
What "communication" actually means here
Not giving presentations. Not writing blog posts. The everyday stuff:
Explaining a technical decision in a PR review so the other person understands the why, not just the what. Writing a one-page proposal that a product manager can follow. Jumping on a call during an incident and describing what's broken, what you've tried, and what you need — in under 60 seconds.
At every company I've worked at, this is what the senior level actually means. The technical bar is table stakes. The thing that blocks most mid-level engineers from promotion is their ability to make their expertise useful to other people. I've seen this play out with at least four or five developers I've worked with closely — technically strong, but their ideas died in their heads because they couldn't get them across.
The "smart but can't explain it" problem
You know someone like this. Maybe you are someone like this. Technically strong — the person everyone goes to when something is really broken. But their design docs are hard to follow. Their PR descriptions say "fixed the thing." In meetings, they're technically accurate but confusing — jumping into implementation details when the room needs the big picture.
From the other hand, there are engineers who are maybe 70% as technically strong but who can write a clear RFC, explain a trade-off in plain language, and align a cross-functional team on a direction. Those engineers get promoted. They get the interesting projects. They get asked for their opinion.
This is probably unfair. I go back and forth on it. On one side, the "smart but can't explain it" person is often doing the hardest actual work. On the other side — if nobody understands your technical direction, it doesn't matter how good it is. The org can't execute on ideas that live only in your head. So is communication a proxy for value, or is it actual value? I lean toward the latter, but I get why people are frustrated by it.
Why this compounds
Communication compounds in a way that technical skills don't. A framework you learn today might be irrelevant in three years. Your React expertise might become less relevant as the landscape shifts. But explaining a complex system clearly, writing a convincing proposal, breaking down a problem for someone with different context — that transfers everywhere.
At the staff and principal level, communication is the job. Writing documents, leading discussions, influencing technical direction across teams. The engineers who can articulate their thinking have an enormous advantage.
Though I should be honest — I'm not at staff level myself. I'm extrapolating from what I've observed and from conversations with people who are. So take this with appropriate skepticism. What I can say from direct experience is that communication was the biggest factor in my own jump from mid to senior, and it's the most common gap I see when I interview candidates.
How to actually get better at this
Nobody teaches you this. CS programs don't cover it. Bootcamps don't. Most companies just expect you to figure it out, which is kind of insane when you think about it — they'll send you to a $2000 conference to learn a framework but won't invest anything in the skill that actually determines your career trajectory.
Explain your work to people who don't share your context. Not just to other engineers on your team — to product managers, designers, new hires. When I was building Prestonly (a language learning app I co-founded), I had to explain technical decisions to my non-technical co-founder constantly. That forced a level of clarity I never needed when talking to other devs.
Write shorter. I used to write long, detailed technical documents because I thought thoroughness meant quality. A one-page document that makes a clear argument is more valuable than a five-page document that covers every edge case. When I started cutting my design docs in half, my thinking got clearer, not less thorough.
Notice how other people explain things. When someone in a meeting gives a really clear explanation — like, the room visibly gets it — pay attention to what they did. Usually it's something simple: they started with the problem, not the solution. They used an analogy. They said one thing instead of three.
Get feedback on clarity, not just correctness. Ask "was that clear?" after explaining something. Not "was that right?" A correct explanation that nobody follows is useless.
The uncomfortable part
The reason most engineers don't work on communication is that it's uncomfortable. No compiler tells you whether you got it right. No test suite. You explain something in a meeting and you think it went well, but maybe three people in the room were confused and just didn't say anything. There's no feedback loop unless you actively create one.
I'm still working on this myself. Writing in English as a non-native speaker (Polish is my first language) adds another layer — sometimes the communication gap isn't about clarity of thought but about vocabulary or phrasing that doesn't land the way I intended. That's a separate problem but it compounds with the same skill deficit.
But yeah. It's the kind of thing where even a small amount of deliberate practice makes a noticeable difference. Not weeks-to-mastery difference. More like: you start noticing when you're losing people mid-explanation, and you start correcting in real time. That alone is worth a lot.
Top comments (0)