Staff Engineer Book Review, Part 1

The last couple of years have seen more attention paid to the Staff+ tier of technical positions. A couple of books in particular, Staff Engineer by Will Larson and The Staff Engineer’s Path by Tanya Reilly, have been published to try and steer the conversation.

In addition. Will Larson started the website staffeng.com, which collects stories and guides on what staff engineers (or higher) do, and how to become one.

This is a review of Will Larson’s book, Staff Engineer.

The basic premise of these books is that the roles above senior engineer isn’t well defined, so these books attempt to help not only engineers at or aspiring to these levels, but also managers and executives who wish to establish a technical leadership track for their engineers.

Staff Engineer was the first book, with a forward by Tanya Reilly, who is the author of the other book. In Tanya’s book she acknowledges Will’s encouragement for writing her book.

The book is divided into two parts.

The first part is information and advice about reaching and operating as a staff+ engineer.

The second part is interviews with various staff engineers.

Will Larson spent most of his time in management, so to write this book he relied on interviews with staff+ engineers across various companies. The companies he interviewed people from are perhaps not as wide as could be. For example, there are no engineers from Big Tech FAANG companies interviewed. And none of the companies he interviewed from were from small startups, though many of the engineers had experience at smaller startups.

Given the vagaries of the responsibilities of staff engineers, the first task is to define what a staff engineer does. Will starts with 4 categories that his research and interviews revealed.

“This taxonomy is more focused on being useful and complete, but so far, I’ve been able to fit every Staff-plus engineer I’ve spoken to into one of these categories.”

The Tech Lead is the most common incarnation of the Staff Engineer.

A tech lead is responsible for technology decisions related to one or more teams, usually working along side a manager who is responsible for the people management of a team.

They coordinate across teams and across disciplines to make sure that technical decisions are aligned with the priorities of the project, product, and stakeholders. As opposed to Technical Program Managers, who make sure that the project is done on time and meet requirements, Staff Engineers as Tech Leads ensure the engineering quality of the deliverable.

Tech leads typically report to another manager over one or more teams. They usually operate at the same scope as that manager across those teams.

Architects are responsible for a specific domain within their organization. This might be API design, infrastructure, or other domain.

Architects design strategies, though not in isolation. They are part of conversations for each project that involves their domain, and lend their expertise to that projects needs.

In addition, they direct future endeavors with strategies for future looking projects, not just current ones.

Architects typically work for larger companies where specific domains are large enough to be warranted. They report to managers higher up the hierarchy, such as a manager of managers.

Solvers are agents who go deep to work on thorny problems that need immediate attention.

This may be code related problems, or it might be organizational problems. Example could be fixing a complicated bug that cuts across components, or it might be filling in as a team lead when a vacancy occurs and no candidates are available.

Solvers are more common in companies that operate at the individual level rather than team level. Startups and companies with smaller tech divisions are likely to have solvers.

Solvers don’t often report to a single product or project manager, but belong to a “tiger team” that goes where it’s needed. This team often operates company-wide, operating as the “Office of the CTO” or similar.

Right hand is the least common of the roles. It is the engineer who has the sponsorship of a high level executive.

Their decisions and actions are usually considered proxies for the executive themself, with the expertise that the engineer possesses.

Of course, for the Right Hand to have the sponsorship, they must consistently demonstrate that they are aligned with the executive’s priorities.

Really, that’s a hard question because, in most companies, not each of the archetypes is available. Where you are matters probably the most.

But if you do have choices, knowing which archetypes matches your talents is the first step.

These archetypes are just very broad strokes. The roles are ambiguous by definition, and it is often up to the engineer to define their role and make sure that it is aligned with the organization’s objective.