I had been wondering for a while what my long-term career as an engineer would look like, so I purchased this book shortly after its release. I won’t cover everything, but I’ll share my review while quoting some parts that caught my attention.

The Japanese version of this article is available here.

About the Book

This book systematically summarizes the role of Staff Engineers, based on interviews with people working in that position. It covers topics such as what a Staff Engineer is, the expected roles, and how to become one. The first half presents a systematic summary based on interviews, while the second half contains the actual interview content.

Career-related books from overseas often contain content that isn’t applicable in Japan. However, I felt that this book offers universally useful insights—both in Japan and elsewhere—because the original author was mindful of not limiting the discussion to Silicon Valley, and the translator added interviews with Japanese engineers.

What Is a Staff Engineer?

“Staff Engineer” is a perfect role for “technical leaders” who want to remain hands-on engineers for their entire career, rather than moving into management positions like manager or CTO (Chief Technology Officer).

The idea that software engineers inevitably drift away from technology and toward management as they advance is a familiar dilemma in Japan. Apparently, this problem exists outside Japan as well. This book explains the career path of a technical leader1. Of course, as a leader, management tasks such as mentoring subordinates and team building are important parts of the job. But what distinguishes it from a typical management role is the emphasis on technical decision-making and continuing to write code (even if with less time).

This book provides a systematic overview of what technical leaders do, and I feel it clarified aspects that I previously understood only vaguely.

I learned that “Staff” also carries the meaning of an advisor, and that it is an established role in the United States, serving as both an “engineering leader” and an “executive aide.”

I learned this term just before buying the book. In Japan, few companies seem to use this title yet. As the book mentions, catchy terminology can help spread the underlying concept (SRE being a good example), so I hope the term “Staff Engineer” will help popularize the idea of technical leadership as well.

Classification of Staff Engineers

The book classifies Staff Engineers into four types:

  • Tech Lead guides a given team toward the right approach and execution.
  • Architect is responsible for the direction, quality, or approach in critical areas.
  • Solver dives deep into arbitrarily complex problems and carves a path forward.
  • Right Hand acts as an aide, representing the concerns of a senior executive and leveraging the executive’s authority and capabilities to manage complex organizations.

It’s worth noting that not all Staff Engineers fit neatly into these four categories—many have a mix of these roles or do other work as well.

Also, these terms are specific to this book’s classification and are not necessarily widely established, so one should be careful with definitions when using them outside the context of this book. In fact, I had heard the terms “Tech Lead” and “Architect” before but in different senses, and even in the interview sections of this book, there seemed to be some mixing of meanings.

In my own opinion, these four types can be classified along two axes: team-oriented vs. not, and broad vs. narrow technical scope. Tech Leads and Architects act as leaders who drive one or several specific teams, while Solvers and Right Hands move between teams as needed, like utility players. Additionally, Tech Leads and Solvers tend to specialize in deep, narrow technical domains, while Architects and Right Hands cover broader technical areas. I admit this feels somewhat forced and may be an oversimplification, so take it as just a reference.

How to Become a Staff Engineer

There are many detailed points, but the four major important things are:

  • Work on a Staff Project
  • Start writing your Promotion Packet early
  • Get into the room where decisions are made and stay there
  • Build your visibility

A Staff Project is a significant project worthy of someone becoming a Staff Engineer. Opinions are divided on whether it’s strictly necessary.

A Promotion Packet is the documentation needed during the promotion review process. It includes details of accomplished Staff Projects, achievements, and peer evaluations. By updating it regularly rather than only at the final stage of promotion, you can clearly understand your current standing and identify areas for improvement.

This section was very helpful as it focuses not on technical skills but on what soft skills are needed and how to conduct yourself.

I noticed that except for “getting into the room where decisions are made,” these are things that are also necessary when job hunting as a new graduate, just at a different level. It seems best to be aware of these things from an early stage and keep at them continuously.

Summary

The Staff Engineer title is still a distant prospect for me. However, this book has significantly clarified how to position myself early on to become a Staff Engineer, as well as what to expect from—and what is expected by—those already working as Staff Engineers, and how to collaborate with them effectively2. Since my takeaways from this book will likely change at different stages of my career, I’d like to revisit it periodically.


  1. I wondered whether CTOs were included, but it seems CTOs are classified as management roles because they focus on business-oriented decision-making and don’t write code. Some CTOs I know work in a way that resembles a senior Staff Engineer, so this classification should be taken as specific to this book. ↩︎

  2. For the details, I encourage you to read the book itself. ↩︎