How to Become a Staff Engineer: Scope, Influence and the Promo Case

Doing more of the same work is unlikely to get you promoted to staff on its own. Public career ladders describe staff by the size of the problems you own, not by how many tickets you close.

If you want to know how to become a staff engineer, start with that shift. A senior engineer who ships twice as much for one team is still working at one team's scope. The next level asks for work that changes several teams at once.

Picture a common setup. A product company in Bengaluru has about twelve engineering teams, and four of them call the same payments partner. The setup is made up, but it is the kind of problem career ladders describe.

Each of those four teams wrote its own retry code. On a busy sale evening, retries sent the same charge twice and some customers paid double (made up). A senior engineer on the checkout team fixed checkout's retries in two days. That was good, fast output.

Three other teams still had the same bug. Nobody owned the problem across teams, so it waited for the next incident. This guide follows that gap from the bug to a promotion case.

Career documents use a small set of words again and again. Learn these eight now and every later section will read easily.

• Career ladder: a written guide that says what each level is expected to do. Some companies call it a career framework.
• Level: one rung on that ladder, sometimes written as a code such as IC4 or IC5. IC stands for individual contributor, an engineer who does not manage people.
• Scope: how much of the company your work changes, such as one team, several teams or a product area.
• Staff-plus: the staff level and the levels above it, such as senior staff and principal. Will Larson uses this term on staffeng.com, his site about the role.
• Promotion packet, or promo packet: a short document that makes your case for the next level with evidence.
• Sponsor: a senior person who speaks up for your work in rooms you are not in. For a staff promotion this is usually your manager.
• Calibration: a meeting where managers compare people across teams to keep ratings and promotions consistent. Names and steps vary by company.
• Glue work: the less visible work that keeps a team moving, such as unblocking people and reviewing designs. In her talk Being Glue, Tanya Reilly says: "I call all of this glue work."

Many public ladders ask a staff engineer to set technical direction across several teams, over a year or more. Coding still matters, but those level statements lead with scope and strategy. Not every ladder agrees, as the table below shows.

Dropbox publishes its engineering career framework on GitHub Pages. Its IC4 Software Engineer statement says, in the first person, that you deliver impact across a team, product capability or technical system. The next level up is IC5, titled Staff Software Engineer.

The IC5 statement begins: "I set the multi-year, multi-team technical strategy." It continues that you deliver it through direct implementation or broad technical leadership. Read the two statements side by side and the jump is plain: one team becomes many teams, and quarters become years.

The table shows a real difference between companies. GitLab's staff bullets mostly say "your team", while Dropbox asks for multi-team strategy. The Razorpay listing also mentions a long-term technology vision for your organisation and team.

So read your own company's ladder before anyone else's. The same staff title can carry different scope at different companies, and level codes such as IC5 are company-specific.

Output is how much you produce. Scope is how far your work reaches. A staff case needs both, but scope is the part a promotion meeting checks most closely.

Go back to the payments setup. The senior fix changed one team's code. The staff move starts with a question nobody had asked: do the other three teams have the same bug?

Pause and predict before you read on. Which part of the staff move do you think takes the most time: the code, or getting four teams to agree?

In this setup, agreement is the slow part. Larson's chapter Operating at Staff makes a similar point: much of staff work "has a much slower feedback cycle" than writing code. Here is the full chain the engineer runs.

An idempotency key is a unique ID sent with each payment request. If the same key arrives twice, the receiver knows it is a repeat and does not charge again. Here, the hard part is not the idea but getting all four teams to use it the same way.

Here is one picture for the whole shift. A senior engineer is like the best cook in one restaurant kitchen. A staff engineer is like the person who notices every branch burns the same dish, writes one recipe card, and gets all the kitchens to use it.

The cook maps to your team's code. The recipe card maps to the design doc. The branches map to the other teams, each with its own head chef, who is that team's owner.

Where the picture breaks: a recipe card can be imposed from head office. Staff engineers usually cannot order other teams to do anything, so the card only works if each kitchen agrees it is better.

Staff engineers spend much of their week on direction, people and decisions, with less time on their own code. Larson's guide What do Staff engineers actually do? names a shared base across all four archetypes.

• Setting and editing technical direction: choosing which technical bets the company makes, and correcting them as facts change.
• Sponsorship and mentorship: growing other engineers. The guide calls sponsorship, actively advancing someone's career, the more valuable of the two.
• Injecting engineering context into organisational decisions: joining planning talks early, while the outcome can still change.
• Exploration: taking on ambiguous, important problems that the current systems are not built to handle.
• Being glue: doing the less visible work that keeps teams shipping, following Tanya Reilly's term.

Larson's guide Work on what matters warns about two traps. Snacking is picking easy, low-impact tasks because they feel productive. Preening is low-impact work that happens to be highly visible.

The same guide points to better targets. Existential issues, problems that threaten the company, come first. Finishing a stalled project counts, because "We only get value from finishing projects." Small edits that change a project's direction count too.

Will Larson describes four common shapes of the staff role: Tech Lead, Architect, Solver and Right Hand. They are his framing from staffeng.com and his book Staff Engineer, not an industry standard.

Larson calls his list "more focused on being useful than complete." He writes that most companies emphasised one or two of the patterns. He describes the Right Hand role showing up as an organisation reaches hundreds of engineers.

Some ladders borrow the idea directly. Dropbox's archetypes appendix lists Technical Lead, Architect and Solver, and says it is heavily inspired by Larson's book. It also says the archetypes are not a checklist and that engineers often blend them.

Use the archetypes to ask a practical question: which shape does my company reward, and which one fits how I like to work? The answer shapes which projects you should go after.

They influence through trust, written proposals and early conversations, not through authority. Larson's chapter Operating at Staff quotes Katie Sylor-Miller on a common belief: that staff engineers control their work and others simply comply. Her verdict is that this is "absolutely the opposite of what happens!"

In the payments setup, the engineer cannot order three other teams to change their code. What works is making the change cheap and the reasons clear for each team owner.

• Talk to each team owner before the big review. Larson's guide Present to executives calls this nemawashi, sharing a draft early so nobody is surprised in the meeting.
• Lead with the conclusion. The same guide suggests SCQA: Situation, Complication, Question, Answer. State the situation, the problem, the question it raises and your recommended answer.
• Bring a proposed answer with every problem you raise. A problem with no proposal gives the room nothing to agree on.
• Gather feedback in the meeting and judge it later. Defending every point live costs trust.
• Accept a decision that goes against you for now. Decisions are often revisited, and the relationship lasts longer than the meeting.

Here is an SCQA opening for the payments design doc. Situation: four teams call the same payments partner with their own retry code. Complication: retries charged some customers twice last month (made up). Question: how do we stop duplicate charges everywhere? Answer: one shared idempotency-key rule and library.

What just happened? Four short sentences told a busy reader the whole story. Anyone who reads only that paragraph knows the problem and the proposal.

Writing is how one engineer's thinking reaches many teams at once. A design doc can be read by forty people (made up), while a hallway chat reaches two.

Larson's guide Writing engineering strategy says when a design doc is worth writing. Write one for a project that many future projects will build on, one that meaningfully affects users, or any work over a month of engineering time.

Dropbox's IC5 page points the same way. One bullet says that, if asked, you write crisp narratives to create understanding and enable decisions. That is the same skill the SCQA opening practises.

1. 1

   Write design docs for real projects

   Start from the problem, not the solution. Larson advises that if solutions are not obvious, you should spend more time clarifying the problem.

2. 2

   Write five, then look for patterns

   Larson suggests writing five design docs and pulling out what they share. Decisions that keep coming up become an engineering strategy.

3. 3

   Write the strategy with its reasons

   A good strategy guides trade-offs and explains why. Larson's cue to write one is rehashing the same discussion three or four times.

4. 4

   Combine strategies into a vision

   Larson suggests combining about five strategies into a one-to-two-page vision that looks two to three years ahead.

5. 5

   Judge the vision by later docs

   Compare a design doc from two years ago with one from last week. Clear improvement means the vision is working.

Notice the order. Strategy comes from real design docs, not from a blank page. That keeps a staff engineer's direction tied to problems teams actually have.

You build it as a written promotion packet that you start long before the promotion cycle. Larson's guide Getting the title where you are calls the packet "your foundational tool to demystify the Staff promotion."

His separate guide Promotion packets suggests seven sections. The table pairs each with a made-up entry from the payments setup, so you can see the level of detail that helps.

The gaps row is the bravest one, and probably the most useful. Naming a gap first lets you and your manager plan work that closes it before the meeting.

The writing process Larson recommends

1. 1

   Answer why you want it

   The guide quotes Michelle Bu's warning about pattern matching towards work you do not enjoy. Staff is a different job, not a reward.

2. 2

   Set expectations

   Promotions at this level build over quarters and years. The guide tells you to avoid expecting instant results.

3. 3

   Write a fast first draft

   Spend about an hour getting everything down. Do not polish yet.

4. 4

   Edit after two days

   Wait two days, reread, then edit for content, clarity and context.

5. 5

   Ask peers, then your manager

   Peers, ideally already staff-plus, often see your strengths better than you do. Then ask your manager to focus on gaps and on projects that would close them.

Keep the packet alive. The guide suggests reviewing it in career-focused one-on-ones, not just at review time. Revisit it when your manager changes, so your progress does not walk out of the door with them.

A simple way to check it is working: after each one-on-one, can you point to a row that changed? If the gaps row has stayed the same for two quarters, raise it directly.

Your manager usually argues the case, and more senior leaders decide it in a calibration or promotion meeting. Exact steps differ by company, so ask your manager how yours works.

Larson's guide Find your sponsor says the sponsor for a staff promotion is usually your direct manager. They take your draft packet, turn it into the company's format and advocate for you in calibration.

Your manager's manager matters too. Larson's guide Being visible says these leaders tend to be in the room that approves staff-plus promotions, and rarely support people whose work they do not know. Find your sponsor adds that your skip-level should remember your work two months later.

The sponsor guide also gives two questions worth asking your manager. "If I don't get promoted this cycle, what are some of the likely causes?" And: what is the most effective thing I can do to become a stronger candidate?

Do you need a staff project?

Not always. Larson's guide Staff projects describes one as complex, ambiguous, with divided stakeholders and visible failure. It says most engineers do not complete one on the way to staff, though a large minority do.

The same guide warns that some companies treat a staff project as an unwritten soft gate in promotion meetings. Early packet feedback is how you find out. Scope can also grow: one Dropbox engineer's six-month estimate became eighteen months.

Most people in Larson's sample got it where they were, but not all. He writes that "About two-thirds of the Staff engineers I surveyed" were promoted at their company, and the rest switched to get the title.

That figure comes from the staff engineers Larson surveyed himself, not an industry-wide study, so treat it as a rough signal. He also writes that some people get promoted one or two cycles later than they expected, and some never do at their current company.

Switching can make sense when your company has few staff roles or no clear ladder. Larson notes that even the best-laid plans can falter at the wrong company. A move also brings a staff interview loop, covered in the interview section below.

Is the title worth it? Larson's guide Does the title even matter? collects both sides. Staff engineers there describe more respect from the start and a seat in higher-level discussions. It also says the title will never do as much work as you would expect.

The common mistakes are choosing the wrong work and keeping the evidence in your head. Each row below is drawn from the staffeng.com guides and Reilly's talk cited above.

Show it by designing for several teams and for change over time, not just for one service today. Larson's guide Staff-plus interview processes lists what staff loops often include.

• A structured presentation of twenty to thirty minutes on a narrow topic, given to a group of peers.
• A code review of a prepared pull request.
• An architecture and system design interview, typically focused on evolving a system to meet changing requirements.
• A subject matter interview on your area of expertise.
• A mentorship panel of three to four people you might mentor, who come with questions.

The phrase "evolving it to meet changing requirements" is the hint. In a staff design round, how you would migrate, roll out and get teams to agree matters as much as the boxes on the whiteboard. The guide System Design Interview Levels shows the same question answered at junior, senior and staff level.

1. 1

   Name who the system serves

   List the teams and users it touches. For the payments setup: four product teams, the payments partner and on-call engineers.

2. 2

   State the requirement that will change

   Say what is likely to change next year, such as a second payments partner. Design so that change is cheap.

3. 3

   Give the design and its trade-offs

   Draw the shared idempotency layer. Say what it costs, such as an extra lookup on every payment request.

4. 4

   Plan the migration

   Explain how existing teams move over one at a time, and how you roll back if a team hits a problem.

5. 5

   Say how you would measure success

   Pick one number, such as duplicate charges per month, and say who watches it.

6. 6

   Say what you would write down

   Mention the design doc and the decision record, and who reviews them. That shows how the decision outlives the meeting.