There’s a lot of discussion around the different career paths a software engineer can pursue. The two most common ones are people management and the individual contributor (IC) track.

Throughout my journey as a software engineer, I’ve noticed that there have always been plenty of resources available for the management track. In many companies, however, once you reached the ceiling of the technical track, which was often the Tech Lead position, there was nowhere else to go. If you wanted to keep growing professionally and financially, moving into management often became the only option.

The problem was that this sometimes placed people who weren’t a good fit for management in roles that didn’t suit them. It also meant losing highly skilled technical professionals and individual contributors to management positions.

Earlier in my career, I had the opportunity to take on technical leadership responsibilities, as well as some people management. However, I’ve always been genuinely more interested in the technical track.

I’ve often noticed that there are plenty of resources, such as articles, books, and training programs, focused on management. But there aren’t nearly as many resources to guide engineers on how to actually operate as high-level individual contributors.

That’s exactly what this book club is about: Staff Engineer: Leadership Beyond the Management Track by Will Larson.

This is a book that changed the way I think about my career. Until then, though, I had only worked at companies that hadn’t really embraced the Staff Engineer role as described in the book. I believe it takes a significant level of organizational maturity to recognize the need for these professionals and make the most of what they bring to the table.

They remain individual contributors, but their impact is on a completely different level from that of a Senior Engineer.

This book covers several important topics about the Staff Engineer role, drawing on real-world experiences and stories. However, the goal of this post is to highlight the topics I find most relevant based on my own experience, particularly those that resonate with my current work environment.

Hopefully, this will give others some useful insights and inspire them to read the book and get the most out of it in the context of their own organizations.

Archetypes

Tech Lead

The Tech Lead drives the technical approach and execution within a particular team. They are usually embedded in a team and work alongside engineering managers, although they may also work across multiple teams, typically focusing on a specific area.

Some companies also have a Tech Lead Manager role, which combines individual contributor responsibilities with people management.

Architect

The Architect is generally responsible for defining the direction of a project, establishing quality standards, and determining how things should be built across specific areas.

This role typically combines deep technical expertise, an understanding of the product and user needs, and broad organizational knowledge.

Solver

This archetype typically steps in when dealing with particularly complex problems. Their job is to evaluate the situation, identify the best approach, and figure out how to solve it.

Solvers often work independently for extended periods and periodically bring technical insights and recommendations to organizational leadership.

Right Hand

This archetype extends the reach of an executive. Executives aren’t usually involved in developers’ day-to-day activities, and while the Right Hand remains an individual contributor, they act as a bridge between technical teams and executive leadership.

They often translate complex technical topics into something executives can understand and absorb without having to spend too much time digging into the details.

This is a particularly important role when you need to establish a connection between one or more technical teams and a leader who doesn’t have the time to stay involved in their day-to-day work, but still needs someone who can be there, understand what’s happening, and represent those teams.

My Take

What I find most interesting about these archetypes is that a company can have one or several of them, but it’s unlikely to rely on just one type. Organizational culture and the company’s context will often determine which archetypes are needed.

Another interesting point I’ve noticed from my experience as a Staff Engineer in a company with several Staff Engineers is that these archetypes naturally emerge as the organization grows and its needs evolve. However, the same Staff Engineer can often move between different archetypes depending on the situation.

For example, I believe I currently operate mostly as a Solver and an Architect.

I’m probably not quite a full-fledged Architect yet, as I’m still developing a deeper understanding of a fairly large organizational domain. But I see the Architect archetype as something I can grow into over time, as I gain broader organizational experience and develop the ability to operate with a higher-level perspective.

Today, operating primarily as a Solver, I don’t just propose solutions to critical problems within the domains I work in, including adjacent domains I occasionally touch. I also help solve those problems and distribute the resulting work across my own team and, occasionally, other teams.

It’s interesting because I believe the Solver and Architect archetypes are inherently connected.

Operating at Staff

Working on What Matters

It’s important to understand that as you progress in your career and move up the levels, expectations naturally increase as well.

As human beings, we have hobbies, families, and limited time to work. That’s why it’s particularly important at this level to focus on high-impact work.

You’re no longer just an individual contributor expected to deliver code. And with AI generating code and making it increasingly commoditized, writing code alone is becoming less of a differentiator.

The organizational impact of your work becomes an even greater responsibility at the Staff level. We’re moving away from the idea of the “super programmer” who becomes a Staff Engineer simply because of the sheer volume of code they produce.

In this context, finding your archetype and understanding what is expected of you within that role is essential. Ultimately, generating meaningful organizational impact is what makes working on what matters so important.

Getting in the Room and Staying There

One thing the book mentions, which I’ve also noticed after spending some time as a Staff Engineer, is that titles matter.

A title won’t do the work for you, but having the Staff Engineer title signals to others that you’ve earned your place through the experience and contributions that got you there. Whether that’s through proven results within the company or the experience you bring when joining an organization directly at the Staff level.

Another important point, particularly in remote environments, is understanding that there are many rooms you don’t necessarily see.

I’m talking about meetings and discussions that aren’t visible or open to everyone, unlike company-wide meetings such as All Hands. These are rooms you need to be invited into.

You need to understand which rooms you want to be in and why. At some point, you’ll get invited to them, but you also need to make a conscious decision about where to spend your time.

It’s important to know how to filter opportunities, when to join, and when to step away. You need to identify the rooms where your participation matters and where you can actively contribute, because these activities also become part of the organizational expectations associated with your level.

Stay Aligned with Your Manager

One of the most important topics in the book, and something I’ve seen in practice both before and after becoming a Staff Engineer, is the importance of staying aligned with your manager.

Your manager is your primary sponsor and your main advocate.

They’re the person who will stand behind you when they trust your potential to take ownership of a particular topic or project, and even when it’s time to advocate for your promotion.

Building that alignment means understanding your manager’s needs, figuring out how you can help them, unblock them, and take some things off their plate.

This is essential to establishing a relationship of trust with both your manager and your team.

I can confidently say that my excellent relationship with my manager, skip-level manager, and director has been essential to my accelerated growth within the company.

Having that alignment creates an environment where you can grow, access new opportunities, build trust, and naturally take on the challenges your manager brings your way.

Being “The Glue”

This is one of the most interesting concepts in the book.

It’s about being present in the channels where you need to be, participating in the discussions that matter, and helping unblock people across your team.

It’s also about building bridges between technical teams and stakeholders.

This is often considered thankless work. It goes beyond Story Points and the usual metrics used to measure individual contributions. Much of this work happens outside your team’s channels and may go unnoticed by the people who are primarily focused on their own team’s deliverables.

However, this work can give you significant organizational visibility.

People who don’t work with you directly will get to know you, interact with you, and appreciate the work you’re doing. As a result, you’ll be invited into more discussions, asked for your opinion, and trusted to review work from other teams.

Over time, this naturally increases your influence across the organization.

Staff projects

I’d say Staff Projects are a way to demonstrate that you have the skills to drive organizational impact. They also show that you can manage work that involves multiple interactions, complex decisions, and collaboration across different teams.

They demonstrate your ability to operate at a scope that goes well beyond your own team.

Staff Projects aren’t necessarily a requirement for becoming a Staff Engineer. Many of the people sharing their experiences in the book mention that they never formally had a Staff Project. However, many of them worked on projects that had a significant impact within their domain or area of responsibility, which could certainly be considered Staff Projects.

I’m currently wrapping up my first Staff Project, and it’s been a really interesting experience.

In my case, since this is a technical initiative with cross-team impact, I had the opportunity to truly understand what it takes to manage a technical project with organizational impact across multiple teams. This involved putting together a well-defined Request for Comments (RFC), getting it reviewed and approved, and breaking the work down into clearly defined tasks and milestones.

Throughout this journey, I’ve learned how important it is to gather feedback and leverage the knowledge of people who have deep expertise in areas I’m sometimes stepping into for the first time. That input is essential to making the right decisions and setting the right direction for a project with organizational impact.

Although I genuinely believe Staff Projects aren’t mandatory, if you get the opportunity to lead one and you’re aiming to become a Staff Engineer, I’d strongly recommend embracing the experience.

You’ll interact with multiple people, deal with a certain level of ambiguity, and often face situations where there isn’t an obvious answer. But I think that’s ultimately part of what being a Staff Engineer is all about.

A Staff Engineer needs to embrace ambiguity, be prepared to deal with uncertainty, and constantly step outside their comfort zone to learn how to navigate these situations.

This particular project has taken me approximately six months, from the initial discussions to its near completion.

Another important aspect of Staff Projects is patience. You need to understand that, in many cases, you’ll have to fit the work into your team’s existing product roadmap, either by allocating some of the team’s capacity or breaking your Staff Project down into smaller pieces that can be delivered over time.

Being patient and working closely with your team and your manager to find the right time and space for execution is essential. This is how you make sure the project actually gets delivered and achieves the organizational impact expected from a Staff Engineer.

Final Thoughts

If you’re looking to expand your understanding of what comes after becoming a Senior Software Engineer and are interested in moving toward roles such as Staff, Senior Staff, Architect, or Principal Engineer, I’d say this book is an absolute must-read.

It doesn’t just explain how to prepare yourself to reach these positions. It also teaches you how to navigate them once you’re there: the different archetypes you should be prepared to take on, how to build sponsorship for your promotion, how to work with your managers, and how to operate effectively at these levels.

It also brings together plenty of practical insights based on the experiences of people who have actually worked as individual contributors in these positions, across different organizations, technical teams, and Staff levels.

Before reading this book, I was already interested in becoming a Staff Engineer. After reading it, I felt even more confident that the individual contributor track was the right path for me.

More importantly, it helped me prepare for the transition, understand how to navigate relationships with my manager and the people around me, and learn how to influence others.

It gave me a better understanding of how to not only pursue the Staff Engineer title but also challenge myself, take on new responsibilities, and step outside my comfort zone.