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

by Tanya Reilly

I’ve sometimes heard engineers describe other people as “not technical enough,” and it’s a framing I always push back on. Apart from being a little dismissive, it claims to describe who someone is instead of the skills they have.1 It leaves no actionable path to becoming “technical enough.”

Being competent and knowledgeable doesn’t mean you have to know the most about every topic.

While you might not recognize the specifics of the problems in this new domain, your general experience should help you recognize their shapes.

When you move into a new technology area or business domain, be deliberate about learning quickly. Learn the technology in whatever way is most effective for you.

Notice if your role is preventing you from continuing to learn. In particular, be wary of drifting so far from the technology that you’re only learning how your company operates. While you should also learn enough about the business to make good choices, keep yourself anchored in the tech.

Be open about what you’re learning, and show how you’re doing it. When you’re making a statement that involves obscure knowledge or a logical leap, fill in the gaps for the folks around you: tell them why you came to the conclusion you did, what information you used, and how you came by that information. Be clear that you’re learning so it’s safe for them to learn too.

Competence is built on knowledge and experience, but you also need to be able to apply those abilities. That starts with having the self-awareness to know what you can do, how long it will take, and what you don’t know. It means being able to say “I’ve got this” and knowing that you do, in fact, have this.

Being competent doesn’t mean you need to be the best. I’ve sometimes seen tech people be shy about claiming to be an expert, because they can always think of someone in the industry who is better than they are. Don’t set your bar at “best in the industry.” It won’t help anyone if you hold back out of modesty. When the skill is needed, don’t wait for someone else to say, “Hey, aren’t you great at regular expressions”? Volunteer that you are—it’s not a brag, just a statement of fact.

Every time you admit you don’t know everything and let people see you learning, you show your junior engineers that it’s normal to continuously learn.

I love asking for an “ELI5,” a term that comes from Reddit and means “Explain it like I’m five years old.” It’s a helpful shortcut to mean “Look, rather than guessing my level of understanding, just spell it out for me. I promise not to be offended if you tell me things I already know.”

It’s much harder to explain something simply! It requires more understanding of the topic and more self-awareness about your own context. But it’s a real indicator of expertise. If you can explain a topic in plain language, so that nonexperts can hook it onto something they already understand, you really understand it.

sometimes the right move is to slap a solution together with duct tape as quickly as possible. But make that determination based on the problem you’re trying to solve, not how interesting the work is to you.

reputation for reliability is like the credibility and social capital we talked about in Chapter 4: it builds up as people see you do the work and get things under control. Be the sort of person who is trusted to get it done well.

As a leader, you have a responsibility to make the implicit explicit. It’s not fair, but if a junior person asks these questions, the team may sigh and say, yes, obviously we thought of that.

A few years ago I wrote a conference talk that went a bit viral. OK, we’re not talking otters holding hands viral, but it swept across tech Twitter,

and ask everyone to radiate intent about what they’re doing and when.

Where did their mental models diverge from reality?

It’s harder to be consistent when you’re stressed out or working beyond your capacity, so being consistent means taking care of yourself.

But if you just resent change, you’ll spend your time being unhappy. Expect it, and you’ll embrace it as a new challenge instead.

Consider your impact to be what wouldn’t have happened without you, not just what you personally did.

the metric for success is whether other people want to work with you.

It’s a common joke in tech women circles that you know you’re acting at senior level when you get your first peer review saying you’re “abrasive.”4

Teachers have a specific goal, often formalized in a lesson plan. If you’re teaching, you should too. Some examples:

Successful teaching includes hands-on learning and activating knowledge:

John Turner, a software engineer who has written about code review for the Squarespace engineering blog, recommends reviewing code in several passes:

Whereas mentoring involves sharing your personal experiences, coaching teaches people to solve problems for themselves.

marking technologies as “Adopt,” “Trial,” “Access,” and “Hold.”

Software consultant Glen Mailer says he looks for ways to make it as easy as possible for people to remember to do the right thing.

frames handing off work as “giving away your Legos”: There’s a lot of natural anxiety and insecurity that the new person won’t build your Lego tower in the right way, or that they’ll get to take all the fun or important Legos, or that if they take over the part of the Lego tower you were building, then there won’t be any Legos left for you.

Rosalind Chow, associate professor of organizational behavior and theory at Carnegie Mellon University, has described what she calls “the ABCDs of sponsorship”:

“We talk about the meritocracy of Silicon Valley, when really it’s a mirrortocracy, as people tend to hire people who look like themselves at greater rates than other sectors.” Pay attention to who you’re recommending or helping, and make sure you’re not accidentally only sponsoring people who look like you. It’s surprisingly easy to do.

For someone to be promoted to your level, they don’t need to be as good as you are now: they need to be as good as you were when you were first promoted to the level. If you keep seeing people join your level who aren’t as capable as you are, don’t snark about lowered standards: think about whether that means you’ve grown.

CTO Yvette Pasqua has spoken about how to build a network in a sustainable way, without burning all of your introvert energy.

Vanessa Van Edwards’s Science of People website for learning some of this “humaning” magic that other people seem to have been born knowing how to do. Check out her article “How to Network”, for example, for tips on talking to people at events like where to stand, how to remember people’s names, and what to talk about. All of this stuff is learnable.3

It’s easy to get typecast.

If you’re not sure what you need, find someone who’s doing the role or living the lifestyle you want, and ask them what key experiences brought them to where they are today.

Mason Jones, who has been an engineering leader at over 10 startups since starting with Travelocity in 1995, agrees: “Consistently and mindfully taking positions where I could expand my knowledge and broaden my experience has been the single most valuable thing I’ve done throughout my career.”

As Huston says, “Sometimes five years of experience is just…the same year of experience, five times over.”