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

by Tanya Reilly

How many unpredictable failures like that lurk in your systems? Assume it’s a lot. The network will fail, the hardware will fail, the people will have an off day. There will always be bugs. Odd interactions between parts of the system you haven’t even thought about will cause problems.

Make your systems observable: easy to inspect, analyze, and debug. And keep them simple, which I’ll talk about next.

Someday your system will be turned off. How hard is that going to be for the people working on it then? Will they have to dig deep into the logic of other systems, unwinding tendrils that touch business logic and tracing through code to understand what data they’re accessing? Or will there be a clean interface and a simple cutover?

The degree to which other people want to work with you is a direct indication of how successful you’ll be in your career as an engineer. Be the engineer that everyone wants to work with.

“Free advice,” the maxim goes, “is worth exactly what you paid for it.” And it’s true that advice is noisy: there’s bad signal mixed in with good, and it tends to not be tailored to the person who’s receiving

Be careful of unsolicited advice in mentor/mentee conversations. When someone starts describing a difficult project, for example, the easy, intuitive response is to say what you, the sage advice-giver, would do in the same situation. It’s kinder (if more difficult) to figure out what they actually need.

If you’re getting into a mentoring relationship, set it up for success. Set expectations, such as that you’ll meet once a week for six weeks. Agree on what you’re trying to achieve: does the mentee want to onboard and feel comfortable in a new company, learn a new codebase, or get career advice to strive toward a new role?

When someone asks you to review a document or pull request or conference talk, do call out the sections that you think are great, but pay them the respect of being (kindly!) honest about their work.

But also remember that the feedback will be read by the person’s manager and potentially others who are calibrating their performance or evaluating them for promotion.

So watch out for implicit bias and be aware of how you’re describing the same behavior across different people. Was it “consensus building” or “indecisiveness”? Were they “refreshingly down to earth or “unprofessional”?

A review from a senior person can be a real confidence booster. Be careful, though: a review done wrong can destroy someone’s confidence rather than boosting it. It can be soul-destroying to work through a barrage of comments that are condescending, seem arbitrary, or that you don’t understand.

A review comment like “Don’t use shared_ptr, use unique_ptr” only tells the code author what to do right now.

If a section of a design is confusing, don’t just say “please make this more clear.”

first high-level comments, then in increasing detail. As he points out: “If the code doesn’t do what it’s supposed to, then it doesn’t matter if the indentation is correct or not.” This advice works for RFCs too: if your first comment is that the author is solving the wrong problem, it’s not helpful to leave a hundred technical suggestions.

Every week when I met with my team lead, he’d ask questions about the project: “Just out of interest, how were you planning to balance these two conflicting business priorities?” Of course, I didn’t have a plan: I hadn’t noticed the problem creeping up.

Opinions about processes vary. Some people will be delighted to have clear steps and the safety that comes from standardization. Others will insist that people should think instead of mindlessly following protocols and that checklists and approvals just slow them down. Nobody’s wrong; it’s a trade-off. But the bigger the company, the more likely you’ll need some sort of structure that helps people do the right thing without having to ask the same questions every time.

Most tech companies now have code review and write tests. But that wasn’t always the case! All of the guardrails that we take for granted today were introduced by people who cared enough to argue for why the change was worth the time. If you’re introducing a culture change, be patient. It takes a lot of time and dedicated effort to make everyone behave in a different way, but it’s the only way you’ll ever be able to stop pushing the process along manually.

The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management. And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum.

Majors emphasizes that management should never be seen as a promotion—it’s a change of profession with a different set of skills to learn.

Since staff+ roles still mean wildly different things in different places, have an explicit conversation with future employers about what it means to them and what your job would be. As staff engineer Amy Unger writes, “It’s likely that each company and even each manager you talk to will have assumptions about what combination of skills they’re hiring for and an inability to articulate them.” Ask a lot of questions.

Not all newly hired senior leaders are entirely committed to or feel comfortable turning themselves into the leader the organization truly needs, rather than the leader they’ve grown to be over the past years. Many leaders take the opposite approach of trying to mold the organization in their image or the image of the past workplace. Engineering leaders brought into embattled organizations tasked with stabilizing the chaos are often heavily incentivized to do this.