Reading The Staff Engineer's Path as a manager
I picked up Tanya Reilly's book on the staff engineer role expecting it to be for someone else. It turned out to be partly about me.
You know when your manager and staff engineer just nod a lot at each other? You both kind of don’t understand what the other is talking about. “I want you to have more impact.” “Yeah, of course.” Nod nod. Then everyone goes back to doing the exact same things they were doing before at their desks.
I’ve thought about that conversation a lot this month, because I’ve been reading The Staff Engineer’s Path by Tanya Reilly, which came out this fall. It’s written for senior engineers who want to keep growing without becoming managers. I am not its target reader. I read it anyway, and I kept finding myself in the margins, usually as the person who hadn’t asked the right question.
Big parts: the big picture, getting stuff done, and raising the talent level. The big picture is all about maps. I loved the maps. There’s one for where you and your team fit in. There’s one for the lay of the land. Where are the decisions really happening? Where are the unclimbed hills? And there’s one for where the org says we’re heading. I’ve seen a lot of org charts, but I never knew where the swamps were.
A chapter that I keep revisiting is about stalled projects. Reilly identifies a few types of stalledness. There are ones that are blocked, waiting for someone, or for something to happen. And there are ones that are lost - there’s no idea what the next decision is going to be. But then there are ones that’ve claimed victory early. Before the actual goal. Maybe the most common type. And definitely the slyest. Shipped code. Everyone thanked. But it didn’t change what it was supposed to change.
It was nice to have a name for these. This feels slow. This is lost. You can do something about that.
A nice concept was this idea of a budget of time. As a staff engineer, you only have a certain number of hours. But you also have a certain energy and credibility and goodwill. All of those are being spent for every project. It never occurred to me that you could run out of credibility for a quarter. But of course you can. You can see it happening for someone who says yes to everything.
Now, a few complaints, because there are never perfect books. And I’d feel like a phony if I didn’t have any.
Written from the perspective of a large company where there are many teams and an actual staff level. Lots to map. Maps are napkin drawings for a small company. Strategy is one page. Staff engineer is probably authoring a large chunk of the code (as well as staff engineer). The principles travel. Ceremony mostly doesn’t. I wish this was emphasized a bit more in the book.
There’s a chapter on how to be a role model of good engineering. Which I feel in a subtle way lets the manager off the hook. Staff engineers can model doing things right all day. But if the manager doles out the kudos to the person who manages to ship the most features least well, then modeling doesn’t win. To be fair. The book is written for the engineer. And therefore talking about the things the engineer can control. But as a manager I found I was influencing much of the weather.
Good (and long) chapter on vision / strategy. Most staff engineers probably are going to write a few narrow strategies before a big, multi-year vision if they ever write a big multi-year vision. I read it to understand the approach. Skimmed the big audience stuff.
But curiously, the thing I remembered from the book most came from the very first chapter. About understanding the scope of staff engineer. What’s the shape of their work? What is their primary focus? Wide? Narrow? Deep somewhere? Broad? Three questions. And I feel like I’m a bit embarrassed about how infrequently I’ve seen people answer and write down. Maybe all the nodding is masking something?
If you’re a senior engineer trying to figure out if staff is an actual job. Then the first chapter will define what it is. And that’s more than most job ladders define. If you’re the manager involved in that nodding discussion. Then read the whole book. And it’s funny which is a plus.