The Identity Shift

Documentation

The Identity Shift

The most important thing to understand about the Staff Engineer level is that it marks a change in identity, not just in scope or compensation. What made you a great Senior Engineer — your ability to own a problem end-to-end, to ship reliably, to go deep — is still valuable. But it is no longer sufficient, and it is no longer the primary measure of your impact.

At the Senior level, success looks like: you understood the problem, you executed well, and you shipped something that worked. The value you created was largely visible in what you personally produced.

At the Staff level, the question changes. The most important thing you can ask yourself is not “What did I build?” but “What did I make possible?”

Your impact is now measured in other people’s output — in the quality of decisions made by engineers who worked near you, in the systems that didn’t get built incorrectly because you asked the right question at the right time, in the junior engineer who is now a Senior because you paid attention to their growth.

This is a difficult shift for most engineers. We became engineers because we love building things. The identity of “someone who writes code and ships features” is comfortable and legible. The identity of “someone who raises the collective capability of a team” is harder to hold onto, especially on days when your calendar is full of conversations and your commit history is sparse.

Lean into the discomfort. That’s the growth.

What the Transition Feels Like

Nobody talks about this enough, so let’s be direct: the transition to Staff often feels worse before it feels better.

The feedback loops get much slower. As a Senior Engineer, you had a tight loop: write code, see it compile, ship it, watch it work. Every day had a small signal that you’d done something. At Staff level, much of your work — mentoring, strategy, influence, alignment — has feedback cycles measured in weeks or months. You might spend a whole day in conversations and leave wondering whether you accomplished anything. That feeling is normal. It does not mean you’re failing.

The coding identity takes a hit. You may find yourself writing significantly less code than you did six months ago, and that can feel like loss. If you’ve spent your career building an identity around being a strong implementor, stepping back from implementation can feel like giving up the thing that made you you. It’s worth recognizing this for what it is: grief for a version of the role that you’ve outgrown. The skills you built aren’t gone — they’re the foundation underneath the new work. But the new work looks different, and that takes time to accept.

Imposter syndrome intensifies. The ambiguity of the Staff role — no one telling you what to work on, no clear daily output to point to, sitting in rooms with Directors and VPs — makes it easy to feel like you don’t belong. Many Staff Engineers privately worry that they were promoted by accident, or that someone will eventually notice they’re not “doing enough.” This is nearly universal, and it’s worth naming: if you feel it, you’re not unusual. You’re just in a role where the markers of success are harder to see.

None of this is a sign that the role isn’t for you. It’s a sign that the role is genuinely different, and that you’re still growing into it.

Further Reading

Larson describes this transition as replacing the visceral coding REPL with the uneven progress of mentorship, relationship building, and strategy — a shift that initially trips most people up (Staff Engineer, “Operating at Staff”). Reilly puts it more directly: at this level, you should be telling your manager what’s important just as much as the other way around (The Staff Engineer’s Path, Chapter 1).

Choosing Where to Spend Your Time

At the Senior level, the work mostly comes to you — through sprint planning, tickets, and your manager’s guidance. At Staff level, nobody hands you a perfectly scoped problem. You are responsible for identifying where your time creates the most leverage, and for defending that time against the pull of easier, more visible, less important work.

The failure mode here has a name: snacking. Snacking is the tendency to gravitate toward small, low-risk, immediately rewarding tasks — answering Slack questions, reviewing easy PRs, attending meetings where your presence is comfortable but not necessary — while the harder, more ambiguous, higher-leverage work goes untouched. Snacking feels productive. It fills your day and keeps you visible. But it doesn’t move the needle.

The antidote is to regularly ask yourself: “If I could only do one thing this week, what would create the most lasting impact for the engineers and systems around me?” The answer to that question is rarely the most comfortable task on your list.

Further Reading

The “snacking” framework and the broader question of how to choose high-leverage work are covered in depth in Larson’s Staff Engineer, “Work on What Matters.” If you find yourself struggling with where to spend your time, start there.

What This Means in Practice

Make implementation go better for everyone around you. You are no longer the primary implementor — you are the person who ensures the team builds the right thing, the right way.
Let your hands-on coding decrease when higher-leverage work needs your attention. That shift is a feature of the role, not a bug in your performance.
Invest in your judgment, your communication, and your influence. These are now your primary tools — more so than your typing speed or your ability to go deep on a single problem.
Actively shape how the engineers around you think and work. Set direction, raise the bar in reviews, model what good decision-making looks like. This is the core of the role.
Decide what matters. Nobody is going to hand you the right problem. Build your own map of where your time creates the most leverage, and then validate it with your manager and your peers.

The Archetypes