Somewhere around year eight or nine, the question stops being hypothetical. Both paths are available. The organisation is large enough that both exist as genuine roles, not just titles. You have to actually decide.
I’ve been close to this decision twice. The first time, at the startup, it was resolved by circumstance — there was no EM role to take, so staff-track it was. The second time, in a larger organisation, it was a real choice. Here’s the framework I used and what I’d change about it.
What the Paths Actually Are
The usual description: Staff Engineer is technical leadership without people management; Engineering Manager is team leadership with people management. Both true, both incomplete.
The more useful description:
Staff Engineer is fundamentally about technical scope and influence. You’re accountable for the technical quality and direction of a system or domain that’s too large or complex for a single team to own coherently. Your job is to hold the conceptual integrity of that system across team boundaries — making architectural decisions, identifying technical risks before they become incidents, and ensuring that independent teams’ technical choices compose correctly.
Engineering Manager is fundamentally about team health and output over time. You’re accountable for the people in your team: their growth, their effectiveness, their alignment with organisational goals. Your job is to make the team perform better than the sum of its parts — by hiring well, removing blockers, maintaining clarity about priorities, and developing the individuals.
Both roles influence technical outcomes. The difference is the primary lever: the staff engineer’s lever is technical judgment and its propagation; the EM’s lever is the team’s capacity and direction.
The Thing Nobody Tells You About EM
Management is a full-time job that looks like it should be part-time. In a healthy organisation, you’re not fighting fires constantly — you’re having one-on-ones, thinking about team structure, reviewing career progressions, attending cross-functional meetings, and doing the ambient work of keeping a team functional.
This work is invisible when it’s done well. Nobody notices that a potential conflict between two engineers was resolved in a one-on-one before it became a team dynamic problem. The absence of dysfunction isn’t celebrated.
The implication: engineers who move into EM roles expecting to continue coding at any significant capacity are usually wrong about the equilibrium. Some coding is possible; 40% coding is not realistic unless your team is very small or your organisation is unusual. The mental model of “EM who codes” usually resolves to “underprepared manager” within six months.
The Thing Nobody Tells You About Staff
Technical leadership at the staff level is largely a coordination and communication job with a technical premise.
You are not, primarily, writing code. You are writing RFCs, reviewing designs, sitting in architecture discussions, and translating between technical decisions and business requirements. The value you add is judgment — accumulated understanding of the technical landscape, the failure modes of various approaches, the organisational dynamics that affect technical outcomes — not keystrokes.
Engineers who move to staff expecting to be “senior senior senior engineer, but with scope” often find the actual job is closer to what they assumed EM would look like: a lot of meetings, a lot of writing, and more time spent on others’ work than their own.
The coding instinct doesn’t disappear. It has to be redirected: writing the prototype that proves a concept, writing the design doc that shapes six months of team work, writing the postmortem that changes the organisation’s approach to a class of problems. High-leverage writing, not high-volume writing.
On Reversibility
The conventional wisdom: EM is harder to reverse than staff. If you go EM and decide you want to go back to IC, you’ve lost two or three years of hands-on technical depth. Staff to EM is a known path; EM to staff is rarer and harder.
My experience: partially true, overstated as a general rule.
Technical depth is not a static resource that depletes. It’s a skill that atrophies without practice but can be rebuilt. I’ve seen EMs go back to IC roles successfully; the recovery period is real but measured in months, not years, for someone who was strong before the EM stint.
What’s actually harder to reverse: the organisational position. As an EM at a large company, you have context, relationships, and credibility in a specific organisational position. Going back to IC means joining a different part of the hierarchy where that context and those relationships don’t transfer. This is not about skill — it’s about organisational capital, which is domain-specific and doesn’t transfer.
What I’d Tell Someone Facing the Choice
Ask which problems you find genuinely interesting, not which role sounds better in the abstract.
If debugging a complex distributed system failure, designing a data model that’s elegant and performant, or writing a technical doc that changes how your organisation builds something — if these feel like intrinsically interesting problems, the staff track probably fits.
If understanding why a specific engineer isn’t performing, designing a process that makes the team more effective, or having the conversation that aligns two people who are pulling in different directions — if these feel interesting rather than draining, the EM track probably fits.
Neither path is superior. They’re different work. The question is which work you want to be doing in five years.
The mistake is optimising for status (which path has better compensation or title) rather than fit (which path uses the capabilities you have and want to develop). Status optimisation leads to people in the wrong role, which is expensive for the organisation and miserable for the person.
I’ve seen excellent staff engineers who would be mediocre managers, excellent managers who would be frustrated staff engineers, and a small number of people who could genuinely do either well and whose choice was arbitrary. Know which category you’re in before you decide.