The Staff Engineer Statute
Why the best engineering organizations have a dual career track
In my previous post (The Manager Manifesto), we discussed how different the role of the engineering manager is from that of an engineer, despite the clear overlap between them. I offered significant caution to those looking to follow the management path. In this post, we’ll discuss the alternative path of honing your engineering skills and becoming more and more senior as a technically focused engineer.
Why do we need this path in the first place?
This is a good place to start. As an engineering organization grows, there is still the need for both centralized and coordinated technical decision making across the teams / products / systems. Ideally, teams have a lot of autonomy in this area to accomplish their goals, but it can’t be 100% autonomy, or else you’ll have a hopeless fragmentation of technology stacks, tools, and processes. Think “80% autonomous / 20% coordinated” across teams, and in some cases centrally decided by a single person.
So who should drive these cross-team decisions? Who should figure out what to bubble up for wider discussion and alignment, vs. deciding to move quickly?
Some might say, “Let the managers take this on! They have lots of meetings anyway and can make sure we’re all aligned.”
In practice, the managers will become too overloaded with the rest of their job to be the primary advocate for technical concerns. They will not be close enough to the code. They will be too focused on what their team is delivering, less able to look at the technical considerations across the entire company. See The Manager Manifesto for a more detailed explanation of why this won’t work.
Others might say, “Shouldn’t we have a single architect who does this?”
In practice, this only solves the problem at the top level. This architect can’t know every line of code and why it was written the way it was. They can’t attend every team meeting and look out for cases where the team isn’t solving a problem the right way. They become a single point of failure and a bottleneck for the organization.
The right solution is to have a community of engineers who work together across teams. They can be of varying seniority and having varying scope, but all are well-respected engineers above a certain level. All are technically focused and not burdened with also having to be a manager. These people are typically called Staff Engineers (also Lead Engineers, or Principal Engineers, depending on the organization).
The staff engineer is typically the same job level as an engineering manager, and is typically one level higher than the “career level” of an engineer. Meaning that, even if you work hard and stay at a company for a long time, you might not make it to this level, but it’s OK. Engineering teams need strong “senior engineers” too.
Staff engineers work in teams and across teams. They partner with engineering managers to ensure the right technical decisions and oversight for the teams they work with. And they work with each other, and sometimes with more senior versions of themselves with broader responsibility, to drive a coherent technical roadmap for the company.
There are at least 3 different archetypes of staff engineer that naturally occur in the industry: Those that operate primarily with a team or initiative (the “tech lead”), those that operate across many teams, projects, and systems to ensure coherence (the “architect”) and those that focus on hard problems wherever they go, often moving from team to team (the “solver”). There is a great write-up on StaffEng on this topic, and I’d also recommend the overall site for deeper descriptions of staff engineers, what they do, and how to excel at being one.
Note: For the rest of this post, we’ll use the term “staff engineer” for both the “manager equivalent” level engineer in the organization and also the more senior roles that can occur in larger organizations, sometimes with titles such as principal or distinguished engineer, architect, or technical director.
Now, back to the topic of dual career ladders, and comparing this track to the manager track.
Remember the Manager Manifesto, which talked about what managers are: 1) Managers first, engineers second, 2) Accountable for everything that their team does, and 3) Leaders, as well as what managers are not: 1) The “smartest people in the room”, 2) Order-givers, and 3) Technical leads or architects.
Let’s think about what a staff engineer is, and what they are not. Consider it a corollary to the Manager Manifesto (given my alliterative tendencies, called “The Staff Engineer Statute”).
The Staff Engineer Statute
Staff Engineers are:
- Experts: They have developed domain expertise to make better designs and decisions, and set the standards for their area. They are continuously honing and updating their knowledge, both inside and outside the company, and use this knowledge to drive innovation.
- Teachers: They seek to improve the team by teaching and mentoring other engineers. They make time to properly write things down and walk through topics with others, whether one-on-one or in groups.
- Leaders: They lead by example, by driving decisions and by influencing others. The best staff engineers are among the most respected leaders in their department, or even their entire company.
Staff Engineers are not:
- The “smartest people in the room”: Their job is to see the right technical decision made; they will balance delegation to teams (for smaller, local decisions) with taking on the responsibility themselves (for larger, more global decisions). They seek to educate and uplevel others to achieve mutual understanding.
- Order-givers: They should ensure clear vision and priorities, but also seek to empower the team to make their own choices.
- Managers: They partner with managers to ensure a successful team and a healthy environment, but they do not bear the explicit burden of responsibility for people that a manager does.
Notice what is similar to the Manager Manifesto and what is different. Staff engineers must cultivate expertise, typically based on hard fought experience, and use that to enable the organization, be it by teaching, influencing, or making tough calls themselves. The best staff engineers are so well respected in the organization that they rarely need to resort to fiat or decree to get things done.They exemplify indirect leadership, where no one reports to them on the org chart, but their impact is widely felt.
At the same time, it is critical that staff engineers do not have to directly manage other people. To do so well requires years of hard work and focus, and getting good at managing other people is a distraction for the staff engineer. Instead, they closely partner with engineering managers to get things done. We’ll talk about this more in a bit.
The Dual Career Track for Engineers
So let’s assume that you’re convinced of the need for staff engineers, and how they differ from engineering managers, not just in responsibility but in mindset. How can this be encoded into the organization and come to life?
The most obvious way to get started is to find someone who has excelled in the staff engineer role and bring them onto your team as an exemplar. However, that is easier said than done, and even when they show up, it needs to be clear to the rest of the engineering organization as to how they fit in, and whether this role is a unicorn or whether others can grow into this role themselves.
A career ladder is often published when an engineering organization gets to a certain size, providing clarity on how the company thinks about roles, titles, and levels of engineers and managers. It provides a framework for performance expectations, allowing an organization to set a clear bar across teams. And it gives a roadmap to engineers on how their careers can develop if they choose to stay with the company over time.
The key point here is that a career ladder needs to take into account both the management track and the technical “individual contributor” or staff engineer track. Far too often, there is a clear definition on the first few levels of engineer, up to becoming a manager, perhaps a director, and onwards, but with a much more vague definition for the technical track and how it compares to the management track.
The best engineering organizations embrace the technical track and the related roles as equally valuable to engineering management roles, including:
- Corresponding staff plus levels defined for every management level, even if vacant for now
- The same compensation bands and perks as the corresponding management levels
- Staff plus engineers reporting to a manager of sufficient seniority (same level or higher)
- Staff plus engineers included in the right conversations along with managers, including hiring/performance decisions and strategic prioritization
As a CTO / VP of Engineering, I’ve always found it extremely useful to have at least one or two direct reports who are Staff plus engineers (typically Principal or higher). Reporting to me directly not only allows them to have a broader agency across teams / initiatives, but also exposes them to strategic discussions that they might not otherwise participate in.
Similarly, I’ve always found that it works much better to have a Staff engineer report to a more senior manager or director, even if this engineer might end up closely supporting a team with a dedicated engineering manager who is more junior.
Look out for these patterns if you’re designing a dual track, or if you’re joining an organization that claims to have one. It will tell a lot about how “real” the senior technical track is vs. “lip service”.
Safe Space
Another critical consideration for making the dual track successful is providing a safe, effective way for engineers to decide which track they should be on. Some organizations go so far as to create a hybrid role (typically called a “tech lead / manager” or TLM) as a formal level, while others simply provide the right “proving ground” for senior engineers who are showing potential as managers.
Either approach can work. The key is that an engineer can assume a role where they are in effect “managers in waiting”, with a subset of the responsibilities of an engineering manager, and close supervision and coaching from their manager along the way. If they a) do well and b) enjoy the shift in responsibilities and mindset, they can fully transition into an engineering manager role. Meanwhile, it’s very much OK, and should in fact be encouraged, for an engineer to realize that the management track is not for them, and they can focus on becoming a staff engineer.
Similarly, it needs to be absolutely OK for an engineer to fully apply themselves to the technical track, but then have a change of heart and realize they should try out management. However, I will note that the world is full of managers who should really be staff engineers, and not vice versa!
Partnering with Management
Armed with expertise and experience, a staff plus engineer can have a huge impact on an engineering organization or even the entire company. However, to fully drive the change they are seeking, they typically need to be great at partnering with those on “the other track”: The engineering managers and directors who run teams.
Managers are inherently making prioritization decisions all the time, by defining a team’s priorities and goals (often in concert with product managers) and also by directly allocating engineers to teams and projects. Need a team to put the brakes on features and help with an architectural shift? Need a skilled senior engineer to be freed up for a few months to work with you on a new technology evaluation or a complex data migration? Good luck doing this without having the managers aligned and bought into your plans.
This is why it is so important that staff engineers feel truly at the same level as engineering managers, including access to the same information and inclusion in the same discussions. Like any good cross-functional partnership, they need to develop close relationships built on trust, and rely on the other for what they are best at while also pressure testing any assumptions.
It’s the rare exception where staff engineers can be “left alone” to do their technical work and then rely on management to take care of the rest. It’s much more the case that they will need to work closely with managers of related teams, so anyone taking this path should embrace this aspect of the job and not avoid it.
Avoid the Self-Fulfilling Prophecy
So what happens if your organization doesn’t have a clear dual track, with both management and technical tracks at parity?
What tends to happen is that people go into management simply because they view it as the best (or the only) path for career growth. These people tend to not make the best managers. Why? Because they are not truly making the mindset change required in moving from engineer to manager, and try to outsmart their engineers, or don’t delegate properly, or run into any other number of problems. These engineering organizations tend to be more autocratic and “top down”.
If you don’t have successful staff plus engineers in your organization, it could be that they are right in front of you, but in management roles, and would benefit significantly from taking on an IC role.
But does all of this apply to startups?
To some, this seems like a big company problem. Facebook and Google have well designed dual career tracks, and many examples of hugely influential staff plus engineers. Meanwhile, very early stage startups tend to be completely flat, without titles or levels, operating as a single amorphous team.
There is a lot of room in between these two extremes. Any successful startup will enter a growth phase where the engineering organization scales up, splitting into multiple teams and identifying technical leads and eventually engineering managers.
My strong guidance would be that once you’ve decided to have true engineering managers, it’s critical to also define the staff engineer role as well and get a clear dual track structure in place. It will set the foundation that, as the organization grows, equal attention will be paid to both types of leadership development, and encourage people to make the right choices on which path to take.