Book Review: Staff Engineer

Will Larson’s first book, An Elegant Puzzle: Systems of Engineering Management, received praise from a few folks I trust. I never read it, though, because the management track isn’t where I want my career to go at this time. When his second book, Staff Engineer: Leadership beyond the management track, was released, I knew I wanted to read it. I am a staff engineer, and want to learn more about how others attain the title, what they do with it, and how to progress from here.

The book is full of real-world advice, anecdotes, and examples from people currently operating at Staff Engineer and above. Indeed, the latter 150 pages is nothing but interviews with these people. Full disclosure: I haven’t read these interviews yet. I’m certain I’ll glean useful information and strategies from them, but it was the first 150 pages that I want to review here.

This book is not a page turner. But it’s a good read. I’d read a couple pages at a time, highlighting several passages per page, and then put the book down to think about what I’d just consumed. There’s a lot in here. There’s a lot of practical advice, as well as just some affirming statements that my experiences thus far are not terribly uncommon. The book contains several hundred footnotes, each of which is a link to a blog post or article for further reading.

Larson starts out identifying the challenge with even describing “staff engineer” roles. The title varies from company to company, and the skills and capabilities of Staff and beyond can be hard to articulate. To that end, he adopts the phrase “Staff-plus” to wrap up everyone operating at a technical career above “Senior Engineer”. This includes Staff, Principal, Architect, and a swath of other titles used by employers. From here, he identifies the major Staff-plus archetypes most common in the workforce today: Tech Lead, Architect, Solver, and Right Hand. Larson states “[t]his taxonomy is more focused on being useful than complete, but so far, I’ve been able to fit every Staff-plus engineer I’ve spoken to into one of these categories.” He then highlights the major focus of each archetype, and helpfully includes sample days from their calendars! This was extremely informative, and highlights how similar each of these roles is in broad strokes, while also making clear the specific differences between each.

One paragraph about the Architect archetype really hit home for me:

There is a toxic preconception that Architects design systems in isolation and then pass their designs on to others to implement. That does happen in some cases, but reciting that stereotype would slander the architects I interviewed. Influential architects dedicate their energy to maintaining an intimate understanding of the business’ needs, their users’ goals, and the relevant technical constraints. They use that insight to identify and advocate for effective approaches within their area of focus, and do it with organizational authority that they’ve earned by demonstrating consistently good judgement.

The book quickly gets into “What do Staff Engineers actually do?”, and covers a few things in broad strokes: setting technical direction, mentorship and sponsorship, providing engineering perspective, exploration, and being glue. Larson asks the question “Does the title even matter?” and provides a few examples of ways in which the titles does matter.

A Staff-plus title allows you to reinvest the energy you’ve previously spent on proving yourself into the core work you’re evaluated on.

The chapter on “Operating at Staff” is really good. Work on what matters (and avoid “snacking”), write engineering strategy, curate technical quality, stay aligned with authority, to lead you have to follow, learn to never be wrong, create space for others, build a network of peers. Each of these gets an examination, and contains suggestions for success. For example, on writing engineering strategy: “Strategies are tools of proactive alignment that empower teams to move quickly and with confidence. And “[a] good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details.” Finally, “[a] great vision is usually so obvious that it bores more than it excites.”

The exploration of technical quality also had some powerful quotes:

In most cases, low technical quality isn’t a crisis; it’s the expected normal state. … At a well-run and successful company, most of your previous technical decisions won’t meet your current quality threshold.

This chapter is full of easy to understand suggestions. Larson is careful not to be prescriptive, nor does he try to speak with a voice of authority. He takes care to quote real-world staff engineers to support his analyses, and presents suggestions as just that: suggestions. The steps outlined in the book have worked more than once for multiple people across industries, so there’s a good chance they can work for you.

The section on “Never be wrong” was extremely interesting. On first read, that title sounds like an encouragement to ensure you always have the best answer, the best approach, or more technical insight into a problem than anyone else. But that’s not at all what this means. I won’t repeat here the contents of this section, but I will share the closing text:

This approach is powerful because more complex projects get derailed by personal conflict than by technical complexity, and this is a repeatable way to replace tension with partnership. It feels like it’s slow because it can take longer to get started, but ultimately it’s fast because you’re more likely to complete the work without disruption.

There’s a whole chapter on presenting to executives, and this was illuminating to me. “Go into the meeting to understand how you can align with their priorities.” Larson introduces Barbara Minto’s Pyramid Principle, and also the SCQA format of Situation, Complication, Question, Answer. The advice in this section is practical and useful, and really underscores the importance of knowing your audience.

Larson spends a lot of time exploring how to get the title where you are currently employed, and examines reasons why you might have to change employers to get the title (if the title is important to you). There’s really good advice on developing your “promotion packet”. Some companies require this, but even if it’s not required it can greatly help you collect your successes and identify your growth areas.

I found a lot of useful suggestions, but I also found a lot of affirmation of things I’ve been experiencing and having a hard time articulating.

There is a significant learning curve in Staff-plus roles that initially trip most folks up. Part of the challenge is that much of the work you’re doing has a much slower feedback cycle. The delayed feedback can initially feel quite demoralizing as you replace the visceral coding REPL with the uneven progress of mentorship, relationship building, and strategy.

This hit home for me in a major way. As a technical individual contributor, I’m used to seeing fast results from my work. I implemented the thing; I optimized the thing; I unblocked my peers because the thing was in their way. But as a Staff engineer, “the thing” that I do doesn’t have those immediate results, and sometimes it’s hard to draw the line between “I did this activity for the past six months, and this positive outcome has been obtained”. Reading this was eye-opening for me, and really helped me feel better about the frustrations I’ve been experiencing.

The other bit that really resonated with me was this:

Retire your remaining expectations that the company is designed to set you up for success. Now you are one of the people responsible for setting the company, your team, and your manager up for success.

Most mature technology companies succeed in creating a predictable promotion pipeline for folks joining early in their careers up through attaining the Senior engineer title. The process of getting a Staff title is generally more complex than preceding titles but usually navigable with the support of your engineering manager. Throughout this pipeline, you may become comfortable with your manager guiding your development and providing a safety net for your continued success. After reaching a Staff role, your safety net will cease to exist, or at best, the safety net will be short enough that you’re quite capable of jumping past it and into the awaiting chasm. This will be increasingly true as you go further into Senior Staff and Distinguished engineer roles.

Staff-plus roles are leadership roles, and in leadership roles, the support system that got you here will fade away. Often abruptly, you’re now expected to align the pieces around you fro your own success.

I am experiencing this now. My manager supports me, for sure, but all future progress is mine and mine alone. My manager has no roadmap for what I need to do next. It’s up to me to develop it, and then refine it with him, and figure out how I can apply my skills to keep the company succeeding in new ways.

In conclusion, I cannot recommend this book enough. If you’re just starting on your career you’ll learn some early tips on how to maximize your impact and influence. If you’re a Senior engineer trying to get promoted you’ll have plenty of things to try after reading this book. And if you’re a manager you’ll get some suggestions on how to better support all your direct reports (and maybe lighten your load by delegating some things!).