How to become a staff engineer

Becoming a staff engineer is not about writing more code or harder code. It is about increasing the scope of the problems you own and the number of people whose work gets better because of yours. The senior-to-staff jump is the first promotion where the bar stops being "can you build the thing" and becomes "can you make a team or an org build better things," often without you touching most of the code yourself.

That shift catches strong engineers off guard. You can be the best coder on your team and stall at senior for years, because the thing being measured changed and nobody told you. This post is about what the staff bar actually is, how it differs at a 30-person startup versus a 30,000-person company, and the concrete moves that get you promoted or hired in.

What does staff engineer actually mean?

Staff is the first "beyond senior" level on most engineering ladders. Senior means you own a feature or a service end to end and need little supervision. Staff means your work has impact past the boundary of your own team: you set technical direction, you de-risk the things that would otherwise sink a quarter, and you make other engineers more effective. Companies usually frame this as four axes that all have to move together.

• Scope. Senior owns a service. Staff owns a domain or a cross-team problem (the auth stack, the data platform, the migration that touches six teams).
• Impact. The work is tied to a business outcome a director cares about, not just a clean abstraction. You can name the dollars or the risk.
• Influence. You change what other engineers do through design reviews, technical strategy, and mentorship, not through your own keyboard alone.
• Judgment. You are trusted to make ambiguous calls (build vs buy, rewrite vs refactor, ship vs wait) and to be right often enough that leadership stops second-guessing you.

The trap is treating these as "senior, but more." They are a different job. Will Larson's *StaffEng* and the *Staff Engineer's Path* both land on the same point: at staff, your output is increasingly other people's output.

Senior is the last level where being a great individual coder is enough. Staff is the first where it is not.

What is the difference between senior and staff?

Here is the practical contrast, axis by axis. The left column is what got you to senior. The right column is what gets you to staff.

Notice that "coding" goes down, not up. This is the single most misread part of the jump. You do not stop being technical. You stop spending your day in the editor. The staff engineers who keep coding 90 percent of the time are usually the ones who stay stuck, because they never freed up the hours to do the scope-setting and influence work the title actually rewards.

How is staff different at a startup versus big tech?

Very different, and it matters for where you try to make the jump. At big tech, staff is a calibrated, defended level. There is a written rubric, a promo packet, a committee, and a stack of staff engineers ahead of you. The path is legible and slow: senior to staff at Google, Meta, or Stripe typically runs 2 to 4 years of demonstrated staff-level impact before a committee signs off, and the bar is partly about politics and partly about a portfolio of cross-team wins.

At a startup, there is often no rubric at all. A 40-person company might hand you "staff" because you are the third engineer and you own half the system. The scope is real but the title is loose. That cuts both ways. You can reach staff-level scope years faster, because there is more surface area than there are people to own it. But the title may not transfer cleanly: a startup staff engineer interviewing at a large company sometimes gets leveled at senior, because the calibration bars are not the same currency.

If your goal is the title fast and the scope real, a venture-backed startup right after a raise is the most direct route. A company that just closed a round has approved headcount, an urgent roadmap, and not enough senior people to own it. That is exactly the gap where staff-level scope gets handed to whoever can carry it. You can watch which companies are in that window on the roles.cc board, which sorts every role by how recently the company raised, and on the recent raises page. We go deeper on why that timing matters in should you join a startup that just raised.

How do you actually get promoted to staff?

Promotion to staff is rarely granted for a single heroic project. It is granted when leadership already treats you as staff and the title is catching up to reality. Your job is to make that reality visible. Concretely:

1. 01Find a problem bigger than your team. Pick something that crosses team lines and that a director would lose sleep over: a reliability problem, a migration everyone is afraid of, a platform gap slowing three teams. Owning this is the scope axis.
2. 02Tie it to a number. "I improved the build" is senior. "I cut CI from 22 minutes to 6, which gave 40 engineers back roughly 90 minutes a day" is staff. Quantify the impact every time.
3. 03Do the unglamorous coordinating work. The migration that did not break production is invisible when done well. Write the design doc, run the review, get the four teams aligned. That coordination is the influence axis, and it is what committees look for.
4. 04Multiply other engineers. Mentor, review, set patterns others copy. A staff packet that says "raised the level of the whole team" beats one that says "shipped a lot."
5. 05Build the paper trail. Keep a brag doc of design docs you authored, reviews you led, incidents you owned, decisions you made under ambiguity. Promo packets are evidence, and most engineers under-document their own staff-level work.

The honest limit: in a slow-growing org, the staff slot may simply not exist no matter how good your packet is. Levels are partly a budget decision. If you have done staff work for a year and the door is bolted, the faster path is often to move, not to wait. Time the move well using best time to job search software engineer.

How do you get hired in at staff level?

Getting hired as staff is a different game from getting promoted, and for many engineers it is the faster one. A new employer has no internal politics tying you to senior. They have a scope they need filled and they are leveling you on the interview and your track record. To land it:

• Lead with scope, not tenure. resume bullets should name the cross-team problem and the outcome, not the tech stack. "Owned the payments reliability program across 3 teams, cut incident rate 60 percent" reads as staff. See resume tips for startup engineers.
• Expect a system design loop that probes judgment. Staff design interviews care less about whether you know the canonical answer and more about how you handle ambiguity, name tradeoffs, and decide. Prep with startup system design interview prep.
• Target companies where the scope is sitting open. A startup 0 to 12 months past a raise often needs a staff-level person to own a domain no one currently owns. That is the cleanest hire-in path, because the level matches a real gap rather than a headcount slot you have to argue for.
• Get represented for the role, not just listed for it. A recruiter who knows the company's actual leveling can position you at staff instead of letting the resume get filtered to senior. That is the job for founders we do on the hiring side.

What if you do not actually want the management track?

Good news: staff is the individual-contributor track. Staff, senior staff, and principal are the IC ladder that runs parallel to manager, director, and VP. You can reach the same level and pay as an engineering manager without ever running a team. The two paths diverge in what you optimize: managers optimize people and process, staff ICs optimize technical direction and leverage. We compare them directly in IC vs management track for engineers.

The catch is that staff still requires leadership, just the technical kind. If you want to stay purely heads-down in the editor and influence no one, senior is your ceiling, and that is a completely respectable place to live. Staff is for people who want technical leverage without the org chart.

The summary is short. Stop measuring yourself by code volume. Start measuring by how many people and how big a problem move because of you. Then make that visible, and put yourself where the scope is already open.