The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change

by Tanya Reilly

Becoming a manager is a common, and perhaps default, career step for anyone who can communicate clearly, stay calm during a crisis, and help their colleagues do better work.

The staff engineer’s path is a little less defined. While many companies now allow engineers to keep growing in seniority without taking on reports, this “technical track” is still muddy and poorly signposted.

As a new staff engineer, you might have heard that you’re expected to be a technical leader, make good business decisions, and influence without authority—but

I want to have time to dig into new technologies, deeply understand architectures, and learn new technical domains.

I’ll unpack the staff engineer role by looking at what I think of as its three pillars: big-picture thinking, execution of projects, and leveling up the engineers you work with.

When acting as a role model, your review comments should make code and designs better, and your opinions need to be well thought out—you need to be right! Technical skills are the foundation of every staff engineer role, and you’ll keep exercising them.

If you’re someone who thinks that technical skills are the only ones that matter, you’re unlikely to find what you’re looking for in here.

you’ll find that work gets less annoying when you can persuade other people to adopt your ideas, level up the engineers around you, and breeze through the organizational gridlock that slows everyone down.

Good decisions need context

Gathering context takes time and effort.

Individual teams tend to optimize for their own interests; an engineer on a single team is likely to be laser-focused on achieving that team’s goals.

But management authority can overshadow technical judgment: reports may feel uncomfortable arguing with a manager’s technical decisions

Managers, as the people responsible for assigning headcount to technical initiatives, need to be part of major technical decisions.

In this same ideal world, though, everyone’s working on a beautiful new green-field project with no prior constraints or legacy systems to work around, and each team is wholly dedicated to that project.

And the murky and difficult parts of the project are not fascinating algorithmic research problems: they involve spelunking through legacy code, negotiating with busy teams that don’t want to change anything, and divining the intentions of engineers who left years ago.

One way to keep a project moving is to have someone who feels ownership for the whole thing, rather than any of its individual parts.

TPMs are responsible for delivery, not design, and not engineering quality. TPMs make sure the project gets done on time, but staff engineers make sure it’s done with high engineering standards.

That means that we need to learn from each other’s mistakes and successes, too.

No matter what the standards say, if the most senior engineers don’t write tests, you’ll never convince everyone else to do it.

Accomplishing larger things means working with larger groups of people—and that needs a wider set of skills.

Teaching is a form of leadership. Quietly raising everyone’s game is leadership. Setting technical direction is leadership.

You need to be able to dive into the details where necessary, ask the right questions, and understand the answers.

Staff engineers often take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else.

For some staff engineers, deep diving through codebases will remain the most efficient tool to solve many problems.

At staff+ levels, your manager should be bringing you information and sharing context, but you should be telling them what’s important just as much as the other way around.

As a technical leader, part of a staff engineer’s role is to make sure the organization has a good technical direction.

The more senior you become, the more you will rely on strong communication skills.

Our industry hasn’t settled on any standard model for how staff+ engineers report into the rest of the engineering organization. Some companies have their most senior engineers report to a chief architect or the office of the CTO; others assign them to directors of various organizations, to managers at various levels, or to a mix of all of the above.

But an engineer assigned to a single team may find it hard to influence the whole organization.

Reporting to a line manager may also mean that you’re reporting to someone less experienced than you are.

Be prepared to ignore your scope when there’s a crisis: there is no such thing as “not my job” during an outage, for example.

Part of the value of a staff engineer is that you don’t stay in your lane.

There will always be another side quest:

Managers might really like this—they get a very experienced engineer who can do a large percentage of the design and technical planning, and perhaps serve as a technical leader or team lead for a project.

An engineer who’s not busy can be inclined to make work for themselves. When you see a vastly overengineered solution to a straightforward problem, that’s often the work of a staff engineer who should have been assigned to a harder problem.

“The more senior you get, the more this becomes true, the more and more there is an expectation that you can shift across each of these four kinds of jobs easily and fluidly, and function in all rooms.”

If there’s one that you really hate, make sure you’re working with someone who’s eager to do that aspect of the work.

Coding has comfortingly fast feedback cycles: every successful compile or test run tells you how things are going. It’s like a tiny performance review every day!

manager (TLM), sometimes called a team lead, is a kind of hybrid role where the staff engineer is the technical leader for a team and also manages that team. It’s a famously difficult gig

As you grow in influence, you’ll find that more and more people want you to care about things. Someone’s putting together a best practices document for how your organization does code review, and they want your opinion.

Early in your career, if you do a great job on something that turns out to be unnecessary, you’ve still done a great job. At the staff engineer level, though, everything you do has a high opportunity cost, so your work needs to be important

A technique I learned from my friend Cian Synnott is to write out my understanding of my job and share it with my manager. It can feel a little intimidating to answer the question “What do you do here?”

Usually this “not my job” work is less dramatic, of course. It can mean having a dozen conversations to unblock a project your team depends on, or noticing that your new engineer is lost and checking in with them.

To reiterate: your job is ultimately whatever your organization or company needs it to be. In the next chapter, I’ll talk about how to understand what those needs are.

Staff engineering roles are ambiguous by definition.

These three maps already exist in your organization; they’re just obscured. When you join a new company, most of the big picture is completely unknown to you. A big part of starting a new job is building context, learning how your new organization works, and uncovering everyone’s goals.

Over time, you’ll get used to how news travels in your org and what you should pay attention

How do you get into the “room where it happens”? I’ll share some strategies in this chapter.

Let’s look at four of those risks now.

Being in your silo can mean that you lose your connection to what’s going on elsewhere in the company.