The Bus Factor

Think of your #1 employee, the person you trust with the most critical and complex tasks. Imagine they come to you to inform you that they’ve decided to pursue their lifelong dream of becoming a bus driver.

Literature has a less cheerful interpretation of this phrase, but the idea is the same — the Bus Factor is a measurement for how dependent your organization is on a specific individual or group of individuals.

Let’s have a quick thought experiment. Bring that specific individual to mind — Are they holding critical information that “we never had the time to document”? Are they the only one who know why a certain product is built the way it is? Is there a part of your service where if things go bad (thankfully, they never have) you’ll need to call them on their vacation?

These are common in every organization, and it’s actually quite natural how you end up there — you have your senior engineer/architect who is both a very talented individual and has been around with the team long enough to build the product as it evolved. As they gather more experience and knowledge, you’ll naturally have them tackle more strategic, wider efforts, keeping them intrigued and challenged, as an effective tool to retain them. You’ll also want them to work uninterrupted, as fast as they can, to bring better results sooner.

While this seems the logical thing to do, it has a lot of risk for the health of your team:

• That person leaving at some point is inevitable, and it won’t always be anticipated either. Think of the technical and operational gap they would leave behind. Will your team be in a state where it can easily recover?
• Your dependency on that person may become unhealthy as well, “upping” the incentives for them to stay, making the gap even bigger — e.g. having them own larger, more complex projects to keep their contentment high.
• You’re also likely to be missing on opportunities for other team members to take part in complex efforts, growing as stronger engineers themselves.

So, what can you do?

1. First, identify where your Bus Factor is too low — who on your team is “indispensable”? A good rule-of-thumb is that every workload should be owned by a team, not by a person. Start with those who are not working within a traditional team (e.g. group architects). Then, go through members of the organic teams as well.
2. Document and share knowledge. Much of the work will still be done by individuals, but that doesn’t mean others should not be accessible to their knowledgebase, methods and thinking process (e.g. through design reviews). A shared understanding across the org is critical, and also a good foundation for onboarding new team members.
3. Actively involve more team members in areas where you’re vulnerable. Those tasks may take longer to complete, but that’s exactly why it’s so important to have more people be proficient in all critical areas of your product.

I’ve had some good experience implementing these principles on my team. We used to have group architects leading efforts end-to-end, when we realized it’s not a sustainable model and changed it. We also used this as an opportunity to develop the architects themselves — having them focus on traits which are no less important than their technical excellence — collaboration and mentorship. That organization recently went through a significant change, losing some of its key people, and it was able to recover quickly and strongly much because of how we structured it to.