Is there an engineer on your team who people always consult for certain classes of problems? Perhaps he’s a senior engineer on the team who wrote large swaths of the codebase. Or maybe she’s the tech lead or the manager who’s participated in most design discussions and knows the historical rationale for many projects. Or perhaps he’s the sole engineer responsible for particular systems and has years of experience operating them.

Oftentimes, we aspire to be the key engineer who people go to with questions and problems. We use the role as an indicator of the value we provide to the team. At companies like Google, parts of this mentality are even codified in the promotion process: junior engineers who demonstrate that they can be the sole engineer responsible for key project areas are often more likely to get promoted.

At first glance, this aspiration makes sense. By supply and demand, the scarcer an engineer’s relevant skills and knowledge, the more valuable he or she is to the team. So aiming to become the point person for a large number of projects seems sensible, right?

This scarcity mindset, unfortunately, can only take us so far.

Your Control Over Your Time Drives Your Impact

The problem with this mentality arises when you enter the critical path for too many projects, and you become the only person that people consult for a growing number of problems. If a high-priority bug gets filed, you might be the first to get notified. If a product manager has a question about how a feature works, you might be the only person able to answer. If another engineer needs advice on a particular system, you may be the only person he or she can consult. When you become the first or only line of defense in these situations, you lose flexibility in what you’re able to do with your time. Your schedule gets dictated by external factors, and that limits the value and impact you’re able to create.

This problem isn’t that uncommon, and it becomes more acute the more senior you are. One early engineer at a Silicon Valley startup shared with me how his years of experience had earned him intimate familiarity with most of the company’s web stack. Many assume that his knowledge and experience would’ve given him his choice of high-impact projects at the company. Instead, he was constantly being consulted by other teams and bombarded with requests to help fight urgent fires. So even though he loved the company and his job, he felt at risk of burning out. His experience at the company had become a curse, and he had become the limiting factor for many projects.

Another engineer, who’s a tech lead at Google, sought advice on how to best help the junior members of her team who were sending her code reviews. She knew that providing feedback early and quickly could be high-leverage — addressing poor design choices sooner meant that her teammates would waste less time going down the wrong path. Given her experience, she also knew that she was best-positioned to give valuable feedback. But at the same time, her role as the primary code reviewer prevented her from spending time on other aspects of leading the team: ensuring that her project was on schedule, checking that her teammates were working on the right priorities, and removing any roadblocks in their way. Her seniority had made her a bottleneck.

Any time you’re the sole engineer with knowledge about how a certain system operates or the sole engineer responsible for a project area, you incur a hidden tax. You’re on the line to help address future problems that depend on that expertise or knowledge. This responsibility is often a necessary part of software development — every time, you build something new on your own, you’ll start off being the sole engineer with knowledge about the project. And sometimes you may be learning from or enjoying the experience so much that you want the responsibility. And that’s great.

But over time, if the knowledge trapped inside your head doesn’t get shared with the team, it becomes a liability. What if an exciting new project opens up that you consider to be high-impact? What if you want to work on something different and learn something new? If all your time is spent responding to a growing number of bugs, customer requests, and other urgent issues across your various projects, you won’t have any time left over to focus on other high-leverage tasks. And the value and impact you can create will start to plateau.

So how do we prevent ourselves from getting stuck in situations like these?

Remove Yourself From the Critical Path

Both of the engineers I talked to would’ve been better off had they delegated some of their responsibilities to their teammates. And, ultimately, that’s what I advised them to do.

The ability to choose what to do with your time is critical to increasing your impact long-term. You can increase your flexibility by proactively taking steps to reduce situations where you’re the sole engineer with operational knowledge of some piece of software. Scale back on arrangements where you’re the center of a hub-and-spoke model of interaction, where everyone must go through you to make their decisions.

If the situations where you’re a bottleneck are technical, automate as much as possible. For example, you might:

• Build an internal tool for the customer support team, so that they can address the most common types of issues without any intervention from you or the rest of the engineering team.
• Write tools to automatically fix common operational issues, so that neither you nor anyone else needs to spend time addressing them. If, for instance, you spend time every week going through the same motions to maintain your servers, you’d likely benefit from automating some of the mechanics. Moreover, the explicit encoding of a process into a script that’s checked into the repository brings you one step closer toward having someone else who’s able to ramp up and operate the system.

If, on the other hand, the main reason you’re a bottleneck is a knowledge gap between you and the rest of the team, invest time in bridging that gap. Share ownership with more people using some of these strategies:

• Learn to delegate to and trust your teammates. This can be a catch-22 — if you haven’t delegated work to a particular teammate before, you may not trust them to get it done. And if you don’t trust them to get things done, you won’t delegate work to them. Start small, and build confidence.
• Review code with the goal of teaching other engineers the right mindset and principles to do things well on their own.
• Write up design documents and give tech talks to share knowledge. At my current startup Quip, we write short design docs for almost every new feature or substantive change, and we document operational tidbits on how to use the various systems we’ve set up. That collection of knowledge makes it easier for anyone to jump into projects and systems they’re not familiar with.
• Avoid one-person teams. By working with someone else on a project, you ensure that there’s one other person who can help share the burden of addressing future issues.
• Mentor and train those around you. At Quora, for example, we invested significant engineering resources to build an onboarding and mentoring program so that new engineers could quickly ramp up on core engineering building blocks.

When engineers get into the critical path of an overwhelming number of projects and the liabilities become too much of a burden, they sometimes get burnt out. Or they feel that the only way to win their time back is to change teams or even companies.

Don’t let that happen to you. Win back ownership of your time.

Your turn: What’s one situation where you’re a bottleneck today, and what’s one step you can take to start removing yourself from the critical path? Share your answer in the comments below.

Thanks to Chen Xiao for reading a draft of this post.