Every company measures how many features an engineer shipped. Few measure how much that engineer raised the capacity of the people around them. That second measurement is where the Staff Engineer shows up, and performance reviews leave it out.
Any given week
- An afternoon reviewing a new service's architecture with two seniors, ahead of three weeks of rework
- One hour in a 1:1 with a senior stuck on a design problem, unblocking two sprints of work
- A morning writing a decision guide for a recurring pattern that eight engineers use through the half-year
- Half a day running an incident review and turning the failure into a process change
None of the four counts as a delivered feature. All four change what the team can do the following week.
Patterns as the main job
Without a written pattern, every engineer decides alone how to organize code, log, structure tests and version APIs. The sum becomes inconsistency that shows up in code review, onboarding and maintenance, and leaves with each new hire.
A pattern settled once returns time in every iteration after it: nobody repeats the structure argument, and the reviewer looks at the problem instead of the shape. Steve McConnell treats consistent construction practice in Code Complete, 2nd edition (Microsoft Press, 2004), along with the cost of every choice made in a different context.
Mentoring with depth
A Staff Engineer teaches a senior how to weigh a trade-off, how to see a decision's consequence in a large system, and how to defend that reasoning in a room with product and sales.
Will Larson describes widened influence as part of the role in Staff Engineer (O'Reilly, 2021), with mentoring as one of its channels. What the senior learns in the conversation enters the reviews he runs and the artifacts he writes, and reaches more people than the pair.
System view
A team deep in its own backlog sees the backlog. Two teams build features that will collide, and the collision shows up in launch week.
Richard Cook explains in "How Complex Systems Fail" (1998) that failure in a complex system involves interaction between components rather than a defect in one isolated component. People who see those interactions cut rework, cut production incidents, and keep different teams' technical investments pointing the same way.
What changes in 6 to 12 months
- The team argues less about what counts as good code, because the pattern exists and gets read
- Seniors take on bigger scope and stay longer in the role
- Production incidents caused by weak design decisions drop
- Onboarding shortens because the system is legible to new arrivals
None of this shows up in a sprint. It shows up over quarters, and a review built on delivery misses it.
The cost of leaving the role out
Rework a clear pattern would have avoided. Senior attrition with no technical path left. An incident a better decision would have prevented. Add the three up for one quarter and compare them with the cost of the salary, full-time or on demand.
