Most senior engineers I see trying to make staff are working on the wrong axis.
The pattern I see, on roughly half the senior engineers I have talked to about promotion: they take on harder technical projects, ship more features per quarter, become a codebase expert in three more services, and grind. A year later they are turned down for staff because their work is "high-quality but tactical". They are right that the work is high-quality. The problem is that the bar they are pushing on is the senior bar, not the staff bar, and senior excellence does not compose into staff excellence by addition.
This article is what the jump actually means, in the rubrics I have seen used at the four companies I have worked at and the half-dozen others where I have talked to friends about their promotion conversations. The specifics vary by company; the shape is consistent. If your company calls staff something else ("principal", "L6", "Senior 2"), the rubric for that level is probably the one I am about to describe.
A hedge: this is what I have seen, not the universal truth. Some companies promote on different axes. Some companies have collapsed senior and staff into one level. Treat this as the median, not as policy.
The senior bar in one paragraph
A senior engineer is someone who can be handed a project of meaningful scope, decompose it into tasks, ship it on a timeline that the team finds reasonable, and produce code that the next engineer can maintain. They mentor more junior engineers, contribute to code review, do their share of on-call. Their judgement on technical questions is trusted. The team can drop them into any service the team owns and expect competent work to come out.
The bar is high. Plenty of engineers spend a long career at senior and do excellent work. The senior label is not a rest stop on the way to staff; it is its own destination, and a lot of companies' best engineers stay there.
The staff bar in one paragraph
A staff engineer is someone who is trusted to choose what the team should be working on, technically, at a multi-quarter horizon. The judgement they apply is no longer just "can I build this thing well" but "is this the thing we should be building, and if not, what is". Their leverage is increasingly through other engineers' work, not their own keystrokes. The technical scope is broader than a single project; the time horizon is longer than a single quarter; the artifacts they produce are at least as often documents and influence as they are code.
The difference is not skill, it is axis. Senior gets harder by going deeper into the same axis (better code, better mentorship, harder projects). Staff gets harder by adding a second axis (judgement about what to build, influence on engineers outside the immediate team).
The four shifts I have actually seen
The shift from senior to staff, in concrete terms, has shown up as four changes in the kind of work I do day-to-day. Each one is the deliberate result of a different work pattern. The senior engineer who is on track for staff is doing some mix of these; the senior engineer who is not is doing more of the work that earned them the senior promotion.
Shift 1: scope expands beyond the team's roadmap
As a senior, my work fit inside the team's quarterly OKRs. As a staff, a meaningful fraction of my work did not. I was working on cross-team things: a shared library that three teams needed, an architectural decision that would shape five teams' work for a year, a debugging effort on a system my team did not own but whose failures cascaded into ours.
This was disorienting at first. Senior had a clear definition of "my work" and "not my work". Staff blurred it. The fraction of my time spent on cross-team work as a senior was about 5%; as a staff it was closer to 30%, sometimes more. Senior engineers who never start spending time on cross-team problems do not get promoted to staff because the cross-team work is the staff work.
The practical question I now ask senior engineers who want to make staff: "What is the largest cross-team problem you have driven this quarter?" If the answer is "none, my team's roadmap kept me busy", they are not on the staff path yet, regardless of how good their team-internal work was.
Shift 2: the artifacts are more documents and conversations than code
My keystroke count went down between senior and staff. I write fewer features now than I did three years ago. What I write more of: design docs, PR review comments on other people's larger PRs, notes-to-self before stakeholder meetings, written feedback to junior staff and senior engineers, and incident postmortems. The thing that scales staff work is communication and influence, and the units of those are written and spoken artifacts, not code commits.
A week of senior work, in commit-shaped units:
A week of staff work, in artifact-shaped units:
The staff week looks slower if you measure by features-shipped. It looks faster if you measure by decisions-influenced. I went through a six-month stretch as a new staff where I was anxious about how little code I was writing, until my manager pointed out that the architectural call I had made on a Tuesday meeting was going to determine the next year of three teams' work. That was the leverage that the company was paying me for.
Shift 3: the kind of mentorship changes
Senior mentorship looks like pairing on a problem, code review with helpful comments, and answering questions in Slack. Staff mentorship looks more like coaching on career, judgement, and trade-offs. The conversations are less about how to write a particular function and more about which function is worth writing.
The distinction I draw between the two: senior mentorship is targeted at the engineer's current work; staff mentorship is targeted at the engineer's growth trajectory. Both are valuable. Both are real work. Staff is judged on the second.
A shift that surprised me: the engineers I now spend mentoring time with are more often senior engineers, not junior ones. A senior trying to make staff is dealing with the same axis-shift I described in this article, and I can give them advice from one step ahead. Mentoring juniors stayed enjoyable but stopped being where my biggest impact was.
Shift 4: trust is structural, not interpersonal
As a senior, the trust I had was earned interpersonally. People who had worked with me trusted my code. New people had to learn from scratch. As a staff, the trust is increasingly structural: people who have not worked with me trust my judgement because of the title, until I prove otherwise. This is a real change in how the role functions.
The two-edged consequence: I can show up to a cross-team meeting I have never been to before, propose a direction, and have it taken seriously without first having to demonstrate competence. The cost is that my mistakes propagate further. A bad senior call costs my team a sprint; a bad staff call can cost three teams a quarter. The standard for carefulness on technical proposals went up sharply when I crossed the line, because the impact of a wrong call was now larger than my immediate visibility.
What gets you the promotion (in the rubrics I have seen)
Most staff promotion rubrics I have seen are looking for evidence of three things, weighted differently by company:
- Technical breadth and depth. You can go deep on a problem you owned, and you can speak credibly across systems you did not own. The deep examples are evidence of senior-level competence. The breadth is evidence of staff-level scope.
- Cross-team or cross-org influence. Concrete examples where your work changed the trajectory of work outside your team. The form might be an RFC that was adopted by another team, a library you built that three teams now use, an architectural decision the company committed to that started as your proposal.
- Multiplier effect. Concrete examples of work that made other engineers more effective: tooling that saved the team hours per week, a code review program that raised the team's bar, mentorship that produced a senior promotion for someone you coached.
The evidence is concrete artifacts. "I worked on X" is not evidence; it is a claim. The artifact that demonstrates it is the RFC, the postmortem, the design doc, the dashboard, the migration playbook. Promotion committees read artifacts. Engineers who do staff-level work and produce no artifacts are at a real disadvantage in the promotion conversation.
Why some senior engineers should not aim for staff
The most useful conversation I have had with senior engineers considering the jump is whether they actually want the work. The list of things that are less fun about staff than senior is real:
- More meetings. A lot more.
- More writing. Less coding.
- Slower feedback loops. A staff project might take six months to land, vs a senior feature that takes two weeks.
- More political navigation. Cross-team work involves stakeholders with conflicting priorities; senior work usually does not.
- More ambiguity. "Is this the right thing to build" is a harder question than "is this code correct".
The engineers I know who tried staff and were unhappy are the ones who loved the day-to-day of senior coding and did not want to trade it for the day-to-day of staff influencing. The title bumps were not worth the work change for them. Several stepped back to senior, which is a perfectly fine career move that some companies treat as failure and some treat as wisdom.
Before aiming for staff, ask yourself: do I want to spend more time in meetings about decisions, less time in editor windows? Do I want my impact to be measured in other engineers' output, not mine? Do I want my failures to be more visible and harder to fix? If the answer to all three is enthusiastic yes, the jump is for you. If you are saying yes for the title or the comp, the work itself will not satisfy you, and you should know that going in.
What I tell senior engineers on the path
The specific advice that has helped friends I have coached toward staff promotions, in roughly the order I give it:
Pick one cross-team problem and own it. Not as a side project. As a real artifact: an RFC, a migration plan, a shared library. Drive it from idea to outcome. This is the single biggest move you can make in the year before promotion.
Write more, in public. A weekly tech digest for your team, a RFC for every meaningful technical decision, a postmortem for every incident. Writing creates the artifacts the promotion committee will read. It also clarifies your own thinking, which is where most staff-level judgement comes from.
Spend time on engineers outside your team. Pair with a senior on another team for an hour every other week. Review RFCs from teams you do not work with. Show up to cross-team forums and contribute. The breadth I described in shift 1 only happens if you build it deliberately.
Stop volunteering for the most-fun feature work. This is the counterintuitive one. The senior engineer who keeps grabbing the meatiest feature on the roadmap is reinforcing their senior identity. The senior on the staff path lets a more junior engineer take the feature (and grow into it) and uses the freed-up time on cross-team work. Staff is a step away from the highest-leverage individual coding, not toward it.
You are choosing a job, not a label
The last frame I want to leave is that staff is a different job, not a different rank in the same job. I have watched engineers chase the title, get it, and quietly ask their manager to step back two months later because they did not enjoy the work. I have also watched engineers refuse to chase the title, stay senior happily for ten years, and be the most respected engineer on the team. Both are legitimate. Knowing which one you actually want, on the timeline of months and years rather than weeks, is the work that pays back the most. The promotion mechanics are the easy part. The match between you and the work the title describes is the hard part, and it is the part nobody asks until you are already in the role.