Will Larson - Staff Engineer: Leadership beyond the management track

Leadership beyond the management track

Will Larson

This book took a village to write, especially when most of the work happened during the chaotic year that was 2020. There are so many people to acknowledge that its hard to know where to start, but theres really only one place: with the folks who shared their stories.

Thank you, Michelle, Kasa, Keavy, Bert, Katie, Ritu, Rick, Nelson, Diana, Dan, Joy, Damian, Dmitry, and Stephen. Im equally grateful to the folks who contributed stories to staffeng.com, whose stories arent in this book. Every one of those stories is a unique voice and well worth reading.

Tanya Reillys foreword is amazing, and Im eagerly waiting for Tanya to publish the canonical book on Staff engineering that replaces this one. The cover illustration is by Luciana Guerra, harkening back to old nautical maps where sailors navigated through the same uncertainty that currently obscures the role of Staff engineer. Greglas on the TechWriters Discord is the only reason this book has reasonable fonts and formatting. The community in the TechWriters Discord gave endless suggestions and support, with particular thanks to Gergely, Shawn, and Uma. Laurel line-edited the entire book; if youre not throwing it into the fireplace after two chapters of inconsistent capitalization, its thanks to her.

Many folks reviewed sections, with particular thanks to Sid, Gary, Pat, Gergely, Pete, and Tommy. Im also indebted to everyone who wrote a blurb and the twenty-plus folks whove contributed pull requests.

My copy of An Elegant Puzzle, Will Larsons first book, came with a side order of angst. No offence to the book Its full of insights and I recommend it. But its a book for managers, and I was reading it as part of the manager reading group in my office. Im not a manager; Im a principal engineer. I wasnt sure I was supposed to be there.

For engineers who have chosen the technical leadership career path, building skills can often mean feeling like youre in the wrong room. As our industry matures and tackles ever-bigger problems, more and more companies are recognising the need for engineers who have seen some things to drive technical strategies, lead projects that cross teams and organisations, and raise everybodys game by modeling what good engineering looks like. But thriving in any discipline means finding resources and communities to learn from and that can require some creativity on the technical leadership track.

Oh, we have plenty of books, meetups and conferences about technology, but from around the senior level on (and arguably earlier), technical skills arent enough. Success will often mean interpreting business needs, communicating a clear direction, defusing a looming crisis, convincing teams to agree on tradeoffs, or just being a good influence. Engineering bookshelves dont have a ton to say on these subjects. Instead, engineers read business or management books, picking out the topics that can apply to technical decision making, architecture, and so on, along with the techniques that can work without direct authority. For now, manager reading groups are often the best learning communities we have. (And, to be clear, we are grateful to be invited! Please keep inviting us, manager friends.)

The lack of resources for senior engineers is part of a larger problem: its easy to lose track of what the job even is. Engineers promoted beyond senior software engineer can find themselves alone as they navigate an under-defined new role, grappling with the mysterious notion of impact to understand whether theyre working on the right things, and struggling to adjust to feedback loops that come in quarters or years instead of sprints.

This isnt intentional neglect: managers just dont always know how to support their most senior engineers. How can you be sure your reports are working on the right things, when theyre expected to advise you on the most important problems rather than the other way around? What are the skills and behaviours you should expect from the engineers who will be the role models for the rest of the organisation? And, the inevitable question, how much code should they be writing?

It doesnt help that theres no universal career ladder shared across companies, or that job titles arent at all consistent. Thats one reason it was such a relief when Will launched staffeng.com and encapsulated the various roles into the collective staff-plus. Ok, we still have wildly divergent titles, but at least we now have a word to describe the sorts of roles were talking about. Im already hearing staff-plus in use where previously wed have jumped through linguistic hoops to describe the engineers who are more senior than senior level.

staffeng.com was an immediate hit in tech circles. Ive never seen a brand new site become the definitive resource on a topic so quickly. Will defines and describes the staff engineer role, offers clear advice on how to become one, and unpacks some of what he calls the orglevel chiropractics needed to be effective at the job. Hes adept at taking a familiar but ambiguous topic, drawing a clean circle around it, and explaining what the rest of us have been looking at without seeing all along. Along with the advice comes the beginning of the community weve needed. The many interviews (with staff engineers, principal engineers, senior principals, architects, tech leads, tech advisors and so on I told you the titles are confusing) show a variety of paths to staff roles and beyond; most readers will be able to find someone whose path feels familiar and, I hope, achievable.

This is the kind of writing we need on staff engineering right now, and Im delighted that Will has made it available in book form. Just like An Elegant Puzzle, the book youre about to read offers clear, pragmatic and practical leadership advice based on real life experiences. But this time, staff-plus engineers are the audience. Well, one of the audiences. Whether youre a staff engineer figuring out what the heck you should be working on, a mid-level engineer choosing between career paths, or a manager who wants to set their most senior engineers up for success, youll find wisdom here.

The stakes in software engineering get higher every year, and thats not going to stop any time soon. As Will says, Much as the Lorax speaks for the trees in his popular childrens book, staff engineers speak for their companies technology. The skills and behaviours we require from our role model engineers will have a direct impact on the code we write, the algorithms we deploy, the decisions we make, and the patterns we consider acceptable.

Im delighted that leaders on the technical track finally have this kind of guidance. I hope that this is just the first of many books and resources for all of us whove ever felt a little out of place in the manager reading group.

Tanya Reilly
Principal Engineer, Squarespace.

When folks ask about writing my first book, An Elegant Puzzle, I say that I wrote half of it over ten years and the other half in six months. Its creation was a challenge at times, and there are many things Id love to change in the final product, but creating it was a personal highlight. As an author, youre supposed to warn prospective authors away from writing a book, but I have no such warning, even to myself: I wanted to write another book.

The question was, what book? I might have more to say about engineering management at some point, but I certainly dont have much more to say there now. Ive spent more time as a manager than as a developer, and there are other folks far better situated to write about effective development. I hope to write a book about infrastructure engineering one day, but Im trying to spend