Staff Engineer

Leadership beyond the management track

Chris Shumaker's notes on the book by Will Larson

Notes from October 14th, 2024 through November 6th, 2024

Book Notes By Chris

Thus far, Staff Engineer has been an interesting read that delves into the multiple ways people transition from pure engineering to technical leadership roles without becoming managers. There are lessons to learn for both junior engineers looking to grow and for managers to understand how strong engineering teams function. The author, Will Larson, is a thought leader working to bring many perspectives to one place. 

As I read this book, I aim to examine the overlap between true leadership and the corporate version of leadership. We see the idea of leadership in politics, the military, consulting firms, universities, movies, religions, and in local communities. We often see those figures putting themselves at risk or at a disadvantage. How often do we see that in a company? I'd say very infrequently. The standard flavor of corporate leadership to me is getting other people to do things they don't want to do or doing it for them because that's what the business needs. This would work if employees weren't discriminated against and paid standard wages while leaders take home huge sums. I don't have all of the answers but I can say that we all need to think more like "true" leaders and not just "business" leaders.

Cover Of The Book "Staff Engineer"

Before Reading Further

Please check out these awesome people for their role in this book:

And please share anyone else's site or profile you think should be here too!

Introducing The 4 Archetypes

I am grateful that Larson prefers to highlight women and minorities as examples of individuals in these roles. Several of them have their own blogs and a few even have books. 

Personally, I have seen plenty of tech leads. This archeteype to me doesn't really benefit from the proliferation of staff engineer roles within the industry, at least not in terms of gatekeeping. The attachment to staff roles seems to have inflated the sense of investment at large companies along with excess rounds of technical screening. Being more available, this role should be more accessible but I actually think that it is harder for many to obtain.

I have lots of experience as an architect and a solver from past consulting projects. Consulting projects typically allocate account managers and sometimes project managers, scrum masters, and tech leads. It is not uncomon in these situations for solutions architects or experts on the central vendor technology to function as architects when things are going well and solvers when they are not.

Larson suggests that the right hand is more common in large companies because in his description, the staff engineer is the right hand to a very senior or executive leader within a larger hierarchical organization. However, I have seen people fulfill the "right hand" role in smaller organizations where they partner closely with influential managers and leaders to drive organizational change. If this style suits you, I would not forego it simpy because you do not work at a large company.

Regarding true leadership, there are some parallels to leadership styles here. Successful leaders learn and understand multiple styles and apply them appropriately. There is an aspect to understanding yourself, playing to your strengths and developing your weaknesses here. But what will matter to the people you lead is that they have compensation, healthcare, physical and psychological safety, and opportunties of their own. How will you balance your preferred archectype or style, your own strengths and weakness, and the real needs of others? Will you become a solver when your expert is in the hospital or will you stick rigidly to your architecture role and let the issue (and possibly the individual) fail?

Core Functions

Larson summarizes the core functions of a staff engineer as follows:

Titles, Titles, Titles

Besides serving the business and others, there are reasons for the roles to exist for the individuals that posess them. Larson points to three main motivations: no longer needing to prove yourself, access to larger and more important decision-making activities, and compensation while debunking the idea that the role is just "better" or "more" of the same.

Book Cover The Staff Engineer's Path by Tanya Reilly

Glue Work

I mentioned that Larson highlighted women and minorities as his staff engineer examples. It is not lost on me that throughout these notes, I will be crediting him for his book which compiles their experience and work. It is also not lost on me that I am doing the same. 

Firstly, on sponsorship, Lara Hogan wrote a great post on the topic. You should read that before continuing. Just stop here. Read it. Takeaway: staff engineers build up those around them. If you look like me, you should absolutely be doing that, even if you aren't a staff engineer.

Second, on "being glue", Tanya Reilly wrote a great article and a book as well. You should read that before continuing. Just stop here. Read it. Takeaway: staff engineers build up those around them. If you look like me, you should absolutely be doing that, even if you aren't a staff engineer.

On true leadership, this one is much easier. If you have privilege, help those with unfair barriers. Make sure that they have a voice in your meetings. Make sure they have the same opportunities. Realistically, the status quo is already unfair, we will need to push beyond "fair" to see real change.

What Else Do They Do?

Larson digs deeper into specifics of the staff engineer's job citing: prioritization, strategy, quality, mutual agreement with authority, being a follower, focusing on truth over appearing correct, developing others, and having a strong peer network.

Prioritization

When it comes to prioritization, a number of tips are provided. Among them are things to avoid like "snacking", "preening", and "chasing ghosts". "Snacking" means picking up "easy" work items to fill time or to receive instant gratification instead of biting off more impactful work. Additionally, "preening" work which is work that makes you look good and "chasing ghosts" is work that builds dependency on yourself. As for work not to avoid, he discusses tackling deep "existential" issues, working where there's "room" not just "attention", developing others, "editing" an existing approach, helping stalling projects to close, and that which only you can do. The author closes by stating that focusing on these types of work as the best and most objective way to accumulate evidence of your experience and ability as you move along your career.

Define Technical Strategy

Larson spends much of this section describing the essence of a good technical strategy which is that it should be straightforward, clear, and grounded in understanding. There is a rule of 5 that systematizes the process:

Some sources cited by the author:

Manage Technical Quality

As a core component of any software organization, quality is of course called out by Larson as one of the staff engineer's responsibilities. Larson breaks down the approaches:

Larson lists hot spots first and suggests relying on them heavily as a substantial quality improvement tool. Hot spots are areas of your product which are in need of attention (help tickets, incidents, friction points, etc.). They are a clear and obvious signal to gaps in the product.

Interestingly, best practices are targeted as useful but often ambiguous or premature. There's work to be done with best practices to ensure that you are prioritizing the problem before proposing the solution.

Of the remaining topics, I feel that measurement is the most specific and useful callout. I agree with the author that code quality can be measured but it requires precision. Slapping code coverage into your toolchain aimlessly will not guarantee higher quality. 

Relationship to Authority

This section of the book is relatively short. The section focuses on the fact that as a leader, the guidance and direction you will receive will shrink while your accountability will increase. You are trading some of your "safety net" in order to provide one to others. Larson is adamant that your authority to your managers is determined by how you help them fulfill their vision and your authority over peers and engineers is determined by your ability to influence them. Title, in both cases, is not that important. 

Another theme of the section is surprises. In short, don't surprise your manager and manage information and feedback such that they do not surprise you. Provide your manage information rather than just opinion.

Time for another true leadership moment. For some, myself included, there is a rebellious nature to being a leader. It is not uncommon for leaders to be unconventional in some way. It's also sometimes necessary for them to have strong values and strength of will to tackle power disparities. Furthermore, phrases like "Speaking truth to power" can get stuck in our minds and subconsciously inform our world-view. In my earlier career, staying "aligned with authority" might have felt insincere. In this case, it's important that you find companies and managers with whom you are comfortable aligning and uphold that expectation for yourself. You need to be patient enough to find them, nurture the relationships, and forgive their moments of failure or shortcomings. You need to be willing to leave if your values drift apart. This can be hard if you are early in your career or not financially strong.

Wrestling with satisfying your needs and the needs of others is part of being a true leader. Introducing corporate interests and hierarchical organizations complicates that further. Ask yourself, "what impact do you want to have and what you are willing to commit for it?"

Being A Follower

There is a theme of supporting others through sponsorship and mentorship and about "getting out of the way" in Staff Engineer and other sources. While this section of the book is quite short, it resonates strongly with my experience. Taking accountability for decisions and failures, providing a fair or large share of work, and giving credit are common ideas of leadership in business today. This is especially true in the tech industry which is deeply rooted in egalitarianism and meritocracy. Those principles are not ubiquitous though. Different domains and situations expect different ideals. Sometimes an authority figure or a "strong" commander can be useful in complex or urgent situations, respectively. 

I first was introduced to this idea by *sigh* a TED Talk from *louder sigh* 14 years ago entitled How to start a movement by Derek Sivers. He used a hilarious example of a lone dancer at a music festival that builds into a crowd of dancers. The first person to join the lone dancer was a catalyst for everyone else's excitement and participation. 

I think this strategy is both underrated and under-appreciated. Leading by following is underrated because many who want to lead have the more classic or traditional vision of a leader, view it as a status which cannot fundamentally be shared due to scarcity or necessity, or simply because the expression is grammatical nonsense. To that I say, check your ego and focus on results which leads to my next point. Leading by example is under appreciated because of how damn effective it is. People love when you back them up and people who take initiative love when you let them lead by doing what they are already doing and building an audience for it and all the while, shit gets done.

"Learn To Never Be Wrong"

It is almost funny how Staff Engineer doesn't bother to acknowledge the wordplay or redefinition of the phrase "trying to always be right". There are helpful strategies here focused on helping you worry less about asserting your technical correctness and worry more about gathering information and commitment from your team through curiosity and involvement. A great tip from the book was to ask at least three good questions before sharing your own perspective. There was another great tip about dealing with "jerks" (people who make it hard to foster open discussions) by including "people they can't be jerks to" in your meetings.

A New Take On "Delegation" and "Development"

Larson calls this "creating space for others" and it is a phenomenal alternative to the classic ideas of delegation as a leadership skill. Most amateur managers and leaders understand that their value comes from others and that a team will get more done than they will individually. 

Specific advice is provided such as keeping a "sponsorship journal" and keeping it in balance. If it's low, figure out why and fill it up a bit and if it's full, try to make space for yourself. The author's perspective on this topic is all about including others while moving yourself out of the way.

Networking

Of course, what self-help book would be complete without a nod toward networking? Staff Engineer lists some interesting strategies for internal, external, and ambient networking. My addition to this topic would be to start thinking of networking in terms of friendships and relationships (albeit with professional boundaries). 

My outlook is that people are implicitly good and can learn, grow, and adapt (when they want try). So, reframing "networking" as developing deeper relationships with people I admire or respect is so much less exhaustive and easier to balance in my life. 

Even if you don't subscribe to my world view, there's no debating the idea that words and phrases in the corporate vocabulary like "networking", "connecting", and "reaching out" are overloaded. Replacing them with your own ideas about genuine interactions between professionals is a great way to take back control.

Presenting to Executives

Right away, this section hits home for me in describing communications with executives who are "uncannily good at one way of consuming information". That said, I think his advice around structured writing may be best for those without much experience in presentations. Whether you present to executives or not depends on the size of your company and how well you understand their preferences and styles depends also on the size and the culture of your company. The end of the section even highlights that this may be more advice than necessary with final tip of sending and early draft and accepting feedback.

Getting The Job

Larson introduces his chapter on how to get promoted to Staff Engineer by identifying some key parts of the process: building a promotion packet, taking on a Staff project, getting and staying "in the room", and becoming visible. He breaks down the rhetoric of an equal distribution of opportunity and discusses the merits of trying out management. Larson also calls attention to the "semi-permeable" boundary of leadership for women. Of the women he interviewed for the book, it was much more common to encounter friction to promotion and to leave a company to obtain the title.

At the time of this writing, it is November 6th, 2024, the U.S. has just finished its election results favoring Donald Trump over Kamala Harris, and among many theories about what led to the victory is the pervasive attitude that the U.S. is not ready for a woman to hold presidential office.

Not only does this voting outcome uphold the status quo, it can be highly discouraging for talented leaders. And, while politics is often taboo in the workplace, elections are just one of many life events broadly impacting our lives (and our businesses and our teams). 

True leaders do not avoid tough subject matter. Women can be true leaders.

Promo Packets

Someone once told me I should keep a "brag sheet" for accomplishments at work. I didn't take their advice. Now, here I am recommending that same advice to my readers and clients! Staff Engineer calls them "Promotion Packets". This is essentially whatever materials you provide to your manager that gets passed around at review time. The book lays out a great template that focuses heavily on specifics, measurement, and the who, what, and why of your work. There is a major emphasis on establishing an empty structure, reviewing it with your manager and peers, and filling it out over time so that there's no difficulty collecting the facts.

I think we all struggle to keep records of our accomplishments. We think we will remember them or that our manager will remember them. However, they'll be remembered along with the rest of your team and then reviewed by other managers you may not know so well for approval. It takes very little time to start and maintain and the early effort pays off at review time.

Sponsorship For Yourself

Not only does Staff Engineer require individuals to sponsor and mentor fellow engineers, they require sponsorship themselves. Larson advocates for building a relationship with you manager and asking for what you want directly. He also also recommends to working with your skip-level manager. An important element in this section is that it's not enough to ask for what you want and to seek feedback from your sponsor but also to facilitate their success as your sponsor, since they have organizational capital but limited time.

Completing A Project

In my experience, big projects are a great way to challenge yourself but they can come with a lot of expectations. They don't always go as expected both in terms of project completion but also in terms of the value they were expected to bring. No singular project has ever led my career to a promotion. That puts me into one of Will Larson's larger camps people who made Staff Engineer without a specific project. He does suggest that having one is a good checklist item to offset gatekeeping in an organization but mostly emphasizes their value in personal development and future self-promotion.

Being Around When Decisions Are Made A.K.A. "In The Room"

My simple takeaway for this section is that it's helpful to be in some meetings where key decision makers meet and to be mindful of your time and theirs. Specifically, do not be insistent or an "over-achiever" in these meetings because these people likely have a rhythm and appreciate efficiency. You also do not need to be in every meeting everywhere. The main thing is that you participate in some, even small, ways in listening to key decisions early and regularly and incorporate them into your work. And over time, you develop rapport and trust with those decision makers. The goal should be for you to execute on the company's goals more swiftly and accurately, not to show off.

I think this happens organically for a lot of people when they get tired of being "downstream" of important decisions that impact their team. They seek to be included in information and decisions earlier so that they can plan appropriately and, at times, advocate for decisions that make their team more effective (hopefully in a way that makes the company more effective too). The downside of this approach is that it's reactive and has a negative context. So, the moral of the story is to do this proactively so that it's not such a forceful or untimely effort.

Visibility

This actually came up for me recently! I think Staff Engineer offers some great ideas around visibility. For example, you needn't treat visibility as a grand spectacle always. You can "cheerlead" for your teammates and participate in reviews or docs, ask questions in meetings. Essentially, activities that show you're an engaged employee (perhaps not coincidentally) relate to being recognizable and trustworthy. One also doesn't need to be limited to activity within their company and instead can create online blogs or present at conferences. The author does call out executive recognition as being of great import and that visibility has its limits. It shouldn't be the only thing you do, especially since letting others shine is an important part of leadership.

Looking Somewhere Else

The final section of the book before the author begins to focus on individual stories discusses the option of leaving your company, how to know if it makes sense, and tips for dealing with the challenges of interviewing and negotiation. While the entire section is useful, I found a few points particularly interesting. Specifically, these points are about finding the right company. One tip is to consider that the bias inherent in a company can work for you when it's clear that the company disproportionately values you. Another is to consider your preference for meritocratic versus proceduralist companies. This last point is one that resonates for me. Having worked at largely meritocratic organizations with one major exception, I honestly say that I see the value of either and the potential for frustration with a mismatch.

Stories

The rest of the book focuses on stories from staff engineers and their journey. I won't go into all of them but you may want to check them out on LinkedIn or see if they have any published materials if their careers seem inspiring to you.

Michelle Bu at Stripe

Will Larson leads his Staff Engineer stories with a piece from Michelle Bu at Stripe. Michelle was the Payment Products Tech Lead at the time the book was written. According to LinkedIn, she moved into Head of Engineering for Commerce & Customers and is now a Standards Librarian. Michelle’s piece describes two major categories of staff engineers focusing on either depth or breadth. In her career, Michelle focuses on breadth which leads to less time in hands-on coding work, including reviews, and on-call rotations. However, she does make sure to keep abreast of the types of incidents that happen as a feedback mechanism for past choices. Bu also focuses a lot on documentation and states that they are the most scalable form of distributing information. Michelle spends ample time working with others to form shared higher order mental models that make decision making faster and better at Stripe. Bu fights imposter syndrome to motivate technical growth and tackles ambiguity by being adaptive. Michelle cares a lot about Stripe and that’s really interesting. 


I think we all need to be a little open to the idea that our companies are worth caring but I recognize how challenging that may be after the wave of layoffs we saw in 2024 or the US tech-centric politics of early 2025? Crucially, Bu focuses on the people - users and colleagues - not the corporate entity. And I think that is key to being a True Leader, focusing on what matters to you and cultivating and protecting it fiercely. Is DEI important to you? Is consumer privacy important to you? Do you work in immigration or Women’s Rights? Even if it’s mental health and work/life balance, finding the way to do your job well while upholding your values is what makes you a leader. Sometimes, we lose sight of these things or they feel insurmountable. Bu’s advice goes further for me when we talk about ambiguity and adaptation.


Just recently, I actually made an Ecosia search about ambiguity in work and life, desperately hoping for clarity and reassurance only to stumble into a Reddit thread of Staff Engineers sharing their stories of continuous ambiguity. Not only that but on a separate occasion, my manager and I also discussed ambiguity and, without explicitly connecting the themes, adaptation was brought up as “one of an engineer’s strongest skills”. While I cannot claim huge success with Maker Consulting yet, I can say that without immense adaptation, I wouldn’t have even started.


All of this goes to show that stepping out of your comfort zone will create ambiguity and that won’t go away without support, constantly reapplied efforts, and adaptation. If you want to chase dreams and you want to grow, dreaming big and being ambitious will not come with answers. Goals and dreams are wildly different things but you can achieve both!

Ras Kasa at Netflix (Previously of Mailchimp)

Staff Engineer Ras Kasa writes that his biggest impact comes from supporting, mentoring, and coaching others. While not strictly completing a staff project, operating on high impact projects with lots of visibility was key to his career growth.

What did you think?