Staff Engineer: Leadership Beyond the Management Track

by Will Larson

Success will often mean interpreting business needs, communicating a clear direction, defusing a looming crisis, convincing teams to agree on tradeoffs, or just being a good influence.

The lack of resources for senior engineers is part of a larger problem: it’s easy to lose track of what the job even is. Engineers promoted beyond “senior software engineer” can find themselves alone as they navigate an under-defined new role, grappling with the mysterious notion of “impact” to understand whether they’re working on the right things, and struggling to adjust to feedback loops that come in quarters or years instead of sprints.

What if you want to advance your career without becoming an engineering manager? Many companies will answer that question by excitedly telling you that they have a two-track software engineering career path. Engineering management is the first track, and the second is technical leadership. The technical leadership track is populated by titles like Staff engineer and Principal engineer. That this second track exists at all is a sign of progress, but there’s much work left to make it both accessible and impactful.

Many companies only have a subset of these titles, slowly adding more as their team grows, but companies that only have one technical leadership title almost always use Staff.

The Tech Lead guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities.

The Architect is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership.

The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to ...

Tech Leads are the most common Staff archetype and lead one team or a cluster of teams in their approach and execution.

While they’re coding less, they are still the person defining their team’s technical vision, and stepping in to build alignment within the team on complex issues.

Another factor is that the day-to-day work of a Tech Lead is most similar to the work you’d already be doing as a Senior engineer, making it a fairly intuitive transition. Most importantly, an organization needs roughly one Tech Lead for every eight engineers, making it far more common than other archetypes.

Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role.

Being a Staff-engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.

Architects are responsible for the success of a specific technical domain within their company, for example, the company’s API design, frontend stack, storage strategy, or cloud infrastructure. For a domain to merit an Architect, it must be both complex and enduringly central to the company’s success.

There is a toxic preconception that Architects design systems in isolation and then pass their designs to others to implement.

The Solver is a trusted agent of the organization who goes deep into knotty problems, continuing to work on them until they’re resolved. Folks in this role are moved onto problems identified by organizational leadership as critical and either lacking a clear approach or with a high degree of execution risk.

The Solver is most common in companies that think of individuals, rather than teams, as the atomic unit of planning and ownership. In such companies, it’s common to see the Solver become prevalent in the place of the Tech Lead.

The role of a Staff-plus engineer depends a lot on what the team needs and also what the particular engineer’s strengths are. From my experience, the responsibilities of a Staff-plus engineer can change over time.

Staff engineers speak for their companies’ technology. Technology cannot speak for itself and requires effective advocates on its behalf.

One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles, you may have tried to influence decisions towards technology choices you were motivated by; in senior positions, you’re accountable to the business and organization first and yourself second.

In my current role, I feel energized when someone I’ve sponsored sends an announcement that they’ve shipped their work, or when I see that I’ve helped shape or shift an engineering team’s model of an important topic. It’s these teams, not me, who are doing the hard work day-to-day of building and supporting their technology. I measure my impact based on their progress and, more importantly, the directionality of that progress and the alignment of their work to the company’s goals.

You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics.

The most effective Staff engineers pair a moderate amount of mentorship with considerably more sponsorship: putting your thumb directly on the scale to help advance and support those around you.

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature.

It’s impolite to end any discussion of the Staff engineer role without opining on the first question that Staff engineers ask when they congregate in a room together: “Do you still find time to write software?” The answer is, of course, it depends!

“The more senior you get, the less your job is about code.

the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company’s public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects.”

Even if you’re not writing much, you’ll be reading a ton of your coworkers’ code and doing a fair number of code reviews.

You’re more respected from the outset, and that’s been really noticeable.

A Staff-plus title allows you to reinvest the energy you’ve previously spent on proving yourself into the core work you’re evaluated on.

Being a Staff-plus engineer, especially a broad-scoped Staff-plus engineer, is a very different job than being a Senior engineer. It’s important to take a step back and think about whether it’s a job you really want.

The title will get you over the ledge once you’re close, but it’ll never do as much work as you’d expect.

how do you work on what really matters?

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.

We only get value from finishing projects, and getting a project over the finish line is the magical moment it goes from risk to leverage. Time spent getting work finished is always time well spent.

I kind of think writing about engineering strategy is hard because good strategy is pretty boring, and it’s kind of boring to write about. Also I think when people hear “strategy” they think “innovation”

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

Durably useful engineering strategy and vision are the output of iterative, bottom-up organizational learning.

You should write design documents for any project whose capabilities will be used by numerous future projects. You should also write design documents for projects that meaningfully impact your users. You should write a design document for any work taking more than a month of engineering time.

Start from the problem. The clearer the problem statement, the more obvious the solutions. If solutions aren’t obvious, spend more time clarifying the problem. If you’re stuck articulating the problem, show what you have to five people and ask them what’s missing: fresh eyes always see the truth.

Keep the template simple. Most companies have a design document template, which is a great pattern to follow. However, those templates are often expanded to serve too many goals. Overloaded templates discourage folks from writing design documents in the first place. Prefer minimal design document templates that allow authors to select the most useful sections and only insist on exhaustive details for the riskiest projects.

Gather and review together, write alone. It’s very unlikely that you personally have all the relevant context to write the best design document on a given topic. Before getting far into the process, collect input from folks with relevant perspectives, particularly those who will rely on the output of your design document. However, be skeptical of carrying that collaborative process into writing the design document itself. Most folks are better writers than they are editors. This means it’s usually harder to edit a group document into clear writing than to identify one author to write a clear doc...

Prefer good over perfect. It’s better to write a good document and get it in front of others than it is to delay for something marginally better. This is particularly valuable to keep in mind when giving feedback on other folks’ designs; it’s easy to fall into the trap of expecting their designs to be just as good as your best design. Particularly as you become more senior, it’s toxic to push every design to meet the bar of your own ...

you want to improve yours, my best advice is to reread your designs after you’ve finished implementing them and study the places where your implementation deviated from your plan–what caused those deviati...

A few interesting strategies to read while thinking about writing your own are A Framework for Responsible Innovation and How Big Technical Changes Happen at Slack.

every missing document is missing for a good reason.

Write until you start to generalize, and then stop writing. If you can’t be specific, wait until you’ve written more design documents.

Show your work. In math classes growing up, you had to show your work to get full credit. Here too, you must show the rationale behind your opinions.

Some of the best strategies you write may at the time feel too obvious to bother writing. “When should we write design documents?” is a strategy worth writing. “Which databases do we use for which use cases?” is a strategy worth writing. “How should we stage our migration from monolith to services?” is worth writing, too.

Stay concrete and specific. Visions get more useful as they get more specific.

Force yourself to write something compact, and reference extra context by linking to other documents for the subset of folks who want the full details.