Staff Engineer author, Will Larson, is mostly known by An Elegant Puzzle: Systems of Engineering Management (which might be my next read). Both books deal with software development career and management at scales beyond the “classic” senior level.
Notes
Defining roles is hard, but I like this quote by Diana Pojar:
(…) their main focus is working on projects/efforts that have strategic value for the company while driving technical design and up-leveling their team
That definition is enriched with mentions to “technical direction, sponsorship and mentorship, injecting engineering context into organizational decisions, exploration and being glue”.
The author suggests an archetype taxonomy for staff engineers (which one are you? ;) ):
- Tech Lead.
- Architect.
- Solver.
- Right hand.
There’s one theme guiding the whole book, implicit and explicitly: being an “staff engineer” feels like you’ve already succeeding proving that you deliver, and the next step is “letting yourself go” and focus on the company and others. Depending on the archetype you become, that focus will balance between team, areas, depth of technical expertise or management influence, but it’s an “outwards task”. It’s not about improving yourself (which you’ll anyway do), but having impact on others (directly or indirectly).
The previous has a corollary: title matters. Theoretically it doesn’t, you know, but in practice, it does. The second half of the book is devoted to personal stories, and many admit that the title helped being listened or taken into account. Specially for those who are in an underrepresented group.
There’s an interesting section about “writing engineering strategy” with a sentence I personally love:
good strategy is pretty boring
I won’t get into the details of the way he suggests writing it, but I’d like to mention why he thinks strategy is important:
Strategies are tools of proactive alignment that empower teams to move quickly and with confidence
I can’t forget one of my most admired managers saying that “whenever strategy is mentioned, everything becomes bullshit”, but I agree that when I’ve seen teams move quickly but aligned you could say there was a common strategy.
Most of the work of an Staff Engineer is still technical (as opposed to management), so you have to pick your battles. Leverage points is the term used for those places where “an extra investment preserves quality over time”, and he highlights three: interfaces, stateful systems and data models.
… but not everything is just technical. You’ll get into many meetings, and for making them successful there’s a suggestion: “master three approaches: listen through questions, define the purpose, and know how to read the room.”.
Closing thoughts
I liked the first half of the book a lot: there isn’t too much literature about non-management roles once you reach senior level, and this presents a good definition of Staff Engineering (both specific and flexible, thanks to the archetypes), which enables conversations. Once the stage is set, it provides a handful of tools and suggestions for being more effective, from technical to communication. I’ll definitely keep this book accessible in my bookshelf for going back to it when I think something’s going wrong and I need to sharpen my tools.
The second half of the book is a collection of stories that became boring and repetitive quite quickly. Individually, each of them is interesting, but 14 of them in a row is a little too much. All of them being interviews with the same format doesn’t help.