What a staff engineer does all day

"Staff engineer" is the most poorly-defined common title in the industry. It means different things at different companies, and even within one company two staff engineers may do almost nothing in common.

Here is an attempt at what the role actually is, based on watching people do it well.

what it is not#

Not "a senior engineer who has been there longer." Time in seat produces a senior engineer with more context, which is valuable and is not this.

Not "the best coder." The highest-output individual contributor is a valuable role and it is a different one. Staff engineers frequently write less code than seniors.

Not "a manager who did not want to manage." The scope is comparable to a manager's; the mechanism is entirely different.

what it is#

The concise version: a staff engineer is responsible for the technical success of work that spans more than one team, without having authority over those teams.

Everything distinctive about the role follows from "without authority." You cannot assign work. You cannot approve headcount. You cannot make a decision stick by deciding it. Every outcome has to be achieved through information, credibility, and persuasion.

the actual activities#

Finding the problem nobody owns. The most common form of staff-level impact. Every organization has problems that fall between teams: the shared library nobody maintains, the integration that fails and each side thinks is the other's, the performance issue that is caused by the interaction of three services.

Nobody owns these, so nobody fixes them, so they persist for years. Identifying one, proving it matters, and getting it fixed is a substantial contribution and it usually requires a person who is not on any of the teams involved.

Making a decision that spans teams. Which of three approaches, when each team has a preference and none of them can see the whole picture. This is where the "no authority" constraint bites hardest: the decision has to be made in a way that the people affected accept, which means the reasoning has to be visible and the objections have to be genuinely addressed.

Writing the document that ends the argument. A recurring disagreement that resurfaces every quarter because nobody wrote down the resolution. One good document — with the options, the trade-offs, the decision, and the reasoning — can end a multi-year debate.

Being the person who read the whole system. Most engineers know their team's code. Somebody needs to know how it all fits together, including the parts nobody has touched in three years. That knowledge is what makes the cross-cutting problems visible.

Raising the floor. Not by writing better code. By making the good pattern easy: a library that removes a class of bug, a template that encodes the right defaults, a lint rule that prevents the mistake, documentation that means nobody has to ask. Impact through leverage rather than output.

Mentoring, specifically on judgment. Not "how do I use this API." "Should we build this at all," "how do I disagree with my manager about a technical decision," "how do I tell if this design will be a problem in a year."

Saying no with a reason, at a level where it lands. Frequently the most valuable thing a staff engineer does, and the reason it requires seniority is that the no has to come with an alternative and with credibility behind it.

the day, concretely#

A real week looks roughly like:

• 20% writing code, usually the hard or risky part of something, or a prototype that settles an argument.
• 25% writing documents — designs, decisions, analyses, postmortems.
• 25% in conversations — reviews, one-on-ones, arguing about designs, being asked "does this seem right to you."
• 15% reading — code, incident reports, other people's designs, the thing everyone is complaining about.
• 15% on whatever is currently on fire.

The proportion of coding is the part that surprises people moving into the role, and the discomfort of not shipping visible code is the most common reason people bounce out of it.

how to tell if someone is good at it#

Do things get decided? Not "do they have opinions." Do arguments they are involved in reach a resolution that holds.

Do other engineers get better? Look at the people around them over a year.

Do they work on things nobody asked them to? The highest-value staff work is usually self-directed, because if it were obvious and assigned it would already have an owner.

Are they trusted by people who disagree with them? This is the real test. Someone who is only trusted by people who already agree has influence, not credibility.

the failure modes#

Becoming an architecture astronaut. Designs, diagrams, opinions, no contact with running code. The credibility runs out within about a year, and it is very hard to get back.

Becoming a very expensive senior engineer. Doing excellent work with single-team scope. Comfortable, valuable, and not the job.

Spreading too thin. Involved in twelve things, effective in none. The scope is tempting and the constraint is real: two or three significant efforts at a time is the realistic maximum.

Losing the ability to build. The role requires enough hands-on work to stay credible and calibrated. An engineer who has not shipped in a year is guessing.