Staff Engineer: Scope of Impact, Not Seniority

From the field: seven months, 64 story points

In the same quarter we had three incidents between the order team and the payments team. All three had the same root: the balance reservation. The order service released a reservation after 30 seconds. The payments service treated the same reservation as valid for 5 minutes. Orders caught in between either took the balance twice or not at all.

After each incident, the team involved patched its own side. Three incidents, three patches, and not one shared contract. The problem sat between two teams, and nobody had a desk there.

The painful part: the person who knew both services best was that staff engineer. They saw the problem after the first incident and said, “I will write something up when I have time.” That time never came. In sprint planning they were counted at 100% of the order team’s capacity. The free hours given to them were zero.

The mistake was mine. I gave the title as a reward: they wrote good code, other companies were interested in them, and I did not want them to leave. I changed the title, but not the work. For seven months they worked as the most expensive senior engineer on the team — and that was the result of my definition, not theirs.

What a staff engineer is for

A senior engineer owns a system. A staff engineer owns the gap between systems. This gap appears in every growing organisation: as the number of teams grows, so does the number of topics where nobody can answer “whose job is this?”. The staff engineer’s job is to own those topics. I group them under four headings.

1. Cross-team technical problems

These are problems no single team can solve alone: the contract between two services, retry logic written separately by three teams, a library everyone uses and nobody owns. What they have in common is that they sit in every team’s backlog as “low priority”. For any one team they really are low priority. Added together, they are not.

2. Written proposals

A staff engineer has no management authority. They cannot tell anyone “you will do it this way”. Their only tool is persuasion, and persuasion scales through writing. A two-page proposal can reach five teams at once; a meeting cannot. The structure is simple:

TITLE     : Single source for the balance reservation timeout
OWNER     : staff engineer
AFFECTS   : order team, payments team
DEADLINE  : comments within 9 days

1. PROBLEM   : what happens today? (incident count, numbers)
2. PROPOSAL  : what will change? (one paragraph)
3. OPTIONS   : paths considered and rejected, and why
4. COST      : how much work for which team
5. ROLLBACK  : how we go back if it turns out wrong
6. OPEN      : things the author does not know yet

# Rule: if "Options" is empty, it is not a proposal, it is an order.

I care most about the “Options” section. A proposal that does not list the rejected paths pushes readers to argue about the same paths again. The “Open” section is where the author admits they do not know everything. Most comments land there.

3. Invisible connecting work

This is what Tanya Reilly calls “glue work”: tracking which team holds each incident action item between two teams, drawing the system map for a new engineer, noticing that two teams use different versions of the same library. This work has no story points and no demo. So nobody rewards it, and so nobody does it.

If you do not write glue work into the staff engineer’s role, one of two things happens. Either nobody does it, or the most helpful person on the team does it and then hears “low technical output” in their promotion review. The second is worse.

To make it visible, we did something small. We added a separate “connecting work” line to the staff engineer’s weekly note. Three items, one sentence each. “Handed the payments team’s open incident action to the order team.” “Moved both teams’ HTTP client to the same version.” Each one is small on its own. Read together at the end of the quarter, the list had blocked at least two possible incidents.

4. Deciding what will not be done

In the quarter after the fix, the reporting team wanted to move to a new messaging platform. The design reached the staff engineer in a review. Technically, it made sense. The staff engineer wrote a one-page note: “Not now. Daily message volume is below 250,000; the current queue handles it. If it passes 1.5 million, we look again.” That note saved the team a six-week migration. A “no” needs a reason and a condition for looking again; I wrote about this in the no list in the technical strategy post. The staff engineer is the person who carries that list into daily decisions.

How it differs from a tech lead

A tech lead is the technical owner of one team’s delivery. They work inside the sprint, and the team’s code and technical decisions are their responsibility. A staff engineer owns the gap between teams, not a single team. The tech lead asks “how does this team deliver?”. The staff engineer asks “why are three teams solving the same problem three times?”. One person can do both, but not both full-time in the same week. I will cover this difference in a separate post.

How we chose the scope

“Cross-team problems” is a category, not a scope. Give someone a category and they look at everything and finish nothing. A scope needs a name, a boundary and a measure. We asked three questions to choose it:

1. Which incidents in the last two quarters fell between two teams? We opened the incident records. 5 of 11 incidents touched more than one team: 3 about the reservation, 2 about account statements.
2. Who already knows this area best? A staff engineer’s scope should start where their knowledge is already deep. An area they must learn from zero eats the first quarter.
3. Can the scope get smaller within a year? A good scope shrinks over time: contracts get written, and teams become able to decide on their own. A scope that never shrinks means you moved one team’s work onto the staff engineer.

In the end the scope was named “the contracts between orders and money movements”. One sentence, two teams, one measure: the number of incidents coming out of that boundary. We left statements out on purpose. Giving two scopes at once would have been a slightly more polite version of my first “look everywhere” mistake.

A staff engineer’s week

The week we fixed the title, we sat down and drew a calendar. The goal was not to lock the hours. It was to make the answer to “what do you do as staff?” visible.

WORK                                         HOURS   SHARE
------------------------------------------------------------
Sprint work (OFF the critical path)            12     30%
Cross-team problems + written proposals        10     25%
Design and code review for other teams          6     15%
Pairing and mentoring                           5     12%
Glue work (incident follow-up, docs, maps)      4     10%
Reading, thinking, free time                    3      8%

# Rule 1: Sprint work is never on the critical path. If the staff
#         engineer is on leave, no delivery date should move.
# Rule 2: The "free time" row is not deleted. Noticing cross-team
#         problems needs hours without meetings.

The first month, the table did not hold. Sprint work did not stay at 30%; it went up to 45%. This time the cause was not me; it was team habit. When a hard task came in, everyone still looked at them. The fix was simple: in sprint planning we wrote the staff engineer’s capacity as a separate line, and once that line was full, they took no new work.

How it should look, how it breaks

There is also a failure in the other direction: making the staff engineer the approval gate for every decision. If every design goes through them, teams stop deciding and the staff engineer becomes a new bottleneck. The goal is that good decisions get made without them, by looking at what they wrote.

How to measure success

In that quarterly review the question was right, but my measure was wrong. With it, I would have counted 64 story points as success.

After we opened the capacity and gave the scope, the first piece of work was the reservation proposal. Two pages, two teams, 9 days for comments, one 40-minute meeting. Six weeks later it was in production. In the next two quarters, reservation incidents were zero. In the same period, their story points dropped from 64 to 21. When I first saw that drop I felt uneasy for a moment — until I noticed I was reading it with the old measure.

We ran the absence test in that period too, without planning it. The staff engineer took two weeks off. The order team’s sprint did not slip, because they had no work on the critical path. More importantly, the payments team made a change that touched the reservation timeout in those two weeks, and asked nobody. They looked at the table in the proposal and made the right call. That is where I saw most clearly that the role worked: while they were away, what they had written was making the decision.

What to track

What did not work for me

• Giving the title to keep someone. The person stayed, but for seven months the title meant “the most senior coder” on the team. Fixing it later was harder than defining it right at the start.
• Saying “find your own scope”. In my first fix I opened the capacity but gave no scope. For three weeks they joined everyone’s meetings and owned no topic. A scope needs a name; a scope without a name means everywhere.
• A written proposal for everything. Enthusiasm was high: 14 proposals in 11 weeks, two comments each on average. We set a threshold: only decisions that affect more than one team, or that would take longer than a sprint to undo. The number of proposals went down, and more of them got read.

Checklist

Conclusion

The question I asked that Wednesday was the right one, but it came seven months late. I had decided the answer at the start: I gave them no scope and wrote them in at 100% of capacity. 64 story points was an honest output of my definition.

The staff title does not mean “you are good”. It means “this gap is yours now”. If you do not name the gap, the person goes back to what they know best: their own team’s sprint.

The test: ask your staff engineer “which problem did you own this quarter?” If the answer is a story point count, the problem is not with them. It is with you.