Senior is the top for most engineers and that’s fine
Fewer than one in ten reach Staff level, and most don’t want it anyway.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
One of the engineers I’m coaching asked me something this week that I suspect a lot of senior engineers are wondering.
“Do you think I’m stuck?”
It wasn’t an angry question. He genuinely wanted to know.
He’s been a Senior Engineer for four years. He was one of the first people to join his team and has become the engineer everyone relies on. When something complicated comes up, people naturally look to him. He’s respected across the team, mentors other engineers without being asked, and has earned the trust that every manager hopes their senior engineers will build.
By almost every measure, he’s doing an exceptional job.
The problem is that there’s already a Staff Engineer above him.
So when he asked whether he was stuck, this wasn’t really a question about his performance. It was a question about the very existance (or lack thereof) of the opportunity.
And I think this is where a lot of managers accidentally damage trust. The easy response is to reach for the carrot.
“You’re close.”
“Let’s build a promotion case.”
“Give it another year.”
I’ve said versions of those things myself. But looking back, I think they’re often the wrong answer. Not because the engineer isn’t capable. Because sometimes there simply isn’t another role to promote them into.
When we pretend otherwise, we create expectations we can’t control. Every promotion cycle that comes and goes without the promised outcome chips away at trust a little more. Eventually, even your best engineer starts wondering whether you really meant what you said.
The difficult conversation isn’t telling someone they’re not ready.
It’s telling someone they are ready, but the organisation isn’t.
Once I realised that, I completely changed how I approached these conversations.
I stopped trying to convince people that the next title was just around the corner.
Instead, I started helping them think much more broadly about what growth could look like.
Ironically, those conversations led to more trust, better engagement, and - more often than not, better retention.
But before we talk about what managers should do differently, we need to understand why this situation exists in the first place.
Because despite how it feels... your best senior engineer probably isn’t stuck at all.
Why so many senior engineers end up asking this question
If you’ve managed engineers for long enough, you’ve probably noticed that quite quickly junior engineers become mid-level engineers, mid-level engineers become senior engineers, and then... everything seems to slow down.
Some seniors eventually become Staff Engineers, but most don’t.
It’s easy to look at that and conclude the promotion system is broken. I don’t think it is.
Most senior engineers I talk to feel some type of frustration about their lack of progression.
“I’ve been senior for years.”
“There doesn’t seem to be anywhere to go.”
“I keep getting told to wait.”
“The people above me never leave.”
If you’re an engineering manager, there’s a good chance one of your own engineers is thinking exactly the same thing.
The mistake many of us make is how we explain what’s happening. We call it a promotion bottleneck.
That sounds reasonable.
But I don’t think it’s the right mental model.
It isn’t a bottleneck.
It’s a pyramid.
A bottleneck suggests that something has gone wrong. That promotions should be flowing but have somehow become blocked. Engineering organisations aren’t designed like that.
They’re designed to get narrower as you move up.
A growing organisation might have dozens of junior and mid-level engineers, twenty senior engineers, five Staff Engineers, and one Principal.
That’s not a flaw. That’s simply the shape of the organisation.
As engineers become more senior, the role changes. It stops being about delivering your own work and becomes increasingly about helping dozens (or sometimes hundreds) of other engineers deliver theirs. That naturally means fewer positions exist.
Senior Engineer is a career level rather than simply another step towards Staff. Most engineers who reach senior will spend a significant part of their career there, because that’s exactly how engineering organisations are built.
Your engineer probably isn’t stuck.
They’ve simply reached the point where promotions stop being about individual performance and start depending on whether the organisation actually needs another person at the next level.
Staff isn’t “Senior++”
I think this is where a lot of promotion conversations go wrong. We talk about Staff Engineer as if it’s simply the next rung on the ladder.
Be a better Senior Engineer.
Have a bigger impact.
Write better code.
Eventually you’ll become Staff.
That’s not actually what happens. Staff isn’t Senior Engineer, but more. It’s a different job.
That’s an important distinction, because most engineers spend years trying to become a better senior when what they really need to understand is whether they even want the role above it.
When I ask engineering managers what they expect from a great Senior Engineer, I usually hear things like:
Delivers complex technical work.
Makes good engineering decisions.
Mentors other engineers.
Raises the quality of the team.
Owns difficult projects.
Now ask the same question about a great Staff Engineer and the answers change completely. Instead of talking about code, people start talking about influence.
Cross-team alignment.
Technical strategy.
Helping multiple teams move faster.
Creating clarity when nobody owns the problem.
Much less time is spent building things yourself.
Much more time is spent helping other people build the right things.
That’s why I love the opening line from The Staff Engineer’s Path.
“You’re not a manager, but you are a leader.”
The role isn’t becoming a better individual contributor. It’s increasing your leverage. Sometimes that means writing code. Often it means making sure twenty other engineers don’t have to. That’s also why Staff roles appear much later as organisations grow. A company with twenty engineers doesn’t usually need someone thinking across five teams. There aren’t five teams.
As organisations get larger, coordination becomes more valuable than individual output, and that’s when Staff Engineers start to appear.
The role exists because the organisation needs it. Not because someone has been a Senior Engineer for long enough.
I think that’s one of the hardest truths for ambitious engineers to accept.
Being ready for Staff doesn’t automatically create a Staff position.
The business has to need one.
And another part I think managers overlook:
Not every Senior Engineer actually wants that job.
Some absolutely do. They love influencing across teams. They enjoy shaping technical direction. They thrive in ambiguity. Others don’t. They enjoy building software. They like being close to the code. They don’t want more meetings, more organisational politics, or more time persuading people than programming.
Management isn’t a promotion - it’s a change of profession. I think the same idea applies here. Becoming a Staff Engineer isn’t simply moving up. It’s choosing a different kind of work.
That’s why I think one of the most useful questions a manager can ask is:
Do you actually want the Staff job... or do you just want the Staff title?
Those are very different conversations.
The carrot is often what does the damage
Once you accept that Staff roles are limited, another question naturally follows.
So why do so many managers still promise them? I don’t think it’s because managers are dishonest. I think it’s because we’re uncomfortable disappointing people. Imagine one of your strongest engineers tells you they want to become Staff. You know they’re capable and you’d love to promote them. But you also know there isn’t going to be another Staff position any time soon. That’s an awkward conversation.
So instead, we reach for something that feels kinder.
“You’re really close.”
“Let’s work towards it over the next year.”
“Keep doing what you’re doing.”
Most of us have probably said something like that. The problem is that these promises usually aren’t ours to make. Whether someone gets promoted rarely depends only on how good they are. It also depends on whether the organisation actually needs another person operating at that level. Those are two very different things. When we blur them together, we create expectations that we can’t control.
At first, the engineer will be motivated. They will take on more responsibility. They will become even more valuable. Then the next promotion cycle arrives and nothing happens. So we have another conversation.
“You’re still on track.”
“Let’s build an even stronger case.”
“Maybe next cycle.”
Without realising it, we’ve turned career growth into a moving finish line. Every time that finish line moves, trust gets a little weaker. Eventually, the engineer stops hearing encouragement. They hear uncertainty. Or worse... they start wondering whether we’ve been telling them what they wanted to hear rather than what they needed to hear. Ironically, the conversation we thought would help retention often becomes the reason people leave. Not because they didn’t get promoted. Because they stopped believing us.
I’ve become convinced that engineers can handle difficult news far better than vague promises. If there isn’t likely to be a Staff opening in the foreseeable future, just say so.
That doesn’t end the career conversation. It starts a much better one. Because once the false promise disappears, you can finally focus on the question that actually matters.
How does this person continue growing, even if their title doesn’t change?
In my experience, that’s where the most valuable management conversations begin. And it’s also where I think most managers need a different playbook.
So what should you do instead?
Over the last few years, I’ve settled on four conversations that have consistently led to better outcomes. None of them require an open Staff position. None of them rely on vague promises.
So here’s the first one:
