Sandglaz Blog

What every project manager should know about the bus factor

Agile Development Collaboration & Team Management

The bus factor is a common term in software development projects, but each and every project manager should be aware of it. It has applications well beyond software development: it applies to any project, and it might apply to yours too!

I once worked a retail job at a recently launched mobile carrier, where I was one of only three employees, aside from the manager. Between the three of us, we were actually able to manage all the work, and more people were already being trained for the job. But through a series of circumstances that were out of our control, all three of us needed to take time off during the same week, leaving the manager with only two trainees who simply did not have the knowledge to do the job. Although the manager had a relatively high bus factor (three), unanticipated events almost left her without staff. Luckily, other locations were able to bail us out.

The bus factor refers to the number of people on your team who need to be ‘run over by a bus’ before the project is in trouble. Of course, for the employee to ‘disappear’ you don’t need a morbid bus accident: she can suddenly change jobs, switch projects, move away, have a health emergency or simply retire before the project will be in jeopardy. One thing is sure: you don’t want your bus number to be one.

Yet when it comes to the ideal team size, we know that less is more. If you want a highly efficient and motivated team, you should really keep it between 5-9 people, which is also the number of people in an agile development team. In most cases, unless you are severely understaffed, you shouldn’t be going around hiring people just to increase your bus number. So how can you increase the bus factor without adding extra people on the team?

The key is making sure certain vital information is not monopolized by a handful of essential team members by creating a culture of open information and collaboration. Easier said than done!

When trying to increase the bus number, it’s important to look at the current processes in place, as well as at the work itself. For example, if one key employee would leave their job tomorrow, how would you get access to the work he’s currently doing? Are all the vital files stored on his personal computer? Where did he file those documents that are essential to the project? And then there’s the work itself: who on your team can tie the loose ends of the lost member’s contribution to the project?

Simplify your processes

Aim to make it almost impossible for one employee to hold all the information by simplifying your processes. This includes using technologies that are easily accessible and available to everyone, as well as technologies that anyone can easily learn. In the day and age of SaaS, where everything from customer relationship management to invoicing is done ‘in the cloud’, there’s no reason not to. You can start by filing and sharing your internal documents through Dropbox or Google Drive. Reviewing your office communication tools¬†and practices will also play a big role in simplifying your processes.

Start at the hiring level

You can increase your bus number from the moment you hire your team members. When interviewing, pay close attention to the candidate’s ability and willingness to learn new things. Highly resourceful, curious people who learn on the fly can quickly step in when one of their team members leaves the project. An innate sense of curiosity will guarantee that this employee will take interest in what her team members are working on. And a strong foundation in their field will help them figure things out on their own in critical moments.

Regular team updates

Meetings can often be a waste of time, but it’s not so with team updates. Try a weekly update meeting, or even better, a daily morning huddle where each team shares what has been accomplished and what are their top priorities for the next leg of the project. You should also encourage sharing possible roadblocks that team members can help solve after the meeting. This will definitely boost collaboration and the sharing of information.

Cross-training

It’s not only necessary that team members know what everyone is working on, but also that they know how¬†everyone is working. You can have a low bus factor if there is no skill redundancy on your team. You want your employees to be generalists to some degree. Cross-training in basic tasks will ensure that the tasks can be covered for when one employee goes under the bus. As much as possible, you want every member on the team to have at least one secondary skill that will allow them to cover for a team member.

Pair programming

Again, there’s something to learn about collaboration from this agile development technique. Pair programming is a technique where two programmers sit together at one workstation. The driver writes the code while the navigator reviews each line as it is typed in. The programmers switch roles frequently. There’s also another style of pair programming, called promiscuous pairing, where each programmer works with all the other programmers on the team instead of pairing with only one programmer.

Of course, this technique is not applicable to every position you might have in your team. Sometimes it’s not viable to have two people work together on a sub-team. But it teaches us something about a culture of learning and collaboration. Programmers get to see and examine their partner’s work and provide feedback. This is essential not only for sharing information, but also for the team members to develop their own learning mechanisms.

Flexibility

You can cheat the bus factor by allowing workers to work out of the office. If your employee is at home with a stubborn cold that you don’t want to spread around the office, chances are they are still able to do part of the job. If their child is sick, they can still perform some of their responsibilities while away. This doesn’t solve the problem of what would happen if a team member permanently left the team, or if they are not capable of fulfilling their duties remotely. But it is a good way to trick the bus number when your other options are limited.

The key thing about the bus factor is that with adequate management, it’s in your hands to increase it. The main takeaway is to encourage an environment of learning and collaboration that will spread information to all team members.

What’s your bus factor? We’d love it if you joined the discussion in the comment section below.

Sandglaz is the easiest way to collaborate with your team. Learn More


  • Cross-training is probably the most important thing for me on this list. Our bus factor is pretty low as everyone is specialised and there isn’t much budget for duplication of effort or additional team members. And this has happened to me on a project about 10 years ago: a really critical member of the development team found that the wood in his house was rotten and was in a dangerous state of repair. He had to move his whole family to temporary accommodation while the floors and ceilings were stripped out, made safe (or whatever it is that they had to do so the house didn’t collapse). We lost him from the team for a number of weeks and it set us back considerably.

    • Alina Vrabie

      Thanks for sharing that story with us, Elizabeth. Cross training is definitely an important aspect of increasing the bus number, especially when there’s no budget for/it’s not desirable to add new members to the team.
      What I find fascinating about your story is that you lost an essential team member for such a seemingly random and unpredictable reason!

      • Yes, that certainly wasn’t on my risk register!