Is it really good to be a key player in a team?

[[138596]]

Do you have an engineer on your team that people always go to for questions? Maybe he's the senior engineer on the team, writing the majority of the codebase. Or maybe he's a technical lead or manager, involved in most design discussions and even the logic of many projects for historical reasons. Maybe he's the go-to person for specific systems, with years of experience running those projects.

We are often encouraged to become important engineers who answer people's questions, and I use this role as a value indicator for the team. Companies like Google even link this ability to the promotion process: junior engineers who become core engineers responsible for key projects are often more likely to be promoted after verification.

This incentive seems reasonable. The rarer an engineer's relevant skills and knowledge are, the more valuable he or she is to the team, based on supply and demand. So the goal of becoming the go-to person for many projects seems reasonable, right?

Unfortunately, this rarefied mindset only takes us further off track.

How you manage your time determines your impact

The problem with this mindset arises when you step into the critical path of too many projects, and you become the first person people turn to for proliferating problems. If a high-priority bug is filed, you may be the first person to notice it. If a product manager has a question about how a feature works, you may be the first person to answer it. If another engineer needs advice on a system, you may be the first person he or she can consult. In these situations, when you become the first or last line of defense, you lose flexibility in how you can use your time effectively. Your schedule becomes constrained by external factors, which limits the value and impact you can create.

This problem is not uncommon, and the more senior you are, the more serious it is. An early engineer at a Silicon Valley startup shared with me that his years of experience have earned him mastery of most of the company's web stack. Many people believe that his skills and experience will allow him to be responsible for the company's influential projects. However, he is often consulted by other teams, bombarded with various problems, and becomes a firefighter. He seems to love the company and the job, and he feels the risk of burnout. In the company, his experience has become a mantra, and he has become a limiting factor for many projects.

Another engineer, a technical lead at Google, sought advice on how to better help the junior members of her team who sent her code reviews. She understood that providing feedback sooner would have a greater impact — addressing bad design choices sooner meant her colleagues spent less time going down the wrong path. She also understood, based on her experience, that she was the best person to give valuable feedback. But at the same time, her role as code reviewer prevented her from investing time in other aspects of leading the team: confirming progress on her projects, checking that her colleagues had the right priorities, and moving any roadblocks out of their way. Her seniority made her a bottleneck.

Any time you become the core engineer who knows how a system works, or is responsible for a project, you incur a kind of indirect tax. [Note 1] Depending on your expertise or skills, you are in a position to help solve future problems. This responsibility is often an integral part of software development - every time you develop something new yourself, you become the core engineer who knows the project. Sometimes you may learn from it, or enjoy the experience so much, that you want to take on this responsibility. This is good.

But over time, if this knowledge stays in your head and isn't shared with the team, it will become a hindrance. If an exciting new project starts, will you be seen as an influential person? What if you want to try different things and learn new things? If all your time is spent responding to the growing number of bugs, customer requests, and other issues on various projects, you won't have much time left to focus on other impactful tasks. The value and impact you can create will begin to stagnate.

So, what can we do to avoid finding ourselves in this situation?

Take Yourself Off the Critical Path

The two engineers I spoke to could have done a better job of delegating certain responsibilities to team members. Ultimately, here’s the advice I gave.

The ability to choose what to do with your time is critical to increasing your long-term impact. To increase your flexibility, you can proactively take the following steps to reduce your role as a core engineer in terms of familiarity with the operational aspects of certain software. You are at the center of the interaction model, and everyone must make decisions through you. You need to reduce this aspect of the arrangement.

If your bottleneck is technical, automate as much as possible. For example, you could do this:

Develop an internal tool for your customer support team so they can solve common types of issues without having to bother you or other engineers on your team.

Write automated fixes for common operational problems so that you and others don't have to spend time solving them. For example, if you perform the same operations every week while maintaining a server, you will benefit from automating some of the mechanisms. Also, explicitly turning a process into a script that can be checked into the codebase gives you a closer look at who can improve and operate the system.

On the other hand, if the main reason you’re a bottleneck is because of the skill gap between you and the rest of the team, invest time in closing it. Share ownership with more people by following these strategies:

Learn to delegate and trust your colleagues. This can be a Catch-22—if you haven’t delegated work to specific colleagues before, you probably won’t trust them to get it done. If you don’t trust them to get it done, you won’t be able to delegate work to them. Start small and build trust.

Set a goal to teach other engineers the right mindset and principles to do it well themselves. Review code with this goal in mind.

Write good design docs and share them with others through technical talks. For my current startup, Quip, we write simple design docs for almost every new feature or revolutionary change. We document actionable tidbits about how to use various systems that have been built. This collection of knowledge makes it easier for anyone to take over a project or system they are not familiar with.

Avoid one-person teams. When working on a project with others, you want to make sure there is another person who can handle future issues to help share the pressure.

Mentor and train those around you. At Quora, for example, we invested significant engineering resources in building an onboarding program that allows new engineers to quickly master the basics of core engineering.

When engineers get into the middle of a massive project pipeline and the debt becomes a significant burden, sometimes they burn out. Or they decide the best way to win their time back is to switch teams or even companies.

Don't let this happen to you, take back your time.