How I Think About the Staff Engineer Track

When I was a senior engineer, I thought about the staff track the way most senior engineers do: as a destination defined by scope and influence. I would become staff when I owned a larger surface area, when my decisions affected more systems, when I was trusted with the company's most technically complex problems.

That framing is not wrong, exactly. But it is incomplete in a way that causes a lot of capable engineers to stall - sometimes for years - while they try to build toward a target they have defined incorrectly.

This essay is about the model I eventually arrived at for understanding what the staff track actually rewards, and what I would do differently if I were a senior engineer today trying to level up.

The Wrong Model

The wrong model treats the staff level as "senior engineer, but for bigger things." More systems, more complexity, more influence over technical direction.

This model is wrong not because scope and influence are unimportant - they are - but because it treats them as inputs rather than outputs. Engineers who pursue scope actively often produce a specific failure mode: they become owners of systems they should not own, decision-makers on problems where they add the least value, and blockers in organizations that would be better served by distributed decision-making.

I have seen this pattern repeatedly. An engineer who is clearly ready for staff by every technical measure keeps getting passed over. Their manager gives them feedback that is frustratingly vague: "You need to increase your scope" or "Your impact needs to be felt across the organization." The engineer takes on more projects, inserts themselves into more decisions, ships more features. The promotion still does not come.

The problem is not that they are not doing enough. The problem is that they are doing the wrong things.

The Right Frame: Problems, Not Projects

The frame that unlocked the staff track for me was shifting from "projects I own" to "problems I solve for the organization."

Projects are bounded in time and scope. You start them, you finish them, you move on. A project-oriented engineer is valuable - they ship things. But organizations have problems that span years, that cut across team boundaries, that are not obviously solvable and cannot be assigned to a specific project roadmap. These are the problems that staff engineers are uniquely positioned to address.

Here is a concrete example. At one company, deployments were slow - fifteen minutes from merge to production. This was not anyone's "project." It was not on any roadmap. No team owned it. Individual teams had adapted their workflows around it: batching changes, reducing deploy frequency, accepting the latency as a cost of doing business.

A senior engineer trying to build scope might have noticed this problem and proposed a project: "Q3: Reduce deploy time to 5 minutes." They would have gotten approval, worked through the quarter, and shipped an improvement. That is valuable.

A staff engineer approaches it differently. They recognize that the slow deployment is not the problem - it is a symptom of a deeper organizational problem: the company has no shared ownership of the deployment pipeline, no forum for cross-team infrastructure concerns, and no engineer with the standing to propose and drive systemic changes to shared tooling. A project to speed up deployments does not address any of those things. It produces a faster deployment that degrades again in twelve months when no one is accountable for maintaining it.

The staff-level intervention is to solve the organizational problem - to create the forum, to establish the ownership model, to make the organization capable of solving its own deployment problems without needing a "fix the deploys" project every year.

The Three Things the Track Actually Rewards

Based on what I have seen promote people at multiple companies, the staff track consistently rewards three things:

1. Identifying the right problems. Not the most visible problems, not the problems someone assigned to you, not the problems you are best positioned to solve personally. The problems that, if solved, unlock disproportionate value for the organization. This requires knowing the business, understanding what other teams are struggling with, and having the structural patience to work on problems that might take quarters to show results.

2. Solving problems through other people. This is the one that surprises engineers the most, because it sounds like management. It is not management. It is the ability to drive an outcome by making other engineers more effective - by writing the design doc that clarifies the decision space, by pairing with the junior engineer until they can drive the implementation themselves, by building the tooling that makes a class of problems easier for everyone. The leverage multiplies across people. Your personal output matters less than the output you enable.

3. Building organizational trust. This is the most underrated of the three, and the one most difficult to pursue directly. Staff engineers are trusted with ambiguous problems precisely because the organization trusts their judgment. That trust is built slowly, through a track record of decisions that turned out to be right, through consistency between what you say and what you do, through the willingness to be honest about tradeoffs in public forums even when the honest answer is unwelcome.

You cannot fake this last one. You cannot build trust by performing trustworthiness. You build it by actually being trustworthy - which means sometimes saying "I don't know" and sometimes arguing for the slower path even when the faster path is more politically convenient.

The Sponsor Problem

One thing the career advice literature consistently underweights is the role of sponsorship. Mentorship gives you advice. Sponsorship puts your name in a room where decisions are made.

Most promotions to staff level happen because someone senior advocated for a specific engineer in a calibration or leveling conversation. Not because the engineer met a rubric, though meeting the rubric matters. Because a person with credibility in the organization said "this is the engineer we should bet on for this level."

The practical implication: knowing who your sponsor is, and ensuring they have visibility into the work that matters, is not political maneuvering. It is recognizing how organizations actually function and doing the work of making your contributions legible to the people who will speak for you.

If you do not have a sponsor, the first order of business is building the relationships that might produce one. Not through networking in the generic sense - through doing good work in collaboration with senior people who can see it clearly and who have standing in your organization to speak for you.

What I Would Do Differently

If I were a senior engineer today trying to build toward staff, here is the approach I would take, in roughly prioritized order:

Find the org's most painful unsolved problems. Not the problems people are complaining about loudest - those often already have owners. The problems that people have adapted around, that produce quiet frustration rather than loud incidents, that cross team boundaries so no one feels accountable. These are where staff-level leverage lives.

Work on one of those problems consistently. Not intermittently. Consistently. The attention span of an individual contributor tends toward "what is due this sprint." The attention span required for staff-level problems is measured in quarters. Pick something and stay with it.

Write more, in public. Design docs, postmortems, architecture decision records, team-visible channels. The staff level is only partially about what you build. It is also about the thinking that makes the organization better at building. Making your thinking visible creates the evidence that your thinking is worth trusting with a larger surface area.

Ask your manager directly what the gap is. "What would I need to demonstrate to be promoted to staff?" is a direct question that most managers can answer more specifically than the generic feedback cycle allows. If the answer is vague, push for specifics. If the answer is that you are not yet meeting the bar on a specific dimension, that is useful information.

The track is learnable. The confusion around it is largely a visibility problem - most of the work that gets rewarded at the staff level is invisible to engineers earlier in their careers, so the criteria feel arbitrary until they do not.

Once they do not, it usually seems obvious in retrospect. That is almost always a sign you are thinking about it correctly.

---

For a more operational take on this, Will Larson's "Staff Engineer: Leadership Beyond the Management Track" is the closest thing to a field guide that exists. It is worth reading before your next career conversation.