What would happen to your team if someone got hit by a bus? Would it drastically affect your deliverables?
If the answer is no and your team keeps performing, then congratulations! You have a resilient and high-performing team. However, in most situations, this is not the case.
This article explains the bus factor and how to avoid this common issue that slows down many teams.
What is the bus factor?
The bus factor measures the minimum number of team members who must be hit by a bus (leaving the company, going on holiday, sickness) to put the project in danger. The goal is to increase the bus factor to reduce the risk of the project falling. The minimum bus factor possible is one, representing a single failure point. This means the project is at risk if one team member is unexpectedly unavailable. So, the lower the number, the higher the risk. Ideally, the bus factor should be equal to the size of the team.
How do we identify the bus factor?
The bus factor manifests when one team member fuels every project. Usually, this person needs to be involved in every technical decision and is the only one with knowledge about the entire stack. So, when this engineer is not around, the team slows down and cannot deliver the expected value because they depend entirely on a single person. For example, the team don’t know how to apply a database migration because they have never done it before, and it’s always the same person doing it. So, if these issues sound familiar, it’s most likely that your team suffers from the bus factor.
Now we know what the bus factor is. Let’s understand the impact on the team and how to avoid it.
Symptoms caused by the bus factor
- It hinders the growth of other team members since one person predominantly makes the technical decisions.
- Single point of failure. If that person is not around or, even worse, leaves the team. The team stops delivering value.
- Your direct reports feel the pressure of being unable to perform at the same level due to a lack of knowledge.
- Having a bus factor can hurt your team when there are incidents. The engineer on-call should be able to investigate the incident without constantly escalating to the same people who have the context.
How to avoid the bus factor?
The following list of practices is a great recipe to avoid the bus factor:
- Pair programming - One of the most straightforward and productive ways to avoid the bus factor is to ensure your team is practising pair programming. Pairing your team members is a simple and practical way to share knowledge. When two engineers work together on the same task, it incentivises discussion, which usually brings better solutions and quality. It is also a great way to help onboard new joiners. They feel more confident and safe by having someone to discuss and guide them through the team’s best practices: deployment, testing, documentation, architecture, etc. and reduces the reliance on any single individual.
- Code reviews - Code reviewing must be part of every software development process. It ensures that team members review all shipped code to production. This practice is valuable for sharing knowledge, starting discussions, reducing potential bugs, and ensuring code quality.
- Sharing ownership - A simple strategy to avoid the bus factor is rotating people ownership across the projects. It may be convenient to pick the same person to deliver a feature when they are familiar with the codebase and are the ones who can ship faster. Although they can be faster, it is also a bottleneck in the team. Try to rotate people across projects to share their knowledge and challenge them even better if you can align their personal growth with the projects.
- Hiring - Avoiding the bus factor must start from the interview process by filtering candidates that don’t understand why it is essential to share knowledge. It is an excellent opportunity to identify and filter candidates who like to be the “hero”. Ask them how they share knowledge and if they understand the benefits of code reviewing, coaching, and pair programming.
- Documentation - One of the easiest ways to share knowledge is by writing documentation. People usually argue that it is not valuable because it’s hard to keep updated, especially in fast-growing startups. However, everyone agrees that it is precious when it exists. Writing documentation shouldn’t be tedious and lengthy. No one wants to read a novel to understand why that service uses that database. That is one of the main reasons every team should write Architectural Decision Records (ADRs). Not only all the decisions are written down, but it also invites people to contribute to the solution. Even if the most knowledgeable person writes down the ADR, everyone in the team is involved by asking questions and adding alternatives. So when someone asks why service A is using a NoSQL database, everyone knows the answer.
Now that you are familiar with the bus factor. Answer the following question: Is your team suffering from the bus factor? If the answer is yes, then I hope this blog can help you to fix the problem. The key is to create a culture of knowledge sharing and avoid creating silos in the team.