Nair argues that the habits which earn promotions — exhaustive analysis, precise language, refusal to oversimplify — become liabilities when the job shifts from writing code to influencing decisions. Senior developers optimize for completeness and accuracy when their audience needs conclusions and actionable direction.
Nair identifies the 'completeness trap' where senior engineers, when asked a question like 'Kafka or SQS?', present fifteen dimensions of tradeoff analysis instead of a clear recommendation. The instinct to be thorough feels like rigor to the engineer but signals inability to commit to a decision to leadership.
The editorial extends this point with a concrete example: a VP doesn't want a survey of the message queue landscape — they want 'SQS, because our throughput doesn't justify Kafka's operational overhead, and here's the migration path.' Leading with caveats instead of conclusions is the core failure mode.
The editorial frames this as a systemic paradox at L5+: the career ladder rewards exhaustive analysis and technical precision on the way up, then abruptly demands a completely different communication style — leading with conclusions, optimizing for decision-making audiences — once engineers reach senior/staff levels. Nobody warns engineers about this transition.
There's an uncomfortable pattern in software engineering that anyone who's sat through a few promo committees has seen: the developer who can untangle any distributed systems problem but can't explain to their skip-level why the project is two weeks behind. The architect who writes brilliant RFCs that nobody reads. The staff engineer whose Slack messages read like man pages.
The paradox at the heart of senior engineering is that the habits which got you promoted — exhaustive analysis, precise language, a refusal to oversimplify — become liabilities once your job shifts from writing code to influencing decisions. This is the thesis at the core of a piece by Nair that hit 461 points on Hacker News this week, and it clearly struck a nerve.
The article argues that senior developers fail to communicate their expertise not because they lack communication skills in general, but because they apply the wrong *kind* of communication skill. They optimize for accuracy when they should optimize for clarity. They lead with caveats when they should lead with conclusions. They explain how the system works when the audience needs to know what to do about it.
From the discussion and the broader pattern this article identifies, senior developer communication failures tend to cluster into three modes.
The Completeness Trap. Senior developers have deep mental models. When asked "should we use Kafka or SQS?", they don't see a simple question — they see fifteen dimensions of tradeoff analysis. So they present all fifteen. The instinct to be thorough feels like intellectual honesty, but to the audience it reads as indecision. A VP doesn't want a survey of the message queue landscape. They want: "SQS, because our throughput doesn't justify Kafka's operational overhead, and here's the migration path."
The Precision Trap. Engineers are trained to be exact. "It'll probably take about three weeks" feels wrong to say when you know there's a dependency on the auth team that could push it to five. So instead you say: "It depends on whether the auth team ships their token refresh changes, which is currently blocked on a security review that might require a design change, so it could be three weeks or it could be seven." Technically more accurate. Practically useless. The stakeholder heard: "I don't know."
The Abstraction Mismatch. This is the subtlest one. Senior developers naturally think in systems — distributed state, consistency models, failure domains. But most cross-functional communication happens at the product or business layer. When a senior dev explains a latency issue by talking about tail latencies in the P99 of a downstream service's connection pool exhaustion pattern, they're not wrong. They're just speaking a language that makes the product manager's eyes glaze over. The failure isn't technical inaccuracy — it's picking the wrong layer of abstraction for your audience.
The HN discussion around this piece surfaced a genuinely interesting structural argument: the engineering career ladder incentivizes this problem.
At most companies, the path from mid-level to senior is almost entirely about technical depth. You get promoted because you can debug race conditions, design schemas that don't fall over at scale, and review code with the precision of a compiler. Communication is mentioned on the rubric, but it's usually something like "communicates effectively with team" — and "team" means other engineers.
Then you hit staff or principal level, and suddenly the job is 60% communication. Write strategy docs. Present to executives. Align three teams on a migration plan. Mentor juniors who don't share your mental models. Nobody taught you this. The ladder didn't prepare you for it. And the people who are naturally good at it often got promoted faster, which creates a survivorship bias where senior ICs assume communication skill equals lack of technical depth.
This creates a toxic dynamic. The most technically capable people self-select out of influence. They retreat to code, where they feel competent, and cede the strategic conversation to whoever's comfortable in a meeting room. The result is architectural decisions made by people optimizing for persuasion rather than correctness.
Several commenters on the HN thread pointed out that this is essentially a market failure. Organizations are paying senior IC salaries for technical judgment, then structurally preventing that judgment from reaching decision-makers. One commenter put it bluntly: "We have $400K engineers whose most impactful output is code reviews, because nobody taught them how to write a one-pager."
Not everyone agreed with the framing. A recurring counterpoint in the discussion was that the problem isn't senior developers failing to communicate — it's organizations failing to *listen*.
If your VP can't sit through a five-minute technical explanation of why a deadline is unrealistic, that's a leadership problem, not an engineering problem. If your product manager doesn't understand what P99 latency means after three years at a tech company, maybe they should learn. The expectation that engineers should always translate downward while nobody translates upward is, in this view, a form of organizational laziness.
There's merit to this. Companies where technical leaders have genuine authority — where the CTO actually codes, where architecture reviews are attended by executives — don't seem to have this problem as acutely. The communication gap is partly a symptom of organizations where "business" and "technology" are treated as separate tribes.
But even granting that, the pragmatic reality is: if you're a senior developer who wants your expertise to matter, waiting for the organization to fix itself is a losing strategy. You'll retire before the VP learns what a connection pool is. The asymmetry exists, it's unfair, and you still have to deal with it.
The practical advice that emerged from both the article and the community discussion clusters around a few patterns:
Lead with the recommendation, not the analysis. Start with what you think the team should do, then provide supporting evidence for those who want it. This is the "pyramid principle" from consulting, and it works because it respects the audience's time while still making your reasoning available. "We should use SQS. Here's why." Not: "Let me walk you through the message queue landscape."
Calibrate your abstraction layer. Before you explain something, ask: what does this person need to *decide*? A product manager needs to know if a feature will ship on time. An executive needs to know if a bet is paying off. Another engineer needs to know how the system actually works. Same information, three completely different presentations.
Treat uncertainty as a feature, not a bug. Instead of hedging with caveats, frame uncertainty as a risk management question: "My best estimate is three weeks. The main risk is the auth team dependency, which could add two weeks. Here's what we can do to derisk it." This communicates the same information as the hedge, but positions you as someone managing risk rather than someone who doesn't know.
Write more, talk less. Several commenters noted that writing forces clarity in a way that speaking doesn't. You can't wave your hands in a document. A well-structured one-pager that takes an hour to write will have more organizational impact than ten ad-hoc Slack conversations. Staff engineers who write well have disproportionate influence, and it's not a coincidence.
If you're a senior developer reading this and feeling called out, the actionable version is straightforward: pick one high-stakes communication in the next two weeks — an RFC, a status update, a design review — and restructure it around your recommendation rather than your analysis. See what happens.
If you're a manager, audit your team's communication expectations. Are your senior ICs presenting at architecture reviews? Writing strategy docs? If the answer is "they just review code and mentor," you're underutilizing your most expensive talent and probably making worse decisions as a result.
The ultimate irony is that senior developers have the most valuable perspective in the room and the worst tools for sharing it. Fixing that isn't a soft skill — it's a force multiplier on every technical decision they touch.
The 461-point HN response to this piece suggests the industry is increasingly aware of this gap. With the rise of staff-plus engineering roles and the growing expectation that senior ICs drive strategy (not just execution), communication is becoming less of a nice-to-have and more of a gating factor for impact. The developers who figure this out won't just have better careers — they'll build better systems, because their judgment will actually reach the decisions that matter.
As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by> “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?”as with exper
> They want to avoid development as much as they can.One of my favorite .sigs was: I hate code, and want as little of it as possible in my software. I don't remember where I saw it, but it was a while ago. It's possible the author has an HN account.One of the things that happens to &quo
Most proof of concepts I've seen get traction turned into production.A rewrite?I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened.The article touches on responsability, accountability. There is none for risk taker. By definition. You
What I found is that my willingness to communicate and share my expertise is usually not in demand with more junior developers. In general, I find developers uninterested in finding a mentor. They don't look at your linked in profile, they don't look at you as a possible source of knowledg
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it.An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty cou