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.
What is a Staff Engineer?
What even is a Staff Engineer? The basic premise of these books is that the role isn’t well defined for engineers above senior level, and 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.
Archetypes
Given the vagaries of Staff Engineer, the first task is to define what a Staff Engineer does. Will Larson starts of with 4 categories that his research and interviews revealed.
Tech Lead
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.
Architect
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.
Solver
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.
Right Hand
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.
To Be Continued
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.
Leadership is through persuasion and advocacy rather than authority.
These books next explore what is part of the duties of a staff+ engineer.