Book review: Staff Engineer

A few weeks ago one of our most senior engineers asked me, in a one-on-one, what the top two levels on our ladder actually meant. Not what the document says. She’d read the document. What she wanted to know was what she’d be doing all day if she got there, and whether she’d like it. I gave her an answer that was mostly about scope, which is how I wrote the ladder seven years ago, and I could tell it didn’t land. “Bigger things” isn’t a job description.

So I was glad Staff Engineer: Leadership beyond the management track came out last month, because it’s the book about exactly that question. It’s by Will Larson, whose An Elegant Puzzle I reviewed a couple of years ago, and it grew out of his staffeng.com site, where he’s been publishing interviews with staff and principal engineers alongside his own guides. It’s self-published this time, not Stripe Press, so it’s a plainer object. I bought the ebook.

Roughly the first half is Larson’s own guides and the second half is the interviews. I liked the first half a lot more, though I’ll come back to that.

The archetypes

The idea that makes the book worth buying is that “staff engineer” isn’t one job. He describes four:

The Tech Lead guides the approach and execution of one team, or a small cluster of them, usually paired with a manager. He says this is the most common one, and it’s often someone’s first staff role. The Architect is responsible for the direction and quality of one technical area that’s both complex and important to the company, say the data model, or the API, or storage. The Solver goes deep on hard, messy problems that leadership has decided matter, fixes them or finds a way forward, and then moves on to the next one. And the Right Hand works as an extension of a senior executive, borrowing their authority to get things done across the org. He says that one mostly only exists at companies with hundreds of engineers.

I read the list and immediately started sorting people, which I suspect is what everyone does. We’re not big enough to have a Right Hand, and I’d be suspicious of anyone who tried to be one at our size. But the other three I can name. We have one engineer who is the Architect for our data model in all but title. Nobody touches the schema without talking to her. There’s no rule about that, she’s just been right often enough that people check. We have a Tech Lead on the platform team. And we have one Solver, who I’ve never managed well, because I kept trying to give him a team and he kept quietly handing it back. He’s happiest when I give him the one problem nobody else has been able to close, and the archetype gave me a name for what he’s been telling me for two years.

It also explained my bad answer in that one-on-one. The engineer who asked is a Tech Lead by temperament, and I’d described the job mostly in terms that fit the Architect.

Work on what matters

The other chapter I’d tell people to read is “Work on what matters”, which is about how senior people waste their time. He’s got names for the failure modes, and they’re good names. Snacking is doing easy, low-impact work because it feels productive. Preening is low-impact work that happens to be very visible, which companies reward more than they should. Chasing ghosts is a new senior person pushing the strategy they had at their last company, mistaking what’s familiar for what’s important. I’ve done all three, and the last one most expensively, when I was new to a team years ago and spent a quarter rebuilding a deploy process that wasn’t the problem.

What he says to do instead is less catchy and more useful: go where the company has an existential problem if there is one, look for projects that are one small change away from working (“editing”, he calls it), get stalled projects finished because unfinished ones deliver nothing, and spend real time growing the people around you. He makes the point that the mentoring is quite likely what people will remember long after your design docs are forgotten, which I think is true and is also the thing I see senior engineers cut first when they’re busy.

There’s good material on writing engineering strategy and on getting promoted, including a section on promotion packets and finding a sponsor. The sponsor stuff is honest about how much the title depends on someone with power deciding to argue for you, which most career advice prefers not to say out loud.

What didn’t work as well for me

The interviews. Each one is a staff or principal engineer describing their role, how they got it, and what they do day to day, and individually they’re interesting. Together they blur. A lot of them work at large, well-known tech companies, and many answer the same questions in similar ways, so by the eighth or ninth I was skimming. They’re free on the website anyway.

It has the same bias I mentioned with his last book. It’s written from, and mostly for, companies with a few hundred engineers or more, where staff is a formal level with a calibration committee and a promotion packet. At a startup of our size, the top of the IC ladder is whatever a handful of people make of it, and the “getting the title” section mostly reads like a description of how other companies work. Useful if you’re thinking of moving to one of them, less so if you aren’t.

I gave a copy to the engineer who asked the question. She came back a week later and said she was definitely a Tech Lead and definitely not an Architect, and that she’d been worried the job meant becoming the second one.