The promotion blocker nobody talks about
You're technically strong. Your reviews say "communication." Here's what that actually means - and the five shifts that close the gap.
It's 4:47 on a Thursday. Your Director pings you in Slack: "Got 5 mins? Quick question about the migration."
You know the migration. You architected the migration. You could talk about it for an hour.
Five minutes later you hang up and immediately replay it. You said too much. You buried the number she needed under three paragraphs of context. You hedged on the date when you actually know the date. You watched her eyes glaze at minute two and kept going anyway.
That call is why you're still a Senior and not a Staff.
Not because you don't know your stuff. You know your stuff. That's the whole problem - you know it so well you can't remember what it's like not to know it. And the person on the other end of that Slack call needs the answer, not the journey.
A story that probably sounds familiar
A few years back I had to tell a CEO and a CFO that a feature wasn't going to be ready for a launch event. Not "might slip" - wasn't going to be ready. I also had to explain that any effort we poured into making it look ready for the event would be thrown away, because we'd have to rebuild it properly afterwards.
I was right. The message was clear. I had the reasoning, the timeline, the trade-off mapped out.
They didn't hear it. They saw the deadline.
We bodged it for the event. Two months later I was back in a room explaining why something they thought was "done" needed another sprint of work. That second conversation was harder than the first one should have been.
I wasn't wrong. I just wasn't heard. And at the time I couldn't tell the difference - which is exactly the trap.
The pattern in performance reviews
Go read your last three reviews. If you're stuck at Senior, you'll find some version of these:
- "Could work on executive presence."
- "Takes a while to get to the point."
- "Would benefit from being more concise in stakeholder communications."
- "Needs to develop their ability to influence without authority."
Notice what's missing: what to actually do about it. Managers often can't articulate it either. They know something's off. They can't name it, so they reach for the HR phrasebook.
These aren't character critiques. They're the sound of a skill gap nobody knows how to teach.
Why the gap exists
The skills that got you to Senior are the opposite of the skills needed at the level above.
To get to Senior, you got rewarded for depth. Precision. Thoroughness. "Let me check one more thing." "Actually, it depends on X, Y, and Z." Caveats demonstrated rigour. Length demonstrated effort.
At Staff and above, those same habits make you invisible in the rooms that matter. Directors don't reward thoroughness - they reward compression. They want the answer, the risk, and the ask, in that order, in under thirty seconds. Then they'll ask for depth if they want it.
Nobody explicitly teaches this transition because it's tacit. You were supposed to pick it up by osmosis from the Staff engineer two desks over. Except they're remote now, or they left, or they never quite figured out how to explain it themselves. Plato, the biggest engineering mentorship platform there's been, wound down last year. The osmosis route is closing.
You're not missing a character trait. You're missing reps.
The five shifts
Here's what the jump from Senior to Staff actually looks like in day-to-day communication. Five shifts. You don't need all five at once - the first one alone will change how people respond to you this week.
1. Lead with the conclusion
Your first sentence is the answer. Not the setup. Not the context. The answer.
Before: "So there are a few things to consider here. The migration has three phases, and in phase two we discovered that the legacy system has a dependency we didn't originally scope. Given that, and factoring in the holidays, I think we're probably looking at end of Q2, maybe early Q3."
After: "End of Q2. Phase two uncovered a legacy dependency we didn't scope - happy to walk through it if useful."
Same information. The second version gets replied to. The first gets "ok thanks" and a mental note that you're hard to get a straight answer out of. We go deeper on this in [post 5].
2. Calibrate to the audience
Same fact, three different framings for three different listeners.
Tell an engineer "we need to rewrite the auth service" and you get a productive conversation about scope. Tell the CFO the same thing and you get panic about cost, or worse, a nod and no budget, because they heard "we have to pay to fix something that was supposed to already work."
This is what I got wrong with the CEO and CFO. I gave them an engineering explanation - phases, technical debt, rebuild - when what they needed was a business explanation: "Shipping it for the event costs us two months of rework. Delaying the feature by three weeks costs us nothing after launch week. Here's which I recommend and why."
Same facts. Different language. One of them lands. [Post 2] is 2,000 words on exactly this, because it's where most engineers lose the most ground.
3. Compress without hedging
"It depends" isn't a recommendation. It's a way of being right without committing to being useful.
Before: "It depends on a few factors. Postgres would give us better consistency guarantees, but Dynamo scales better horizontally and the ops burden is lower. There are trade-offs either way."
After: "Postgres. We don't have the scale to justify Dynamo's ops cost, and consistency matters for billing. I'd revisit in 18 months if usage tripled."
The second version isn't less nuanced - the nuance is compressed into the recommendation rather than sprayed around it. You can still be wrong. You just can't be vague.
4. Know what the question is actually asking
When a VP asks "how's the migration going?" they're almost never asking how the migration is going. They're asking one of four things: Should I be worried? Do you need anything from me? Is this going to come up in my meeting tomorrow? Am I going to regret trusting you with this?
Answer the real question.
Before: "Good! We're on phase two of four, the team's hitting velocity, and the new service mesh is performing well in staging."
After: "On track. Nothing for you to worry about - I'll flag early if that changes."
The VP now has what they needed and goes back to their day. The engineer who gave the first answer feels like they communicated well. The VP feels like they still don't know whether to worry. [Post 4] covers the five most common versions of this.
5. Be honest about what you don't know
This is the one engineers get most wrong, in both directions.
Overconfident: you bluff, get caught, and now everything you say needs fact-checking.
Over-humble: you hedge so hard people stop asking you anything important, because the answer is always "I'd need to look into that."
The middle version sounds like this: "I don't know off the top of my head. I can have a confident answer by end of day, or a rough take right now - which do you need?"
Credibility survives "I don't know." It doesn't survive bluffing, and it doesn't survive never having a view. [Post 3] is the deep dive on this - probably the shift with the highest leverage per unit of practice.
What changes when these land
Meetings get shorter. Slack replies actually get replied to. Your name comes up in rooms you're not in - not because you're charismatic, but because you're quotable. Your manager starts including you in conversations one level up because you won't embarrass them. Your promo packet starts writing itself, because people can repeat what you said back without having to translate it first.
None of this is about personality. Introverts can do all five. So can people with imposter syndrome. So can people who hate small talk. These are mechanical shifts, not character ones - which is why they're practisable.
Where to start this week
Pick one. Probably shift #1, because it's the highest-frequency opportunity - you send Slack messages and emails constantly, and every one is a chance to reorder the first sentence.
Try it on low-stakes comms for two weeks before you try it on your skip-level. Reply to your teammate's "how's that ticket going" with the answer first, context second. See what happens to the thread length. See what happens to how often they come back with follow-up questions.
The reps matter more than the theory. Which is the honest problem: nobody has many low-stakes reps available. You don't want to practise being crisp with the CFO by being mid-practice in front of them.
That's the gap we built Parod to fill. It sends you workplace questions from named personas - an impatient CTO, a non-technical PM, a sceptical architect - and evaluates how well you communicated for that audience, not just whether you got the answer right. Same answer can score 4/10 or 9/10 depending on who asked. You can try a question without signing up - takes 90 seconds.
Or skip the product and start with shift #1 on your next Slack reply. The rest of this series goes deeper on each shift. Next up: What your CTO actually hears when you explain technical debt.