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.

Core Functions

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

• Set technical direction

• Mentor and sponsor

• Provide engineering perspective

• Explore

• Act as "glue"

• Write software (sometimes)

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.

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:

• Review design docs by 5 peers

• Review 5 design docs to define a strategy

• Review 5 strategy docs to craft a vision

Some sources cited by the author:

• Stitchfix Framework for Responsible Innovation (15 minutes)

• How Big Technical Changes Happen At Slack (15 minutes)

• Good Strategy Bad Strategy (336 pages)

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:

1. Hot spots

2. Best practices

3. Leverage points

4. Technical vectors

5. Measurement

6. Quality teams

7. Quality programs

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.

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.

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.

Keavy McMinn at Stripe (Previously of Fastly)

Keavy McMinn emphasizes support and relationship building just like others. Interestingly, Keavy worked at GitHub, an early pioneer for remote work and presents a great counterargument to the serendipity of in-office environments which is intentional relationship building efforts. In her career, switching companies and gaining a title led to much more organizational trust. Unlike others interviewed for Staff Engineer, public speaking turned into a useful career development platform for Keavy. She gives advice to new Staff Engineers to avoid pervasive "hero" mentalities and the need for singular epic innovations or achievements compared to supporting others and surrounding herself with peers that challenge you, even outside your domain or company.