Matt Peperell's Blog

How to avoid a low bus number

And why this isn't the same as maximising it

Written: 16 Dec 2021 (Index by date)

Tags: work  (Index by tag)

This post is nothing to do with public transportation. Instead I refer to the concept called the Bus Number, which is a way to quantify organisation risk. It refers to the minimum number of people in an organisation that need to be hit by a bus for there to be lost knowledge.

A less jarring version of this term is the lottery factor; referring to people who would leave the organisation were they to win the lottery. (The risk would also apply when people take holidays or go on parental leave).

In a perfect world, all knowledge would be captured in written form such that it wouldn’t be lost in the event of people moving on but reality doesn’t work that way. I remember once place I worked which had a large ish team but also had a large variety of duties. In the early stages that worked okay, but as the team and variety increased it didn’t scale. Our bus number was seldom 1, except perhaps during the initial stages of taking on that duty. As a result we became adept at distributing this knowledge. We soon realised that trying to share knowledge of all tasks to all mwmbers wouldn’t work. Instead, I proposed that we would have each member of the team be the subject matter expert for a different component. They would not only be in charge of discovering and documenting the relevant intricacies, but also ensuring that their particular knowledge area does not have a bus factor of 1. So they’d also run training sessions to share the relevant information.

The team was made up of 3 senior engineers (me being one) but was junior heavy. By distributing the workload, this not only freed me up for managerial duties, but also empowered and engaged other team members. What better way than to be told “I trust you to make this happen”‽

A second technique, relevant to the documentation side of things1, was that we’d have one person write it, but then asked that the documentation be validated by having a newcomer attempt to use it. The SME would answer questions, but take a passive role such that the documentation – and not the SME – would be the guide. The newcomer can then amend documentation filling in gaps and ambiguities. Having the ability (and permission!) to amend procedural documentation was key here. 2

All in all at the time of my departure we had in the order of 20 topic areas spread across 10 SMEs, though basic knowledge of the majority of tasks was able to percolate to most of the team. But 100% across 100% would be an impossible and demotivating goal. Don’t set yourself or your team up for failure. Success is possible but don’t equate this with perfection.

  1. I have a post in the back of my mind on the topic of documentation too. 

  2. Hm. Maybe this would be a good addition for my Questions to ask a company list 

RSS RSS feed