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

by Tanya Reilly

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.

Your big-picture perspective includes understanding what’s possible and having good judgment. When executing on projects, your solutions will need to actually solve the problems they set out to solve. 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.

To become adept at big-picture thinking, execute on bigger projects, and level up everyone around you, you’re going to need “humaning” skills, like: Communication and leadership Navigating complexity Putting your work in perspective Mentorship, sponsorship, and delegation Framing a problem so that other people care about it Acting like a leader whether you feel like one or not6

But titles do matter. The Medium engineering team wrote a blog post that lays out three reasons titles are necessary: “Helping people understand that they are progressing, vesting authority in those people who might not automatically receive it, and communicating an expected competency level to the outside world.”

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 often decisions that seem to belong to one team have consequences that extend far beyond that team’s boundaries. The local maximum, the best decision for a single group, might not be anything like the best decision when you take a broader view.

To travel in the same direction, groups need to agree on technical strategies: which technologies to invest in, which platforms to standardize on, and so on. These huge decisions can end up being subtle, and they’re often controversial, so essential to making the decision is being able to share context and help others make sense of it.

So, if you want to make broad, forward-looking decisions, you need people who can see the big picture. But why can’t that be managers? And why can’t the chief technology officer (CTO) just know all of the “business things,” translate them into technical outcomes, and pass on what matters? On some teams, they can. For a small team, a manager can often function as the most experienced technologist, owning major decisions and technical direction. In a small company, a CTO can stay deeply involved in the gory details of every decision. These companies probably don’t need staff engineers. But management authority can overshadow technical judgment: reports may feel uncomfortable arguing with a manager’s technical decisions even when there’s a better solution available. And managing other humans is itself a full-time job. Someone who’s investing in being a good people manager will have less time available to stay up to date with technical developments, and anyone who is managing to stay deeply “in the weeds” will be less able to meet the needs of their reports. In the short term that can be OK: some teams don’t need a lot of attention to continue on a successful path. But when there’s tension between the needs of the team and the needs of the technical strategy, a manager has to choose where to focus. Either the team’s members or its technical direction get neglected.

If you have more than a few engineers, it’s inefficient—not to mention disempowering—if every decision needs to end up on the desk of the CTO or a senior manager. You get better outcomes and designs if experienced engineers have the time to go deep and build the context and the authority to set the right technical direction. That doesn’t mean engineers set technical direction alone. Managers, as the people responsible for assigning headcount to technical initiatives, need to be part of major technical decisions.

No matter how carefully you overlay teams onto a huge project, some responsibilities end up not being owned by anyone, and others are claimed by two teams. Information fails to flow or gets mangled in translation and causes conflict. Teams make excellent local maximum decisions and software projects get stuck.

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. Even before the project kicks off, that person can scope out the work and build a proposal. Once the project is underway, they’re likely to be the author or coauthor of the high-level system design and a main point of contact for it. They maintain a high engineering standard, using their experience to anticipate risks and ask hard questions. They also spend time informally mentoring or coaching—or just setting a good example for—the leads of individual parts of the project. When the project gets stuck, they have enough perspective to track down the causes and unblock it (more on that in Chapter 6). Outside the project, they’re telling the story of what’s happening and why, selling the vision to the rest of the company, and explaining what the work will make possible and how the new project affects everyone.

Of course, quality, efficiency, and order are far from guaranteed, particularly when there are deadlines involved. When doing it “right” means going slower, teams that are eager to ship may skip testing, cut corners, or rubber-stamp code reviews. And creating good software isn’t easy or intuitive. Teams need senior people who have honed their skills, who have seen what succeeds and what fails, and who will take responsibility for creating software that works.

Staff engineers are role models. Managers may be responsible for setting culture on their teams, enforcing good behavior, and ensuring standards are met. But engineering norms are set by the behavior of the most respected engineers on the project. No matter what the standards say, if the most senior engineers don’t write tests, you’ll never convince everyone else to do it. These norms go beyond technical influence: they’re cultural, too. When senior people vocally celebrate other people’s work, treat each other with respect, and ask clarifying questions, it’s easier for everyone else to do that too. When early-career engineers respect someone as the kind of engineer they want to “grow up” to be, that’s a powerful motivator to act like they do.

Maybe now you’re convinced that engineers should do this big-picture, big-project, good-influence stuff, but here’s the problem: they can’t do it on top of the coding workload of a senior engineer. Any hour you’re writing strategy, reviewing project designs, or setting standards, you’re not coding, architecting new systems, or doing a lot of the work a software engineer might be evaluated on. If a company’s most senior engineers just write code all day, the codebase will see the benefit of their skills, but the company will miss out on the things that only they can do. This kind of technical leadership needs to be part of the job description of the person doing it. It isn’t a distraction from the job: it is the job.

As your compensation increases and your time becomes more and more expensive, the work you do is expected to be more valuable and have a greater impact. Your technical judgment will need to include the reality of the business and whether any given project is worth doing at all. As you increase in seniority, you’ll take on bigger projects, projects that can’t succeed without collaboration, communication, and alignment; your brilliant solutions are just going to cause you frustration if you can’t convince the other people on the team that yours is the right path to take. And whether you want to or not, you’ll be a role model: other engineers will look to those with the big job titles to understand how to behave. So, no: you can’t avoid being a leader.

Staff engineers lead differently than managers, though. A staff engineer usually doesn’t have direct reports. While they’re involved and invested in growing the technical skills of the engineers around them, they’re not responsible for managing anyone’s performance or approving vacation or expenses.

Leadership comes in lots of forms that you might not immediately recognize as such. It can come from designing “happy path” solutions that protect other engineers from common mistakes. It can come from reviewing other engineers’ code and designs in a way that improves their confidence and skills, or from highlighting that a design proposal doesn’t meet a genuine business need. Teaching is a form of leadership. Quietly raising everyone’s game is leadership. Setting technical direction is leadership. Finally, there’s having the reputation as a stellar technologist that can inspire other people to buy into your plans just because they trust you.

At this level, your goal is to solve problems efficiently, and programming will often not be the best use of your time. It may make more sense for you to take on the design or leadership work that only you can do and let others handle the programming. Staff engineers often take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else. Once the problem is tractable, it becomes a growth opportunity for less experienced engineers (sometimes with support from the staff engineer). For some staff engineers, deep diving through codebases will remain the most efficient tool to solve many problems. For others, writing documents might get better results, or becoming a master of data analysis, or having a terrifying number of one-on-one meetings. What matters is that the problems get solved, not how.6

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.

If someone asks you to work on something, you’ll bring your expertise to the decision. You’ll weigh the priority, the time commitment, and the benefits—including the relationship you want to maintain with the person who asked you for help—and you’ll make your own call.

But autonomy demands responsibility. If the thing they asked you to work on turns out to be harmful, you have a responsibility to speak up. Don’t silently let a disaster unfold.

You Set Technical Direction As a technical leader, part of a staff engineer’s role is to make sure the organization has a good technical direction. Underlying the product or service your organization provides is a host of technical decisions: your architecture, your storage systems, the tools and frameworks you use, and so on. Whether these decisions are made at a team level or across multiple teams or whole organizations, part of your job is to make sure that they get made, that they get made well, and that they get written down. The job is not to come up with all (or even necessarily any!) of the aspects of the technical direction, but to ensure there is an agreed-upon, well-understood solution that solves the problems it sets out to solve.

You Communicate Often and Well The more senior you become, the more you will rely on strong communication skills. Almost everything you do will involve conveying information from your brain to other people’s brains and vice versa. The better you are at being understood, the easier your job will be.

Your manager might have less visibility into your work and therefore might not be able to advocate for you or help you grow. An engineer working closely with a single team but reporting to a director may feel disconnected from the rest of the team or might pull the director’s attention into local disagreements that should have been solved at the team level.

In particular, if you’re reporting to someone low in the org hierarchy, make sure to have skip-level meetings with your manager’s manager.8 Find ways to stay connected to your organization’s goals.

If you and your manager have different ideas about how you can be most effective, that can cause tension. You can end up with a case of the local maximum issues I mentioned earlier, where your manager wants you to work on the most important concern of the team, when there are far bigger problems inside the organization that need you more. It’s harder for a technical or prioritization debate to happen on a truly level playing field when one person is responsible for the other’s performance rating and compensation. If you find that these arguments are happening a lot, you might want to advocate to report to a level higher.

Inside your scope, you should have some influence on short-term and long-term goals. You should be aware of the major decisions being made. You should have opinions about changes and represent people who don’t have the leverage to prevent poor technical decisions that affect them. You should be thinking about how to cultivate and develop the next generation of senior and staff engineers, and should notice and suggest projects and opportunities that would help them grow.

A scope too broad If your scope is too broad (or undefined), there are a few possible failure modes. Lack of impact If anything can be your problem, then it’s easy for everything to become your problem, particularly if you’re in an organization with fewer senior people than it needs. There will always be another side quest: in fact, it’s all too easy to create a role that’s entirely side quests, with no real goal at all.9 Beware of spreading yourself too thin. You can end up without a narrative to your work that makes you (and whoever hired you) feel like you achieved something. Becoming a bottleneck When there’s a senior person who is seen to do everything, the convention can become that they need to be in the room for every decision. Rather than speeding up your organization, you end up slowing them down because they can’t manage without you. Decision fatigue If you escape the trap of trying to do everything, you’ll have the constant cost of deciding which things to do. I’ll talk in Chapter 4 about choosing your work. Missing relationships If you’re working with a very broad set of teams, it’s harder to have enough regular contact to build the sorts of friendly relationships that make it easier to get things done (and that make work enjoyable!). Other engineers also lose out: they don’t get the sort of mentorship and support that comes from having a “local” staff engineer involved in their work.

A scope too narrow Beware, too, of scoping yourself too narrowly. A common example is when a staff engineer is part of a single team, reporting to a line manager. 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. Some engineers will love this too: it means you get to go really deep on the team’s technologies and problems and understand all of the nuances. But watch out for the risks of a scope that’s too narrow: Lack of impact It’s possible to spend all of your time on something that doesn’t need the expertise and focus of a staff engineer. If you choose to go really deep on a single team or technology, it should be a core component, a mission-critical team, or something else that’s very important to the company. Opportunity cost Staff engineers’ skills are usually in high demand. If you’re assigned to a single team, you may not be top of mind for solving a problem elsewhere in the org, or your manager may be unwilling to let you go. Overshadowing other engineers A narrow scope can mean that there’s not enough work to keep you busy, and that you may overshadow less experienced people and take learning opportunities away from them. If you always have time to answer all of the questions and take on all of the tricky problems, nobody else gets experience in doing that. Overengineering An engineer who’s not busy can be incli...

Do you prefer to focus narrowly on a single problem or technology area? Or are you more inclined to go broad across multiple teams or technologies, focusing on a single problem only when it can’t be solved without you? Being depth-first or breadth-first is very much about your personality and work style. There’s no wrong answer here, but you’ll have an easier and more enjoyable time if your preference here is lined up with your scope. For instance, if you want to influence the technical direction of your org or business, you’ll find yourself gravitating toward opportunities to take a broader view. You’ll need to be in the rooms where the decisions are happening and tackle problems that affect many teams. If you’re trying to do that while assigned to a single deep architectural problem, no one wins. On the other hand, if you’re aiming to become an industry expert in a particular technical domain, you’ll need to be able to narrow your focus and spend most of your time in that one area.

Yonatan Zunger, distinguished engineer at Twitter, describes the four disciplines that are needed in any job in the world: Core technical skills Coding, litigation, producing content, cooking—whatever a typical practitioner of the role works on Product management Figuring out what needs to be done and why, and maintaining a narrative about that work Project management The practicalities of achieving the goal, removing chaos, tracking the tasks, noticing what’s blocked, and making sure it gets unblocked People management Turning a group of people into a team, building their skills and careers, mentoring, and dealing with their problems Zunger notes that the higher your level, the less your mix of these skills corresponds with your job title: “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.” Every team and every project needs all four of these skills. As a staff engineer, you’ll use all of them. You don’t need to be amazing at all of them, though.

There are actually very few jobs at senior levels that are purely hyperspecialists. It’s not a thing people tend to need.”

Although most staff engineers don’t have direct reports, some do. A tech lead 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. It can be challenging to be responsible for both the humans and the technical outcomes without feeling like you’re failing at one or the other. It’s also difficult to find time to invest in building skills on either side, and I’ve heard TLM folks lament a loss of career progression as a result.

Know why the problem you’re working on is strategically important—and if it’s not, do something else.

There’s a similar situation when a senior person devotes themself to the sort of coding project that any midlevel engineer could have taken on: you’re going to do a stellar job on it, but chances are there’s a senior-sized problem available that the midlevel engineer wouldn’t be able to tackle. To use an idiom my kid dropped profoundly one day, “You don’t plant grass in your only barrel.” Be wary of choosing a project that already has a lot of senior people on it. Scope out who else is working on the problem and whether they seem likely to succeed at solving it. Some projects may even be slowed by an extra leader joining.11 In general, if there are more people being the wise voice of reason than there are people actually typing code (or whatever your project’s equivalent is), don’t butt in. Try to choose a problem that actually needs you and that will benefit from your attention.

Paying attention means being alert to facts that affect your projects or organization. And that means continually sifting information out of the noise around you. If you can train your brain to say “That’s interesting!” and remember facts that you might need later on, you’ll start to add detail to your maps and build skills in synthesizing new information. What sorts of facts are useful? Anything that can help you or others have context for your work, navigate your organization, or progress toward your goals.

If your brain’s not naturally “sticky” for retaining information like this, I recommend challenging yourself to note down facts that might be useful later, just to get yourself into the habit of paying attention. Think of gathering context as a skill to build as part of your job.

If your customers are leaving in droves because your product is missing core features that your competitors have, it’s probably not the time to push for a focus on technical debt. If everything is smooth sailing and you’re anticipating growth, this might be a great time to make sure your foundations are solid.

As time passes, your company’s priorities will change and parts of your map will fog up again. To stay up to date with what’s important, pay attention to all-hands meetings for your group and others, ask for skip-level one-on-ones with your manager’s manager, and find face time with customers or teams that depend on you. If you don’t have business context about why (or whether) your work matters, ask for it.

Your good ideas don’t get traction Being right about a need for change is less than half the battle. You’ll have to convince other people that you’re right and, even more difficult, convince them to care that you’re right. That means knowing how to build momentum within your organization: figuring out who can sponsor your idea or help it spread, and how you can get it over the finish line and make it “real.” You don’t find out about the difficult parts until you get there Many obvious-seeming journeys have some crucial point that nobody has figured out how to get past. You may be attempting to scale a cliff that’s defeated many other people before. Staff engineers can often navigate past obstacles that less experienced engineers can’t, and it’s possible that you’ll be able to succeed where others have failed. But if you know where people got stymied in the past, you can take a different path or solve the hardest part of the problem first, so other people will be convinced the project is worth their effort. Everything takes longer Unless you know how your organization works, decisions that should be straightforward will take months or quarters. The mechanics of your organization’s planning cycles will affect you too. There are times of year when it’ll be easier to make the case for staffing a new project or to rally everyone behind some goal. If you announce an initiative immediately after the quarterly engineering OKRs have been set, you’ll have a hard fight and you may ha...

Staff+ engineers should be fairly autonomous and self-directed, but make sure your organization agrees: if your manager expects to approve where you spend your time, it can cause conflict if you don’t check in. If you’re used to seeking permission or having work handed down, and you move to a bottom-up company, you’ll be seen as having low initiative and have trouble getting anything done.

The DevOps Research and Assessment (DORA) group (now part of Google Cloud) has shown that high-trust cultures that emphasize information flow have better software delivery performance. It’s not surprising that an increasing number of software companies aim to have a generative culture. That means encouraging cooperative cross-functional teams, learning from blameless postmortems, encouraging experimentation, taking calculated risks, and breaking down silos. If your organization works like this, you’re going to have an easier time sharing information and making progress.

If you know whether your workplace is oriented around power, rules, or mission, you’ll find it easier to get things done. A feeling for how much people will share information, cooperate, take the time to help, and get behind new ideas will keep you safer and less frustrated as you cross the terrain. If you know you’re in a bureaucracy, you’ll have more success if you plan ahead, stay within the rules, and respect the chain of command. If you’re in a pathological organization, you’ll take fewer risks—and cover your ass when you do. Pushing a cart across cobblestones is more difficult than doing so across smooth paving. If you know the road will be rocky, you’ll budget more time, and you’re less likely to get mad at aspects of the situation that you can’t control.

The truth is something that a lot of us struggle to make peace with: being technically correct about a direction is only the beginning. You need to convince other people too—and you need to convince the right people. If you don’t understand how decisions are made in your organization or company, you’ll find yourself unable to anticipate or influence them. You might also find that you think you hold the same opinions as everyone else about what should happen next, and then find that suddenly everyone is advocating for a different path. If you consistently feel out of the loop, that’s a sign that you don’t understand how decisions are made and who influences them.

If you do get an invitation, don’t make anyone regret inviting you. Will Larson’s article “Getting in the Room” emphasizes that as well as adding value to the room, you need to reduce the cost of including you: show up prepared, speak concisely, and be a collaborative, low-friction contributor. If you make the room less effective at making decisions or sharing information quickly, you won’t be invited back. If you don’t get into the room, don’t take it personally, especially in orgs where people are still figuring out what their staff+ engineers are for and aren’t yet on board with it being a leadership role. While they work that out, you’ll have more influence (and will appear more of a leader) if you’re friendly and do good work than if you grouse about not being invited to things.

In their book Debugging Teams: Better Productivity Through Collaboration, Brian W. Fitzpatrick and Ben Collins-Sussman describe the “shadow org chart”: the unwritten structures through which power and influence flow. The shadow org chart helps you understand who the influencers of the group are, and it’s probably not the same as the actual org chart. These influencers are the people you need to convince before a change can happen.

It’ll be harder to keep everyone going in the same direction If the team doesn’t know the big plan, either they’ll go to the wrong place, or every decision will be long, complicated, and full of discussion. Sometimes navigating around difficulties will mean taking an indirect path. Everyone should be very clear about the course correction that will need to come after that milestone. You won’t finish big things If your team keeps focusing on short-term projects to solve local problems and pain points, you won’t be able to solve bigger, long-term problems that take multiple steps. The value of your existing projects might not be clear to people outside the team either. You’ll accumulate cruft If teams don’t know where they’re going, they have two options. They can try to be flexible enough to support every future state, creating solutions that are overcomplicated and hard to maintain. Or they can make local decisions, taking the risk that their direction won’t match everyone else’s and that their solution will be a weird edge case that everyone else has to work around. You’ll have competing initiatives In an organization that relies on grassroots or bottom-up initiatives, there might be multiple people trying to rally enthusiasm around completely different directions. They’re all trying to do the right thing and get people aligned, but the end result is chaos. Engineers stop growing Focusing only on short-term goals limits the way you think about and frame your work, and how...

When you’re choosing a technology to invest in, often that’s because it’s an unavoidable step on the path to something else. You’re not building a new service mesh for the joy of building a service mesh; you’re building it to make your microservices framework easier to use, because you want to make it easy for new services to get set up quickly, because you want teams to be able to ship features faster. The real goal is to reduce time to market. When you know the real goal, you can step back and evaluate whether any proposed work will get you closer to it.