Staff Engineer: Leadership Beyond the Management Track by Will Larson

Staff Engineer: Leadership Beyond the Management Track Reviews

• 
  Sebastian Gebski

  So good I've read 85% in just one day. Yeah, I was stuck on a train for 6 hours, but hey, it still counts.
  
  What is it about? A technical leadership. Not a managerial kind of leadership (you'll find more on that in "Elegant Puzzle" or "The Art of Leadership"), but the endgame of genuinely technical engineering path. So yeah, it's about what's behind "senior" in an engineer's career progression. If the titles like "staff engineer", "principle engineer" or "distinguished engineer" ring a bell for you, that's the book that covers those roles/positions.
  
  The book consists of two parts.
  
  The first one is a synthesis of the info on SE role the author has collected from various companies that understand and cultivate modern engineering leadership. Yes, this knowledge had to be 'picked up in the field', because we're not talking about any single 'standard', unified terminology, or even common understanding of the same term.
  
  The second part is pretty much what was the basis for the first part - interviews with various individuals that play SE roles in their organizations. They differ significantly and Larson does a good job in catching both the common parts and the differences.
  
  I really liked this book. I think it was needed because of many reasons. Here are some of them:
  * to show how exciting engineering leadership can be and in how many flavors it comes
  * to clarify why leadership is different from management
  * to give the meaningful answer whether the IC path can be equally compelling to a managerial one
  * to somehow standardize (or at least try) ideas introduced in parallel by many organizations
  * to indicate that the top of the engineering career ladder still ain't about pure technology - it's also about understanding of the product, great communication, cultivating teams around you, and making things happen not necessarily just with your very own hands
  
  Good stuff, highly recommended to everyone interested in various aspects of engineering culture and building engineering organizations. A must-read for engineering who want to consciously build a future career in tech.
• 
  Matt McCormick

  As the target audience for this book, I had high hopes for this ebook but was sorely disappointed.
  
  The content is extremely generic and fluffy, similar to what you might find in a pop self-help book. For example, when it comes to team development the advice is:
  
  > If you start dedicating even a couple of hours a week to developing the team around you, it's quite likely that will become your legacy long after your tech specs and pull requests are forgotten.
  
  There are no suggestions of what to do in those couple of hours a week. There's no real-life stories or experiences from the author about what they, or others, have done to address problems or help develop the team.
  
  This is just one example. The other topics in the book are all covered in a fairly similar manner.
  
  I read about 50 pages and realized I hadn't really learned anything so I stopped reading.
  
  Additionally, the author will vaguely cover a topic but then provide links to other articles or blog posts for more details. The reason I paid for this book is to have information like that summarized in one place. The author should be the one doing the research on the reader's behalf. The reader should feel like they are reading a book and not reading a long blog post.
  
  If the author had provided a refund policy on their website, I would have asked for my money back. After purchasing a few ebooks, in general, I have found the quality to be sorely lacking even though authors charge much more than published books retail for. Unfortunately, this book falls into that category as well.
• 
  Rogério Vicente

  I had high expectations for this book and I picked it up mainly because there are very few titles about progressing past Senior Software Engineer in the Individual Contributor career track. But unfortunately it fell short of expectations.
  
  The book just feels like a very early draft. And here's why:
  
  - there are tons of links thrown into the text, without even briefly explaining them, you're forced to actually check the notes section (and I understand that in the ebook version the experience is slightly better because those are links. But I picked up the paperback version).
  
  - some paragraphs seem out of place, the narrative misses a linear progression and sometimes I found myself wondering why I was reading about X when the chapter mentioned Y.
  
  - throwing around 150 pages of interviews seems rushed and sloppy. I think that a better way would be to actually digest those interviews, filter out irrelevant/repetitive stuff and provide a clear narrative summarizing the key points, stating what's common in all of them, what's different, etc.
  
  But there's definitely interesting advice and stuff to learn here (specially if you work in a mid-to-large organization). It's just very condensed and would eventually result in a 100 pages book at best. Everything else feels repetitive since the author keeps quoting those same interviews.
  
  I wish I could say there are better books out there on the subject. Unfortunately there aren't.
• 
  Mindaugas Mozūras

  Staff engineers need to be able to think about engineering decisions as a series of tradeoffs, and articulating those tradeoffs is a skill that you can have from any perspective within the stack.
  
  At Vinted, we started using the words "Staff Engineer" in 2017. I specifically say "started using the words", because we were not exactly sure what those words meant. We had a definition, but there was a gap between that "Staff Engineer" definition and reality.
  
  Now, in 2021, the situation is different. We have a lot more clarity about the "Staff Engineer" role and its importance. Thus many of the thoughts laid out in this book were not new to me.
  
  Probably because of that increased clarity (and partly because I follow Will's blog and some of the content was not new to me), I found the actual experience of reading this book a rather calm and pedestrian affair. I would rate it 3 stars if I would rate it only based on my reading experience.
  
  BUT! I know I would've loved to have this book in my hands 4 years ago. The importance of this book can't be overstated. In our industry, we need more books about technical leadership. And I'm quite convinced that a lot of engineers will appreciate the content of this book greatly. Recommended to anyone who is in technical leadership, wants to be in technical leadership, or leads people in technical leadership roles.
• 
  Ieva Gr

  Why I read this book: A colleague recommended it to me as a good guide for navigating the corporate life as a developer.
  
  How I read this book: I listened to the audiobook version while doing various chores around the house. I tried to focus on the chapters that contained the "theory," but I allowed myself to listen more loosely to the chapters with the interviews.
  
  What I liked about it:
  I'm glad that books like this exist. Even if one isn't aiming to become a staff engineer, this book is a good guide on how to orient oneself professionally. It talks about different ways to be a senior software engineer (mostly tech lead vs. specialist) and I think it's useful to understand as early as possible which works best for you. It also paints a picture of what responsibilities look like later in a career.
  
  I have two stories in my professional life where I failed rather miserably. One was about trying to hype up my peers about setting up our monitoring system and fighting false positives. The other was about building a complex piece of software that I didn't realize was this complex when getting into it. Even though there was no direct advice on handling such problems in the book, the overall flow described in, for example, "
  Manage technical quality" made me realize what I did wrong in those cases. I'm used to rather small tasks where I can just start coding straight away, but some problems require a lot more preparation, communication, and planning in advance.
  
  While listening to the audiobook, I googled the author and found his blog at
  https://lethain.com/. It has several good posts on it. Some of my favorites are "
  Hard to work with" and "
  Lessons not worth learning."
  
  The book came to me at an interesting time. I've been down with a cold on and off for more than a month now. I sometimes took sick days and sometimes tried to work through it, which left me quite drained mentally. Finally, I took a week off to move between apartments, and throughout all the chores of moving, I listened to this book. It usually put me in a certain mood as I started to think about my work and my relationship to it, and the relationship that the people interviewed in the book seem to have with a very similar line of work. I haven't come to any meaningful conclusion yet, but the thing that caught my attention the most was that a lot of the staff engineers interviewed in the book talked about finding the type of work (within software engineering) that energizes you. As the author points out in another
  good blog post of his, things that bring us joy sort of create more time in the day as we wouldn’t be able to do more things if we're in a bad mood or feeling drained.
  
  I liked that the staff engineers interviewed in the book are rather diverse. They shared their experience of how being part of a minority affected their career path. For most of them, it was impostor syndrome. Someone described it as "only feeling ready to do something when you're absolutely sure that you'll be able to." This is definitely a problem I have, too, and it was nice to hear someone assure me that it's also okay to take on projects I have no idea how to implement at first.
  
  I like that the book is also available as a
  website. I wanted to revisit some chapters I couldn't properly concentrate on in audio format and was pleasantly surprised that I didn't have to buy a paper copy to do it. I also saw that the author has another book, "Infrastructure Engineering", in the works, and there is already a website for it at
  
  https://infraeng.dev/. It seems to have an outline for the entire book and only some chapters filled in. This is a very interesting way to work on a book.
  
  What I disliked:
  One of the things that prevents me from wanting to advance in my career is the fear that having more and more responsibility would ruin my work-life balance, as I would constantly be so stressed that I couldn't stop working or thinking about work. I wish this topic had been addressed in the book in some way.
  
  What other resources the book pointed me to:
  - All the interviews list the staff engineer's name in the title, which makes it easy to look them up. I think I'll research them more in depth later, but the one person who caught my attention was
  Keavy McMinn, as she writes about the process of approaching complex problems.
  - Many people praised Lara Hogan. I added her book "
  Resilient Management" to my to-read list.
  - One of the staff engineers mentioned reading the Programming subreddit to stay up to date with what is happening in software engineering. This wasn't the first time I heard someone say that, but now I finally took the time to download the Apollo app for browsing Reddit on iOS and will try to make a habit of it.
  
  You can also find this book review and the reviews of other technical or otherwise work related books that I’ve read on my website:
  https://www.ieva.dev/book_reviews.html
• 
  Dmitriy Rozhkov

  Less than a half of the book is the book. The other half is stories of various staff+ engineers. The stories I didn't yet read. Though stories are usually stories, not a framework or something practical. The book ended somewhat abruptly on compensation negotiation. I'm a bit frustrated.
• 
  Gianluca Ciccarelli

  Sure has many useful ideas and probably it’s the only book written explicitly on the subject, all things to commend. What I didn’t like is the continuous reference to external articles via direct links. I don’t mind that happening when you can still understand what’s going on without actually following the link (unless you want to go deeper). However I don’t find it cool when unfamiliar concepts are referred to without any introduction and assuming the reader is familiar with your blog or the topics you touch on. There’s a reason for a person to read the book: they want to learn about new concepts.
  
  I also think the interviews (which take roughly 50% of the book) are repetitive and in the end don’t provide much utility (but were often mentioned in the first part as an already acquired concept). Many of them contain spelling mistakes and seem to have been collected via email (the questions are always the same and are always asked, even when the interviewee has covered some topic in a previous answer).
  
  There’s also something that I philosophically dislike about some of the archetypes discussed. Being aligned with the manager? Act like you are them or their extension in their absence? I mean I agree on having a common vision but regard with suspicion any situation of unneeded thought dominance.
• 
  Chip Huyen

  It was interesting to learn about the career progression of the engineering IC path.
• 
  Tyler

  First fifty pages or so had useful information but this quickly devolved into restating the same thing in order to pad this out to a book length. It evens reprints the interviews that inform the first section just to double the page count. There are some interesting nuggets but it focuses on such a narrow band of Staff Engineering that it almost becomes worthless to those not operating in a many thousand person engineering organization.
• 
  Rob

  I think a friend put it best when he described this book as "super clarifying" and that it "gave [him] language to understand" what it meant to be a Staff Engineer (and more so, why he felt "stalled" in a specific previous organization). I would agree with both of those points -- for anyone operating as a senior software engineer and thinking about next steps, this book is like a magnifying glass for the career map and provides the vocabulary, mental models, and strategies you can use in both thinking through that next step and executing on it. What's more, Larson's book seems to be a novel discussion of the topic, and while he makes heavy use of references to outside material (well-known blog posts, books, etc.), his prose points you to those before making his own synthesis.
  
  I approached this book as a kind of teaser or trailer for the next phase of my own career, as I wade through those complex (and emotional) decisions about whether to zig toward Principal/Staff, or zag toward the Management track. (This putting aside any discussion of "the pendulum" for now.) And like my friend, what was foremost in my mind was: "Have I been thinking about this in a sensible way? Do I have the right vocabulary to talk about this? Do I have a sound mental model for what the work at the Staff+ level is going to be?"
  
  SPOILER ALERT: I wasn't too far off, but this got me to where I needed to be on my journey.
  
  Broadly speaking, Larson's book is structured in four parts:
  
  1. An overview of what a Staff+ Engineer is
  2. A discussion of the kind of activities/projects taken on by a Staff+ Engineer
  3. Strategies for getting the Staff+ title (and whether to do it "in-place" or switch companies)
  4. A series of interviews with Staff+ Engineers (how they operate, how they got to where they are, etc.)
  
  The discussion of "what a Staff+ Engineer is" winds up being an excellent place to start, because Larson creates a mental model of the role (in all its diversity) that he can now share with you (the reader!) moving through the rest of the material. It's a level-set for the rest of the material. And in SOME ways, this is your escape hatch: if you get to the end of the section and you're like "Whoa! not for me!" -- then you can end there (guilt-free!) and move on to
  An Elegant Puzzle: Systems of Engineering Management or
  Resilient Management.
  
  Moving on to the discussion of Staff+ activities/projects ("OK but what does a Staff+ actually do?") presents the kinds of "day-to-day" (in quotes because sometimes these activities have v. long time horizons and get bursty) that one might expect to do in these roles. For me, this section was useful in two ways: FIRST -- the activities described are very concrete, and illustrate a vivid pictures of what "the work" is; SECOND -- with such concrete descriptions, it becomes trivial to map that work onto what I'm doing right now, and to identify where I'm already operating in a similar capacity, where I need to grow, as well as what kinds of things might be energy-draining pitfalls for me were I to take a Staff+ role.
  
  The "how to get the title" section provides more concrete examples -- this time talking through tactics like how to leverage your work into a "Staff project", how to use the notion of a "promotion packet" to your advantage, and how to get the right kind of visibility with leadership to garner support. (A lot of software engineers hate to hear about these kind of company politics but… if you made it this far in the book, you've probably AT LEAST come to accept the necessity of them.) Larson talks first about how to apply those tactics at the company where you already are, given that a Staff+ role is more likely when you have already established the kind of cachet and credibility that it takes to get sponsorship for a role like this. That being said, Larson explicitly acknowledges that your current organization may not be able to support you as a Staff+ (or there are other barriers -- e.g., political ones) and then lays out some tactics for how one might land such a role at another company.
  
  Lastly, Larson includes interviews with 14 Staff+ Engineers from 11 different companies. Like with the section on Staff+ activities/projects, the interviews are useful through the lens of making things concrete, and giving you something "real" to grab onto for comparing your own situation. You get to see the different paths that brought people to their Staff+ roles, the different ways that they apply their leverage, the different kinds of projects, etc. It also gives you a taste of the different ways people might inhabit the role, and the different expectations that might be applied by different organizations. (Also: hats off to Larson who seems to have made a point of getting a diverse group of Staff+ engineers across gender, race, and other identity verticals -- show people it's possible for them!)
  
  Perhaps the most worthwhile aspect of this book is how it coaxes you into asking deeper questions about your career while framing it in those concrete terms. It is somewhat ironic that my first thought upon finishing this book was to seek out Larson's book on engineering management so that I might compare/contrast the different tracks and roles. (I've got some more reading and meditation to do!)
  
  I would definitely recommend this to any senior software engineer who is considering some kind of Staff+ role as their next step. Really think about whether this kind of work would energize you, and whether you believe you could provide the kind of leverage to accelerate the organizations you'd be supporting. And if that gives you some good feels? Maybe try that "promotion packet" exercise next…
• 
  Amir Sarabadani

  4.5
• 
  Grzegorz Witek

  I'm quite conflicted about this book. I'm not sure if it's good or bad, I think it's not what I expected.
  
  First of all, almost half of the book are interviews with staff/principal engineers from various companies. Most of them follow almost identical list of questions like "what are your responsibilities" or "what advice do you have for people who want to be staff engineers ". These interviews are somewhat interesting, but a lot of the advice is very similar. I believe they shouldn't cover 150 pages.
  
  The remaining half talks about leadership beyond the management track. It covers a bunch of topics and I find that part too shallow. A lot of sections are very short, like 2-3 pages.
  
  Having just finished it, I feel the book lacks detail, but I'm not sure how much of it it's author's fault. I believe that the staff engineering track is something so new and blurry that it's hard to be more specific. In every company the staff role might look quite different and it's hard to cover all that.
  
  Another thing that came to my mind is the difference between engineering manager and staff engineer - the title of the book says "leadership beyond the management track", but a lot of stuff covered in the book applies to managers as well (and some interviewees mention they have direct reports), which makes the definition of what is staff engineer even more blurry.
  
  Overall I believe "An Elegant Puzzle" (author's previous book) was much more valuable in terms of specific advice. A manager myself I wanted to learn about staff engineers so that I know how to work with them and in the future how to manage people in such role, and while I learned about it, I feel like it was an appetizer, not the main dish.
  
  One last note: I believe the most valuable part of the book is the end: a list of specific advice on how to hire and manage staff engineers, and a list of other books but also articles that talk about this topic.
• 
  SY77

  If you ever worked in software under illusion that being the best at what you do matters the most, I have bad news for you. Maybe you had a suspicion that it's not really about the quality of work, but still secretly hoped to one day be proved wrong. I regret to inform you that it is not a "meritocracy".
  
  Like in many professions, after a certain point it becomes predominantly about how you interact with other people. It doesn't matter that you're doing great and important work if nobody besides you thinks that. In fact, making sure it looks that way may be a bigger contributor to successful recognition.
  
  So next time your boss invites you to a cycle polo game or to a sauna you better make sure to show up – your career depends on it. On the other hand, if you are not invited it means you have a lot of work to do.
  
  Overall, a good book with a bunch of practical advice. I would also recommend it to those who are still considering a career in software.
• 
  Lukasz Nalepa

  For me, it was one of the most important books of the last year... Well I finished it only today (end of Jan), but I read most of it in 2021 :) Back on more serious note, I've learned a lot about good engineering leadership above the individual contributor level and concepts related to such type of work. I consider myself a technology professional with over 15 years of experience, but still I feel that this book opened my eyes a little bit, no how things should be done and organised. ​
  
  The book itself is not and extraordinary read though - I think it could be written a little bit better, with a bit different ratio of "book" vs interviews of Staff Engineers who volunteered to share their experience.
• 
  Harrison Dempsey

  Lots of food for further thought from this one. I'm not an engineer nor looking to swap back to the IC track anytime soon, but it's helpful to understand the mindset and challenges that those in senior craft roles face across different organisations. Good stuff, have already recommended it to a couple of people.
• 
  Michał Węgrzyn

  The best and the only books that addresses this specific field. Based on real cases and interviews with a lot of examples it provides is a solid roadmap for current and future staff+ engineers and their managers.
  
  If you are a software developer - must read
• 
  Charly Poly

  An exciting book that covers the mysterious world of the IC track after the Senior level.
  As a Tech lead, the first part of the book, dedicated to a more summarised content of the Staff/Lead mission and whereabouts, did resonate and helped me identify my improvements zones and the next steps in my career.
  The second and last part of the book, dedicated to stories, was really insightful, with a broad diversity of Staff+ roles (lead, architect, advisors).
  
  The only downside of the book, more linked to the industry itself, is that very few companies offer such Staff+ and well structured IC track, leading the book to quote often the same type of super well-known big companies such as Stripe, Uber, etc...
  
  I would definitely recommend it to any engineer or engineering manager willing to pursue and create a track in IC through the Staff+ approach.
• 
  Povilas Balzaravičius

  Great book Will! I especially liked the book is not a collection of abstract knowledge but real world experience. There are stories and people behind author's words. These stories refutes some myths and proves that staff role and responsibilities are very different across different companies.
  
  Why not 5 stars? The second part of book consists of a set of interviews with staff engineers of various companies. While each interview is interesting, reading all of them at once felt very monotonous. I have slowed down myself and read 1-2 interviews per evening.
• 
  Steven

  Great introduction to staff eng role
  
  I really like how Will writes: he explores relevant systems and tried to distill them. As a newly minted staff eng, this book really helped jumpstart my modeling of how to be effective.
• 
  Avraam Mavridis

  3.5 It's mainly interviews with Staff engineers, interesting but kinda repetitive.
• 
  Ozan

  Top recomandation in my view for people who want to operate at staff/pursue engineering leadership, but as well for those who already do.
  
  A really good book that provides a lot of insight for those who are looking to choose a technical leadership path (beyond management track as the title states). Further one can observer different archetypes of staff engineers and how they fit in the company org. The book also tries to define what a staff eng does..since sometimes is easy to explain your job, but maybe the actual role.It also shows what if feels to operate at staff level and how one can have an impact.There is as well a lot of accent on sponsorship,partnership and leading by influence.
  You can read the book from end to end, but also it makes if you want to jump ahead.
  Beyond all the good advice, out of which I personally experienced before getting to this book, I really enjoyed the stories of the people who have the same roles of Staff/Staff+ eng. in different companies. Their way of sponsoring, mentoring, views (and many more..I will let you read through from this point) and even how they spend their days during a work week, were quite inspirational.
  I truly recomand the podcast as well, where you can further listen to the stories.
  In the end, the book offers a large amount of resources that can be inspirational for your career.
• 
  Andrew Fiorillo

  I would rate this book as a solid 3 to be honest but there were a handful of legitimately good gems which I think warranted bumping it up. For example, Larson articulates a way of interviewing for staff roles by looking for a collection of "signals" rather than focusing on a particular skillet etc -- this isn't particularly revolutionary, but it agrees with my philosophy on the subject and reminded me of the better writing the author has done.
  
  That said, this book takes a backseat to Larson's other work. There is no coherent narrative through the book; just a summary of Larson's feelings on the interviews he did, those interviews, and a sort of appendix restating the summary in more compact language. There is a lot of fluff (about 60 pages of end note links, the full interview transcripts that were the basis for the first and third sections of the book) and a lot obvious advice. While I have no doubt that some readers would benefit from being told that being intransigent during a meeting is not a good way to keep getting invited to meetings, to me it undermined the credibility of the book.
  
  I think reading it was a net positive, but there is definitely better material I would (and will) recommend. Some of which is on Larson's blog!
• 
  Boyan

  I am happy I finally found out a read that confirms (to a high degree) my thoughts about management/IC tracks separation in many IT companies. I have always had the feeling that both can run hand-in-hand and this book presents the Staff+ roles as such examples. I have been operating at this level in my last companies without necessarily calling a staff role, but combining coding (to a varying degree), mentoring, architecture, prototyping, product discussions, team growing is something I have been doing and something that I enjoy mixing. I can highly recommend this book to people in any role in IT - even if you don't want to reach a staff+ role, it is interesting to read the challenges such people have. Although I find the order of (some) topics in the book unnatural, they all contain useful information. You have access to a bunch of interviews with people holding staff+ roles from big IT companies like Dropbox, Stripes, Slack among others. Even if you might find them a bit too "Silicon Valley"-ish, I find these stories interesting.
• 
  Leonid

  Felt somewhat of a "downward slope": beginning was really exciting, but lots of advise from "Operating at staff" felt quite generic, and so lacking actual impact and applicability. Interviews part totally lost me - interview excerpts were great in the first part of the book to illustrate certain points, but just a collection of answers didn't feel that interesting.
  However, the book is easy and quick to read, and it pushed me to think quite a bit about further career, and how do I see self-development, so that's absolutely a plus.
  I think, it won't be something I would be coming back to re-read in future, but it can be really helpful at certain points of your career, to get a wider perspective.
• 
  Mark Sutherland

  There are very few books that address the mid to late career of the software engineer and this is one of them.
  The actual advice of the book is in a fairly short first sections and more than half is a series of interviews with staff engineers from various familiar web stack companies. These are interesting but it would have been nice to get some perspective from more established tech companies like IBM, Microsoft, Cisco etc. who have had these roles and people working in them long enough for them to retire. Instead we have the perspective of a 25 year old director of engineer who works remotely for a silicon valley startup.
  That said, what is in here is worth paying attention to, particularly if you are just starting to figure out what a career past the senior engineer plateau might look like. I'm hoping Tanya's own contribution to the literature goes a bit deeper though.
• 
  Jorge Maroto

  Probably one of the best books I've read. Not only to understand what my current position means, as to learn about other points of view from different people.
  
  The book is mainly structured in 3 parts:
  - The theory/summary of some concepts explained by the author.
  - A series of stories from different Staff/Principals/etc from popular companies
  - Resources (how to manage staff engineers / how to interview them / etc)
  
  Probably, my favorite part of these would be the stories, as it addresses the same questions from a different point of views, and I've learned a lot of stuff there.
  
  I don't tend to re-read the books, but probably this will be an exception, as another thing that I've liked is the amount of references that it has at the end of the book (more than 300), and how easy is to read these thanks to the editorial added a QR code next to each one on the printed edition :)