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

by Tanya Reilly

As my colleague, Dan Na, says, a new person can always see the problems. They haven’t been around for the gradual change and the boiling frogs:

The product or service that your organization provides should work. Its customers should want to use it. Deploying it shouldn’t be painfully slow. Know your implicit goals as well as the explicit ones.

“A user doesn’t distinguish between DNS services, ISP, your CDN, or your endpoint, whatever that might be. At the end of the day, there are a bunch of websites that work, and a bunch that don’t.”

If you don’t understand your customer, you don’t have real perspective on what’s important.

Remember that your goal is to solve the problem, not necessarily to write code to solve it.

Take the time to understand what already exists—inside and outside your organization—before building something new.

Reorganizations can disrupt communication between groups that need to work closely together.

A new senior leader can cause an earthquake that reshapes the landscape overnight.

Being right about a need for change is less than half the battle.

You don’t find out about the difficult parts until you get there

Engineers sometimes dismiss organizational skills as “politics,” but these skills are part of good engineering:

If your organization has published a statement of values or principles, that can help you see what the leaders care most about. But these values are aspirational: the real values of the company are reflected in what actually happens every day.

Knowing the cultural expectations around sharing is crucial. In a culture that keeps knowledge locked down, you’ll lose your boss’s trust if you reshare something they told you in confidence.

In a more open company, you’ll be considered political or untrustworthy if you withhold information or don’t make sure everyone knows what’s going on.

Thankfully, most workplaces are somewhere in between. If yours prefers quick conversations, you may get pushback if you take the time to write a decision down—and

One team I worked in had a cowboy hat that would end up on the desk of whichever team member had last done something a little too “Wild West.” It was affectionate, but it was a good reminder too.

However, when those initiatives need broader support, they slow down. If teams disagree about direction or priority, the lack of a central “decider” can lead to deadlock.

How do people in different groups talk with each other? There may be formal paths for information and requests, but your social culture adds informal channels too. If people are friendly across teams, they’ll send a DM when they have a question and share ideas over coffee.3 If an engineer in one group can just go chat with a counterpart in another, it’s going to be easier to make decisions that cross both teams.

In some places, the only real way to get work done is to have an “in” via a back channel with someone on the team. If it’s more typical to file a ticket and wait, or to send a collaboration idea up your management chain until you and the other team have a manager in common, everything will take longer—but it will also be more predictable and fair.

How much time does everyone have? If teams are understaffed and overworked, you’ll have trouble finding a foothold for any new idea that isn’t on an existing product road map—the

the same group of people, in the same configuration, climb the ranks together and have a fairly fixed structure for communicating, making decisions, and allocating the “good projects.” Each person is like a node in a crystal lattice: so long as the people around you are moving up, you’ll move up too.

This sort of hierarchy is anathema to young, small, scrappy companies, which claim to be something like a meritocracy. Let’s be realistic about that: success still depends on having access to opportunities and sponsorship,

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.

Although some fortresses are petty tyrants, the majority are well-intentioned. They gatekeep because they care. They’re trying to keep the quality of the code or architecture high and keep everyone safe.

It’s very hard to draw team boundaries in a way that lets each team work autonomously. No matter how opinionated your APIs, contracts, or team charters, there will inevitably be some pieces of work that multiple teams think they own, and navigating those disputes can feel risky.

When two or more teams need to work closely together, their projects can fall into chaos if they don’t have the same clear view of where they’re trying to get to.

The lack of alignment can lead to power struggles and wasted effort as both sides try to “win” the technical direction.

Companies that have worked to make engineers efficient will often set up processes to ensure that the official ways to do something are also the easiest ways.

Try sketching your own map. Remember that cartography is inherently political: what you choose to include says something about you as well.

Organizations end up with weird shapes due to reorgs, acquisitions, individual personalities, and, in some cases, people who just don’t like each other.

It is fascinating to watch how information and opinions flow through a company and to see how unexpectedly they can become a plan of record. Suddenly everyone’s using a new acronym or holding a particular opinion, and it can be hard to see where that came from.

One team has approval to hire more people this year and another doesn’t. How did all of these decisions happen? Was there a memo?

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.

Figure out where decisions are happening. Perhaps there’s a weekly managers’ meeting that’s intended to make organizational decisions but that often weighs in on process or technical direction.

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 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.

If you’re decidedly on the individual contributor track, you usually shouldn’t be part of discussions about compensation, performance management, and other manager-track things.

You might bring information to your manager or director that affects those decisions, but it’s up to them to act.

The shadow org chart

In their book Debugging Teams: Better Productivity Through Collaboration, Brian W. Fitzpatrick and Ben Collins-Sussman describe the “shadow org chart”:

The authors identify “connectors” who know people all across the org, and “old-timers” who, regardless of rank or title, wield influence just from being around a long time. These

“There be dragons” and vow to steer elsewhere. But a staff engineer can often have the most impact by going where everyone else fears to tread and making the dangerous territory easier for everyone else.

I talked earlier in this chapter about how you need to look past your group’s local problems and keep perspective about the world around you. You need that same perspective across time.

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

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.

team that’s used to iterating on short, clearly specified goals won’t build muscle for bigger, more difficult projects and won’t be able to tell the story of why they did what they did.

If everyone knows where they’re going, life gets easier. There’s no need to keep tight alignment along the way. Each team can be more creative in figuring out their own route, with their own narrative for the problems they’ll need to solve to get there.

They’re less likely to go down wrong paths, and they’ll have enough information to make decisions, reducing the amount of hedging and technical debt they need to incur.

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.

It may take you time to dispel the fog of war and uncover the true destination of your journey. Once you do understand it, don’t keep it to yourself. That means telling the story to other people and letting them understand why it matters.