Why Most Senior Engineers Never Make It to Staff

"Why Most Senior Engineers Never Make It to Staff"

Hey, welcome back to Gazar Breakpoint. I'm Gaz, and today I want to talk about something I've seen play out over and over again in the last 15 years. And that is — why do so many really, really good senior engineers just... stay senior? Like forever.

And I want to be clear upfront — there's nothing wrong with that. Being a great senior engineer is a genuinely valuable thing and some people are happy there. But I talk to a lot of people in my mentorships and through the community, and there's a very common pattern. Engineers who are technically excellent, who ship great code, who are reliable, who everyone likes — and they just can't seem to get that next step. Staff engineer, principal engineer, whatever your company calls it. And they're frustrated because they feel like they're doing everything right.

So I want to unpack what's actually happening there. Because usually the problem is not what they think it is.

Let me start with the most common mistake I see. And that is: optimising for the wrong thing.

When you're a junior engineer, the job is basically to learn and to execute. Someone gives you a task, you do the task well, you ask good questions, you grow. That's it. And when you get to mid-level, same thing but you need less handholding. Then at senior level, you're expected to own a feature, break it down yourself, deliver it, maybe support some more junior people on the way.

The trap — and this is the trap — is that a lot of engineers think the path to staff is just doing that more. Being a faster, better, more senior version of senior. Writing cleaner code. Closing more tickets. Reviewing more PRs. And look, those things are good. But they're not going to get you to staff. Because staff is a fundamentally different job. It's not senior++. It's a different role.

And that's the invisible shift that nobody explains clearly enough.

So what does staff actually look like? Let me describe the difference from what I've seen.

A senior engineer asks: "What should I build and how should I build it?"

A staff engineer asks: "Should we build this at all? And if we do, what does it mean for the next 18 months?"

See the difference? The scope is different. The time horizon is different. The questions are different.

When I was moving into more of an architectural role, one of the things that changed for me was I stopped thinking about my team's problems and started thinking about the organisation's problems. My team was part of a bigger system. And my job was to understand that bigger system and help steer it in the right direction.

That shift in scope — from "my feature, my team, my quarter" to "our platform, our direction, our trajectory" — that's what separates the two levels more than anything else.

The second thing I see a lot is what I'd call the execution trap.

Senior engineers are often really, really good at execution. And the thing about being good at execution is that everyone wants you to keep executing. Your manager loves that you close tickets. Your team loves that you unblock them. The business loves that things ship.

But if you're always heads-down executing, you're not building the other muscles you need. You're not in the architecture discussions. You're not writing the tech proposals. You're not thinking about what the next big investment should be or what the team should stop doing.

And the cruellest part is that your execution skills can actually hide the problem. Because you look great on paper. You're shipping. Your manager is happy. But you're not growing into the next level. You're just getting really comfortable where you are.

So if you're a senior engineer and you feel stuck — the first question I'd ask is: how much of my time is spent executing versus influencing? Because those need to be in better balance.

The third thing, and this one is big, is communication. And I don't mean soft fluffy communication. I mean the hard technical stuff.

Can you write a design doc that convinces people? Can you explain a complex technical trade-off to an engineering manager who doesn't know the details? Can you push back on a bad idea in a way that doesn't create conflict but actually moves things in the right direction?

At staff level, your ability to communicate IS your technical work. Because you're not the one writing all the code anymore. Your job is to align people, to share context, to make sure decisions are made with the right information. And if you can't do that clearly and confidently — through writing, through diagrams, through conversations — then you can't do the job.

I've seen engineers who are objectively brilliant at the technical side, but they struggle to get their ideas across. They write long emails that nobody reads. Their design docs are hard to follow. They get talked over in meetings. And then they wonder why people with less technical depth are getting promoted past them.

It's not fair, but it's real. So invest in your communication. Write more. Draw more. Practice explaining things simply.

The fourth thing is influence without authority. And this one takes time to develop.

At senior level, your authority is mostly positional. You're on this team, you own this area, you make decisions about it. But at staff level, you're often influencing things you don't directly own. Other teams' decisions. Platform choices. Engineering culture. And you don't have formal authority over any of that.

So how do you actually move things? You build trust. You do it by being right often enough that people start to listen when you say something. You do it by picking your battles — not pushing back on everything, but knowing when something really matters and making a strong case. You do it by understanding other people's constraints and designing your proposals so they solve other people's problems, not just yours.

This takes time. And it's not natural for a lot of engineers, because we're trained to solve technical problems, not social or organisational ones. But this is the work at staff level.

So what can you actually do about this? Let me give you some concrete things.

First — expand your scope deliberately. Find one thing outside your immediate team that you can have a view on. Maybe it's the frontend platform. Maybe it's how services talk to each other. Maybe it's the onboarding experience for new engineers. Pick something and develop a real opinion about it. Then share that opinion.

Second — write more. Write design docs even when nobody asked for them. Write post-mortems. Write up your mental models. The act of writing forces you to clarify your thinking. And it gives you artifacts you can point to. A well-written doc that shapes a decision is basically proof that you're operating at a higher level.

Third — get closer to the problem, not just the solution. Talk to your PM. Talk to the customer-facing teams. Understand what the actual pain is. Because when you can connect technical decisions to business outcomes — like, "if we do this refactor, we can ship this feature three times faster and that's directly tied to the thing leadership cares about" — that's when people start seeing you differently.

Fourth — find a sponsor. Not a mentor who gives you advice, but a sponsor who gives you opportunities. Someone who will put you in a room you wouldn't normally be in. Who will say your name when an interesting project comes up. That person is really valuable and worth cultivating.

And look, I want to be honest — not everyone should be a staff engineer. Some people genuinely thrive at senior level and that's a perfectly great career. The key thing is to be honest with yourself about what you actually want.

But if you do want that next level, the thing I'd ask you to think about is: am I still doing the same job I was doing two years ago, just faster? Or am I genuinely taking on a different kind of work?

Because that's the real question. And the answer will tell you a lot.

Alright, that's episode 2. I hope that was useful. If you're working through this yourself and want to talk it through, you can find me on LinkedIn or book some time through my website at gazar.dev. I'm happy to help.

See you in the next one.