Staff Engineer by Will Larson talks about what happens in your career should you decide to progress past Senior Engineer. For context, software engineers typically progress through a series of well known levels: junior, mid (or just “engineer”), and senior.

All of these levels are characterized by increasing autonomy and impact:

Title	Autonomy	Impact
Junior Engineer	Needs direction	Needs assistance completing tasks
Mid-level Engineer	Self-directed for day to day tasks	Independently completes tasks
Senior Engineer	Self-directed, assists with team direction	Independently completes tasks with high level of quality

Senior Engineer is what’s called a “terminal level,” meaning you could spend the rest of your career as a senior engineer. Basically it’s an equilibrium point; another way to think of it is that you won’t be let go for deciding *not* to go for a promotion, whereas for more junior positions that is generally not true (though I feel like Engineers get by just fine in my experience).

Staff plus levels, meaning Staff / Principal / Fellow / Distinguished Engineers are engineers who are still individual contributors, but nonetheless take on leadership roles. So the table begins to look like this:

Title	Autonomy	Impact
Staff Engineer	Influences a team or division	Affects the output of team members
Principal Engineer	Influences the organization	Affects the output of teams
Distinguished Engineer	Influences the industry	Affects the industry

Each subsequent level comes with increasing understanding of the business domain and increasing organizational trust in their abilities to do what’s best for the business.

Q: So if it’s a leadership role, what’s the difference between Staff+ and going into management?

A: The difference is in the reporting structure. As a staff+ engineer, you’re not in the chain of command and it’s not typically your job to do performance reviews, 1:1’s, or firing, yet you have the mandate to operate outside of your immediate chain of command in order to maximize impact on the organization. This lets you “go to ground” among your fellow engineers and get their unfiltered opinions on the state of engineering in the organization without fear of managerial retribution. The difference is that staff+ roles are about soft power leadership, whereas managers are endowed with institutional power, which changes the relationship with other individual contributors.

Also, sometimes being a force multiplier for a team can mean improving developer experience, platform engineering improvements, changing the onboarding or hiring processes, introducing a new technology, or promoting a psychologically safe working environment.

Larson’s book covers four archetypes of Staff+ engineers that stuck with me:

1. The Team Lead – the most common Staff+ archetype, the team lead is responsible for leading a team on an initiative or a domain.
2. The Solver – the solver finds hot spots or particularly thorny problems and fixes them, often bouncing from problem to problem. Interestingly Larson notes that this archetype shows up in orgs with a “weak team concept.”
3. The Architect – the architect is responsible for architecting new solutions. This sounds simple, but good architecture accounts for brownfield projects as well, meaning incremental architectures like the strangler fig pattern come into play.
4. The Right Hand – the right hand is the least intuitive to me. To my understanding, it’s a form of very deep delegation to engineering leaders who act as representatives of an individual or an office. They force multiply leadership instead of force multiplying individual contributors like many of the other archetypes do.

After discussing the archetypes, the book then goes into tips for how to operate as a Staff+ engineer, then how to get the position, whether that’s at your current company or otherwise, then filled the last half of the book with all the source interviews that the author did with Staff+ engineers.

Overall, the book covered a lot of ground – almost too much, because it will often allude to linked articles that aren’t summarized at all. I do think it would have benefited from a professional editor. However, while the book feels a bit like a long blog post, it’s still very useful and does well in conveying the overall idea of the various Staff+ positions.

I found the interviews at the end possibly more useful than the first half of the book in terms of getting an idea of what real staff+ engineers do – having cohesive stories makes it easier to remember them, even though I had read excerpts from the interviews in the first half of the book.

I’m very curious to compare this to Tanya Reilly’s book, The Staff Engineer’s Path, which is up next.