Book review: The Staff Engineer's Path

Three years ago I reviewed Will Larson’s Staff Engineer, and ended with the engineer who’d asked me what the top of our ladder meant deciding she was a Tech Lead and not an Architect. She got the title last year. A few weeks ago, in a one-on-one, she said the job was nothing like she’d expected and asked if I had anything for her to read that wasn’t about getting promoted. I’d bought Tanya Reilly’s The Staff Engineer’s Path when it came out in late 2022, read a third of it, and put it down. So I picked it up again to see if it was the right book to give her. It is, and I’m a bit annoyed I didn’t finish it the first time.

Larson’s book is mostly a view of the role from outside: what kinds of staff engineers exist, how companies define the job, how people got there. Reilly’s is about doing it, day to day, once you have it. She organizes the job around three pillars, big-picture thinking, execution, and leveling up the people around you, and the book is in three parts to match. It’s from O’Reilly, around 350 pages, and it reads like it was written by someone who’s been in the meetings, which she has, as a long-time infrastructure engineer at Google and then at Squarespace.

The maps

The chapter I’d photocopy, if people still did that, is “Three Maps”. Her claim is that most senior engineers can’t see their own organization clearly, and she gives you three ways to draw it.

The locator map is where you are: your team, the teams around you, what the company is actually trying to do this year, and how far your work is from that. The topographical map is the terrain, the stuff that isn’t on the org chart, like who actually makes decisions, which teams don’t talk to each other, the hazards (she has chasms between teams, fortresses, and disputed territory), and what she calls the shadow org chart, the people whose opinion matters regardless of title. And the treasure map is where you’re going, the destination and the stops on the way, so that a pile of small tasks becomes a story people can follow.

At a company of a few thousand people that’s obviously useful. I wasn’t sure it would mean much at ours, where the org chart fits on one screen. It does. The topographical map in particular. I tried drawing ours on a Saturday morning, honestly, as an exercise, and the hazards I drew were all things I’d known about for years and never written down. There’s a team that won’t touch anything near billing since a bad incident in 2019, which means billing changes wait for one particular engineer. There’s a decision about our data retention that everyone treats as settled, and nobody can find where it was decided. None of this is secret. It’s just never been on a map, so every new senior hire has had to walk into each cliff on their own.

Finite time

Part two, on execution, has the chapter I needed most for myself, “Finite Time”. Her point is that a staff engineer will always see more broken things than they can fix, and the skill is choosing. For every project, she asks you to check it against your energy, your credibility, your quality of life, your skills and your social capital, and to notice when something costs a lot of one of those for not much in return. She’s also blunt that you shouldn’t book 100% of your time, because the work that makes the job valuable is mostly unplanned.

I’ve given a version of that advice to engineers for years, badly, as “pick your battles”. Hers is better because it names what you’re spending.

The chapter on stalled projects, “Why Have We Stopped?”, described one of ours almost exactly. A migration that was 80% done for most of a year, stuck because the last 20% needed a decision nobody owned, between two options that were both fine. Her advice is to notice that the blocker is a decision and not a technical problem, write down your best guess, and get someone with the authority to agree to it, even provisionally. We did that in March, more or less by accident. I wish I’d read the chapter in 2023.

Role models, and glue

The third part opens with a chapter called “You’re a Role Model Now (Sorry)”, which is the best chapter title I’ve seen in a leadership book. The point is that people copy staff engineers, whether the staff engineer means them to or not. If you skip writing tests on a Friday, so will the people watching you. If you’re dismissive in a design review, that becomes how design reviews go.

She’s also the person who gave the “Being Glue” talk a few years ago, about the coordinating, unblocking, documenting work that keeps a team running and doesn’t get anyone promoted, and the book brings that in without making it the whole argument. She’s realistic that glue work is part of the staff job and also that it’s dangerous to do it too early in a career, before anyone has seen your technical work, which matches what I’ve seen. Two of the best engineers I’ve managed spent years doing glue work as mid-level engineers, and in both cases I was too slow to see it and too slow to argue for them.

What I’d change

It’s long in places. The chapter on writing technical strategy and vision is solid, but it’s well-trodden ground, and Larson covers it too. And like most books of this kind, the default setting is a company with many teams and a formal promotion process. Reilly is better than most at acknowledging smaller companies, but the examples still mostly assume there’s a “platform org” and a “director” somewhere. At our size, I’m the director, and some of the advice about “finding a sponsor” means “talk to me”, which the engineer who asked will find funny.

I gave her my copy last week, with the Three Maps chapter marked. She’s already drawn her locator map, on a whiteboard, and asked me to check it. I got two things wrong when I tried to.