006. Become Less Necessary
Your team scales, but you don't.
Congratulations! You've hired an excellent group of engineers and onboarded them successfully. Work is well prioritized and everyone is staying productive. Features are underway... and yet... things don't seem to be going faster.
As your team scales up, you don’t. If you find yourself with a backlog of questions to answer and PRs to approve, the bottleneck might be you. Here’s how to get out of your own way and let your team succeed.
The PR Bottleneck
One of my favorite team leadership successes came from implementing a straightforward change. Before the change, only one or two leaders were reviewing and approving all pull requests for a team of ten developers. As you can imagine, PRs stacked up quickly. Despite the reassurance of automated tests, the constant overload of reviewing code lead to fatigue and a diminishing quality of reviews from team leaders.
After the change, all PRs were reviewed and approved by one or more team members. Leaders needed only to take a brief look before confidently hitting the merge button.
The result? Backlog cleared. Happier leaders. Increased collaboration, sense of team unity, and knowledge sharing overall. Happier, more confident, and more knowledgeable individual contributors.
The example highlights an important but counterintuitive principle for leaders: strive to make yourself less necessary. Here's why it works.
Trusting Your Team
It’s common for small software teams to rely on their leader or managers to review and approve PRs. It’s a practice propagated by both teammates and team leaders: individual contributors are wary of taking responsibility for a review that misses a bug or security issue, and team leaders don’t trust that developers will consider all the possible pitfalls of a less-than-careful approval.
Both these perspectives are fear-based and wrong.
Individual contributors are often far better at reviewing pull requests than their managers. They’re closer to the code and appreciate a level of detail that their leaders don’t see (without in-depth digging and the consequent time investment). It’s true that code is better reviewed by a fresh pair of eyes - which is why I recommended that all individual contributors only review PRs that are not their own.
When contributors review each other’s code, they also engage in conversations that advance the level of knowledge sharing and collaboration across the team. For the team in my example above, this increase in collaboration lead to a much greater sense of unity. Team members developed an appreciation of each others' talents or specific area of expertise - as a result, they knew who to go to for help in the future for any particular issue. With that in mind, not having contributors perform code reviews is a huge missed opportunity.
Leaders who feel reluctant to turn over the task of reviews and approvals to their team are similarly missing the bigger picture. It’s true that leaders often have more context and consider a wider scope for the effects that code changes can have; using this as a reason for not trusting your team is an error.
Instead, it’s up to you as a leader to share this context and these larger considerations with your team members at every opportunity. It’s not only relevant for code reviews, but while building the features that create the PR in the first place.
Share What You Know
Sharing information that you have as a leader can also empower the team to answer a lot of their own questions. There’s no good reason I can think of for leaders to withhold context such as a long-term roadmap, discussions surrounding feature prioritization, and customer feedback from the team. The latter in particular can be rewarding and motivating for contributors.
Rather than simply firefighting questions you receive from the team, observe them and ask yourself what information you could make available that would have helped them to find an answer for themselves. In a future chapter, I’ll give you a sustainable strategy for doing just that.
Take it to work today:
Don't be a bottleneck. Look for processes where you can remove yourself as a gatekeeper, such as by having individual contributors review and approve PRs.
Trust your team. Utilize their individual talents by empowering them with autonomy.
Don't become a gatekeeper for knowledge. Share context and the bigger picture with your team.