What a Staff Engineer Actually Does (And How to Grow One)

2026-08-11 · 11 min read · Career & Promotions

Ask five engineering organisations what a Staff Engineer is and you'll get five answers. Ask five Staff Engineers what they do all day and you'll get five different answers. This is not because the role is incoherent — it's because Staff is the first level where the job is defined by the organisation's needs rather than by a job description.

That ambiguity is the source of most of the pain around this level: engineers who don't know what they're supposed to be doing, managers who can't articulate the gap, and promotion cases that fail because nobody could explain what was missing.

Here's what the role actually is, why the jump from Senior is different in kind, and what you as a manager can do about it.

The Core Misconception

The most common way to get this wrong is to treat Staff as "Senior, but better" — a Senior Engineer who writes more code, writes it faster, and handles the hardest tickets.

That's not the job. An engineer promoted on that basis usually becomes an unusually expensive Senior Engineer who is now unhappy, because the thing they were promoted for isn't what the role rewards.

The actual shift is in the unit of work.

A Senior Engineer's unit of work is a problem. Give them something ambiguous and they will define it, solve it, and ship it well. That's already a significant capability — most of the journey from junior to senior is about developing it.

A Staff Engineer's unit of work is a class of problems, usually one that nobody assigned. They notice that four teams are independently solving the same thing badly, or that the architecture has drifted somewhere that will be expensive in eighteen months, or that a decision being made this quarter will constrain the org for years. Then they do something about it — which typically involves convincing a lot of people rather than writing a lot of code.

The clearest way to put it: a Senior Engineer solves the problem in front of them. A Staff Engineer changes which problems are in front of everyone.

What Actually Changes

Three things shift, and all of them are uncomfortable for engineers who were promoted on technical excellence.

Influence replaces authority. A Staff Engineer typically has no direct reports and no formal power over anyone's roadmap. Everything they accomplish beyond their own keyboard happens by persuading people who don't report to them. Engineers who were excellent because they could out-think a problem often struggle here, because the bottleneck is no longer thinking.

The feedback loop gets much longer. Senior work has a satisfying rhythm — ship something, see it work, repeat. Staff work often means spending six months on a migration whose benefit is that nothing bad happens, or advocating for a technical direction that pays off after you've moved on. The absence of frequent, legible wins is one of the main reasons people bounce off this level.

Writing becomes a primary skill. At Staff, the design document, the RFC, and the technical strategy memo are the work product — not artefacts of it. Ideas that aren't written clearly don't propagate beyond the meeting they were mentioned in. A Staff Engineer who can't write well is capped, regardless of technical depth.

The Four Shapes of the Role

Because the role is defined by organisational need, it takes different shapes. The taxonomy that's become standard across the industry describes four, and it's genuinely useful — mostly because it lets you and your engineer name which one they're actually being asked to be.

The Tech Lead runs the technical direction of a team, usually alongside an EM. Closest to what most people picture. Distinct from the Tech Lead role in a smaller team in that the scope is deeper and the technical strategy is genuinely theirs.

The Architect owns the design of a critical area across teams — the data platform, the API surface, the service boundaries. Deep domain context, long time horizon, lots of consultation.

The Solver is deployed at whatever is currently on fire or intractable. High autonomy, moves between problems, rarely owns anything permanently. Valuable and hard to develop deliberately, because the role is essentially "be trusted enough to be sent anywhere."

The Right Hand operates at the org level alongside a senior leader — carrying technical strategy across multiple teams, sitting in leadership discussions, doing the thinking a VP doesn't have time for. Usually the rarest and most senior-adjacent shape.

The practical value of this taxonomy isn't classification for its own sake. It's that most confusion about "what does Staff mean here" dissolves once you name which shape your organisation actually needs. An engineer optimising to be an Architect in an org that needs a Solver will feel like they're doing everything right and getting nowhere.

How to Develop Someone Toward Staff

You cannot promote someone to Staff and then have them start doing Staff work. Every functioning promotion at this level ratifies something that already happened — which means your job starts one to two years before the case is written. See writing a promotion document that gets approved for the mechanics of the case itself; what follows is how to make it true in the first place.

Give them problems with no owner. The defining Staff behaviour is picking up the important thing nobody has been assigned. You can't develop this by assigning it — that just makes it a project. What you can do is stop assigning them things, deliberately, and see what they pick up. Then create the space for them to pursue it.

Sponsor, don't just mentor. Mentorship is advice. Sponsorship is spending your own credibility to put someone in a room they wouldn't otherwise be in, and letting them own something visible enough to fail at publicly. Staff-track engineers need the second far more than the first. Concretely: get them into the architecture review, have them present the technical strategy rather than presenting it yourself, name them as the decision-maker in front of other teams.

Push them toward writing. If they're not writing design docs and RFCs that circulate beyond their team, they are invisible at the level where the promotion decision gets made. This is often the single highest-leverage gap, and it's very fixable — most engineers write badly because they've never received real feedback on their writing, not because they can't.

Make them work through disagreement. The skill that most reliably separates Staff-ready engineers is landing a technical direction when a smart, senior person disagrees with them. Look for opportunities where they have to build consensus rather than being handed it. If they've never had to change someone's mind, they're not ready, however strong the technical work.

Give them exposure to consequences at scale. Involvement in incident review, capacity planning, and the aftermath of architectural decisions made three years ago. Staff judgment comes from having seen how decisions age.

The Problem Nobody Talks About: No Room at the Top

Here's the situation that causes more good-engineer attrition than any other at this level: you have someone genuinely operating at Staff, and there is no Staff position available.

This happens constantly at companies under a few hundred engineers. The honest arithmetic is that most organisations need roughly one Staff-level engineer per five to eight Senior engineers, and many need fewer. If your team has three people who could plausibly be Staff, at least two of them aren't getting there here.

The failure modes, in descending order of how common they are:

Stringing them along. "Keep doing what you're doing and we'll revisit next cycle" — indefinitely. This is the worst option and the most common, because it defers a hard conversation. Engineers work it out eventually, and they leave with a much worse impression than if you'd been honest.

Inventing the role without the scope. Giving the title to retain someone, without an actual org-level problem for them to own. They now have a Staff title and Senior work, which satisfies nobody and devalues the level for everyone else.

Being honest. "You're operating at this level. There isn't a role here in the next year, and I don't want to pretend otherwise. Here's what I can do: sponsor you into higher-visibility work, back you fully if you want to look externally, and be a strong reference. If a role opens, you're first."

The third one costs you some people. It also produces engineers who stay longer than they otherwise would, because being told the truth about your ceiling is rare enough to generate real loyalty. The alternative — discovering in an exit interview that they'd been waiting eighteen months on a promotion you knew wasn't coming — costs you the person and the reputation.

Staff vs. Management

This fork usually arrives around the same time, and managers frequently give bad advice on it because they've only walked one path.

Two things worth being clear about with your engineer:

It's a genuine fork, not a hierarchy. Staff and EM are parallel, not a promotion ladder where management is higher. Organisations that treat management as the senior path end up with reluctant managers and capped ICs, both of which are expensive.

The decision should be about what you want to spend your days doing, not which is more prestigious. The honest framing: management means your output is your team's output, and you will spend most of your time on people and coordination rather than technical problems. Staff means retaining depth and autonomy, with a much longer feedback loop and no formal authority. Both are hard in different ways.

Someone who wants Staff because they don't want to deal with people problems has misread the role — influence without authority involves more interpersonal work, not less, just of a different kind.

What Good Looks Like

You know someone is operating at Staff when:

The last one is the real test. A Staff Engineer's most valuable output isn't the solution — it's the judgment about what was worth solving. If you find yourself repeatedly surprised and then convinced by what they've decided to work on, they're already doing the job.

Emtricks lets you log impact stories and track career development over the multi-year horizon a Staff case actually requires. Try it free for 30 days.