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

by Tanya Reilly

When I was new to the industry, I used to wonder why my senior colleagues seemed so wary of committing to things. I would demonstrate that something was a problem and, inexplicably, my boss and the senior engineers around me would not drop everything and go solve that problem. Why didn’t they care?

You have to make peace with walking past things that are broken or suboptimal (or just really annoying) and taking no action.

Your time is the most obvious finite resource: there are exactly 168 hours in every week,

I’m inclined to be optimistic about my time. Too optimistic. There’s always important, interesting work available—and my default is to say, “I’ll do that. I’ll fit it in somehow.”

It’s an odd default that work calendars tend to only show meetings. If you’re trying to do focused work, your planned schedule only shows the interruptions to that work, not the work itself. Executive coach Fabianna Tassini of Confidantist gave me the best advice for managing my workload: put nonmeetings in the calendar too.

Leadership work can be unpredictable. A crisis, outage, or launch can cause a load spike. If a project needs more help than you predicted, you might find yourself oversubscribed.

Once the smartbrain is gone, it’s a struggle to do anything useful.

I’m absolutely wiped by one-on-one meetings, but I have friends who thrive on them.

But if you move entirely away from low-level technical problems, other engineers might distrust your technical judgment because they think of you as too disconnected. In some cases they might be right!

When I asked on Twitter what causes a loss of credibility, one of the big themes was absolutism: if you’re a fan of some technology and advocate for it in every single situation, people will stop believing you know what you’re talking about.

You will build credibility as a professional every time you take on a chaotic situation and make it easier for everyone else to understand.

You’ll lose credibility when you’re seen as contributing to the chaos, or when a project goes badly and you don’t do a good job of navigating the failure.

The skills resource behaves a little differently from the others, because it’s always slowly decreasing. That doesn’t mean you’re forgetting what you know (though you will lose fluency with technologies or techniques that you don’t use for a long time); it means that any technical skill set slowly becomes less relevant and eventually gets out of date.

The second way is by working closely with someone who is really skilled. Being the least skilled person on a team of superstars will teach you more than being the best person on an otherwise mediocre team.

sometimes being the most senior person around means that you should shield your less experienced colleagues and take on the grungiest work.

Do any of the people you’ll work with leave you exhausted every time you talk to them?

“It feels rewarding and can solve a short-term problem, but if you never eat anything of substance you’ll suffer.”

every project needs core technical skills, project management, product management, and people management.

Will this work align with your values and make you feel fulfilled, or do you feel a bit “off” about it?

In general, work that matters to the people in your reporting chain is work that builds social capital.

Your project can build—or lose—social capital with your peers depending on how it aligns with their values.

After viewing a potential project through the lens of each of those questions, you’ve probably got a good feeling for whether you should take it on. Maybe you shouldn’t! It’s possible for a project to be important but not actually right for you.

He says that there’s guaranteed to be work that shows up on your plate on which you can “get an A” every single time, and if you give it to someone else, they’re probably going to get a B. But, he argues, a B is a pretty great outcome for their first time doing this kind of work:

You’ve been at a company for a few years and you’ve done a lot of work to modernize architecture and processes. As a result, you’re now the point of contact for a lot of things.

By the time you reach the staff+ level, you will be largely (but probably not entirely) responsible for choosing your own work. This includes deciding on the extent and duration of your involvement with any given project.

But, usually, the reason a project is difficult isn’t that you’re pushing the boundaries of technology, it’s that you’re dealing with ambiguity: unclear direction; messy, complicated humans; or legacy systems whose behavior you can’t predict.

But, as the lead, you’re responsible for the result. That means you’re thinking about the whole problem, including the parts of it that lie in the fissures between the teams and the parts that aren’t really anyone’s job.2

When a project is too big for any one person to track all of the details, narrative is vital.

first to relationships, talk to people. If you’re a reader, go get the documents. Probably your

Describe how you’ll measure your success. If you’re creating a new feature, maybe there’s already a proposed way to measure success, like a

Success metrics aren’t always obvious. Software projects sometimes implicitly measure progress by how much of the code is written, but the existence of code tells you nothing about whether any problem has actually been solved.

If you initiated the project, be even more disciplined about defining success metrics. If your credibility and social capital are strong, you can sometimes convince other people to get behind a project based on their belief in you or by means of a compelling document or an inspirational speech.

Don’t rely on them as the only motivator to keep the project going.

There’s a big difference between “ship a feature” and “ship a feature without enough engineers and with two stakeholders who disagree on the direction.”

Describe the reality of the situation you’re in, so you won’t spend all your time being mad at reality for not being as you wish it to be.5

The reality is that some things will go wrong, and the more ambitious the project, the riskier it will be.

One of the most common risks is the fear of wasted effort, of creating something that ends up never getting used. If you make frequent iterative changes, you have a better chance of getting user feedback and course-correcting (or even canceling the project early; we’ll look at that more in Chapter 6) than if you have a single win-or-lose release at the end.

When teams have already tried and failed to solve a problem, there might be leftover components you’ll be expected to use or build on, or existing users with odd use cases who will want you to keep supporting them. You might also face resentment and irritation from the people who tried and failed, and you’ll need to proceed very carefully if you want to engage their enthusiasm again.

Don’t waste your time in power struggles. You’ll be more likely to achieve your shared goals if you work well together, and of course work is a much more pleasant endeavor (higher quality of life, higher energy!) when you’re harmonious with the people around you.

mentioned the risk of conflict when there are multiple leaders, so let’s start there. At senior levels, engineering roles start to blur into each other: the difference between, say, a very senior engineer, an engineering manager, and a technical program manager might not be immediately clear.

The program manager sees the gaps, communicates about the project status, and removes blockers, but everyone else should step up and do those things if they aren’t happening.

The beginning of a project is the best time to lay out each leader’s responsibilities. Rather than waiting until two people discover they’re doing the same job, or work is slipping through the cracks because nobody thinks it’s theirs, you can describe what kinds of things will need to be done and who will do them. The simplest approach is to create a table of leadership responsibilities and lay out who should take on each one.

“Here’s what I think I’m responsible for. Do you agree? Am I taking the right amount of ownership?”

Last thought on roles: if you’re the project lead, you are ultimately responsible for the project. That means you’re implicitly filling any roles that don’t already have someone in them, or at least making sure the work gets done. If your teammates have no manager, you’re going to be helping them grow. If there’s nobody tracking user requirements, that’s you. If nobody is project managing, that’s you as well.

Recruiting decisions are some of the most important you will make. The people you bring onto the project will make a huge difference in whether you meet your deadlines, complete visible tasks, and achieve your goals. Their success is your success, and their failure is very much your failure.

Whichever you prefer, make the increments small enough that there’s always a milestone in sight: it’s motivational to have a goal that feels reachable.

I’ve also found again and again that people don’t act with a sense of urgency until there’s a deadline that they can’t avoid thinking about. Regular deliverables will discourage people from leaving everything until the end. Set clear expectations about what you expect to happen when.

If your company is using product management or roadmapping software, it will probably have functionality to organize your project into phases, workstreams, or milestones. If everyone who needs to participate is in one physical place, you can do the same thing with sticky notes on a whiteboard. What matters is that you all get the same clear picture of what you’ve decided you’re doing and when.

have met almost nobody who is good at time estimation. This may be the nature of software engineering: every project is different, and the only way we can tell how long a project will take is if we’ve done exactly the same thing before.

“Driving doesn’t mean you put your foot on the gas and you just go straight.” Driving, in other words, can’t be passive: it’s an active, deliberate, mindful role. It means choosing your route, making decisions, and reacting to hazards on the road ahead. If you’re the project lead, you’re in the driver’s seat.