I spent years trying to become the best coder on my team. And it worked — right up until it became the thing holding me back.
Here's what nobody tells you about the Senior-to-Staff jump: it's not a skills upgrade. It's an identity crisis.
The Ceiling Nobody Warns You About
After 5-8 years of grinding, most developers reach Senior and feel like they've made it. You're fast, you're reliable, you solve hard problems. Your PRs are clean. You're the person people come to when something's broken.
Then you stay there. For years.
According to levels.fyi data, the median time at Senior before reaching Staff is 4-6 years — but many engineers never make the jump at all. The drop-off is steep: most companies have 3-5x more Seniors than Staff engineers.
The common assumption is that you need to be even better at coding. Write even more elegant solutions. Ship even faster. But that's exactly the trap.
The Identity Problem
When "I'm the best coder in the room" is your identity, you optimize for the wrong things. You take on the hardest implementation work yourself instead of delegating it. You solve problems at the code level when the real issue is architectural. You measure your value by your personal output.
Staff engineers get promoted for a fundamentally different skill: making everyone else more productive.
That means writing the document that prevents three teams from building the same thing. Running the design review that catches a scaling problem before it ships. Saying "we shouldn't build this at all" when everyone's excited about a feature.
What Actually Changes
The shift looks something like this:
Senior mindset: "I'll implement this complex feature myself because I can do it fastest."
Staff mindset: "I'll design the system so a mid-level engineer can implement it safely, and I'll focus on the parts that affect three other teams."
Will Larson's Staff Engineer book surveyed hundreds of Staff+ engineers. The consistent pattern: they stopped being the person who writes the most code and became the person who ensures the right code gets written.
This isn't about writing less code. Plenty of Staff engineers still code daily. It's about choosing where your code has the highest leverage. A week spent on a shared library that eliminates duplicated work across five teams is worth more than a month of heads-down feature work.
The Uncomfortable Part
Letting go of your identity as "the best coder" feels like losing something. You spent years building that reputation. Your confidence is rooted in technical skill. Walking into a room and not being the person with the cleverest solution feels... wrong.
But the engineers who plateau at Senior are almost always the ones still measuring value by personal output. I've seen it play out dozens of times. Brilliant engineers, stuck for years, because they kept doing the thing that got them promoted last time.
How to Actually Make the Shift
Three things that work:
1. Track your multiplier effect. Instead of "I shipped feature X," start thinking "I unblocked 4 engineers this week" or "my RFC prevented a 3-month rewrite." If your impact disappears when you take a vacation, you're not operating at Staff level.
2. Volunteer for the unglamorous work. Design documents. Oncall improvements. Cross-team coordination. Migration plans. This work is invisible and boring and it's exactly what differentiates Staff engineers.
3. Develop opinions about systems, not just code. Staff engineers have strong, well-reasoned views about architecture, team structure, and technical direction. Not "this function should use a map instead of a loop" but "this service boundary is wrong and here's why it'll cause problems in 6 months."
The hardest part isn't learning new skills. It's letting go of the identity that got you here. But on the other side of that discomfort is a career that scales — one where your impact isn't limited by how many hours you can personally code.
Top comments (0)