Team management tips: What's the bus factor and 7 ways to increase it

The “Bus factor”, also known as the truck/lorry factor is an important number to keep track of.

In this article, I’ll explain what the bus factor is all about, why you should care (whether you’re a team leader/manager or not) and most importantly, how to increase it.

What is the Bus factor?

Simply put, the bus factor corresponds to the number of people in your team that can get hit by a bus before your project, product, system, whatever is in grave danger, stuck, blocked or doomed.

The lower the number, the higher the risks.

The problem with Rockstars

As a project manager, team leader or manager, you always need to keep an eye on risks. Risks come in all shapes and forms; some obvious and highly visible, others less tangible and harder to evaluate. The risks induced by a low bus factor are sometimes part of the second category.

So you’ve got a rockstar in your team, a Mr know it all, one with all the answers. Congratulations. You’re lucky. Hiring and retaining talented people is incredibly hard these days.

Rockstars are nice to have on a team, since they tend to:

• be passionate
• work efficiently without supervision
• produce high quality results
• raise the bar for everyone
• tackle the hardest problems
• …

But, as the saying goes, “What if he/she got hit by a bus?”. “What if” scenarios are awesome when writing fiction, but are also super important from a risk management perspective.

So, what if your rockstar gets hit by a bus? Would it jeopardize your project? Why?

Getting hit by a bus is quite rare (s*** happens though), but in fact there are tons of events that could create the same kind of trouble for your team.

The most obvious issue with rockstars is that they’re in demand and they know it. They get called by recruiters on a daily basis. If they get a much better proposal from a different team or company, then maybe they’ll decide to leave. They might also get bored and decide to take on a new role, join another team, another employer, etc.

There are things you can do to retain the rockstars, such as showing gratitude/appreciation/praise for their work, giving them good enough compensation, making sure that they can learn and grow, etc.

But life happens too; even if they’re fulfilled, happy and enjoy the project, the team etc, they might still get sick or might want to take a sabbatical, a parental leave, etc. Even if you did all you could, events completely out of your control will eventually happen.

Truth be told, rockstars are actually not the problem. The problem is that many teams rely too much on their rockstars and forget about the impact of losing them. Once it happens, it’s often too late to start preparing.

If you’re in charge, you need to do everything in your power limit the impact of losing your rockstar (and it will probably happen at some point).

To know if you’re at risk, observe what happens when your rockstar is out of office. If everything slows down, then you’re probably in trouble. It’s not good when rockstars are at the center of everything all of the time. If they’re the only ones tackling the hard tasks and always the ones that are called for help.

Over the next sections, I’ll explore some options for limiting the risks and to increase your bus factor, whether you have rockstars with you or not.

Redundancy

Having a Single Point of Failure (SPOF) in a system is a critical risk for the availability. For instance, if you have a single power supply or raid controller and it dies, then your system is down. The same is true for file servers, Active Directory domain controllers, databases servers and any system that should be highly available, really (IT or not). To fix that, the solution is to introduce redundancy.

This is also true for teams. Note that you might want to clone your rockstars, but that isn’t an option yet (afaik :p).

To make sure that your team continues to function if a key member is unavailable, you need to ensure that that person has at least one backup.

The “backups” should be able to take over any critical role/function/task of the unavailable team member at any time.

For that to be possible, you first need to have a clear view of the roles/functions/processes that need to be available or taken care of. Then, you need to identify the key members / responsibles for each and to design official backups. It’s important for team members to know that they’re the backup for X or Y; that way, they become accountable and can take action to ensure that they have the skills/information they need to assume their backup role.

It might also be useful to create virtual teams rather than talking about “backups”. Shared ownership is usually better. Some people become too obtuse when they think of themselves as the “chiefs/masters” of something instead of co-owners, regardless of their skill/knowledge level on the subject. I’ve seen bad situations emerge just because ownership wasn’t shared. “Virtual” teams have the advantage of promoting shared ownership, team cohesion and fostering creativity.

There shouldn’t be any one-man islands in a team.

In addition, for this to work, you need to ensure that time/budget is available for team members to train each other, to train themselves and learn what they need to learn.

For processes, it’s interesting to put rotations in place, so that it’s not always the same person taking care of the same tasks. Repetition is good for productivity, but rotation is great for knowledge sharing. Moreover, having different persons perform the same tasks will increase the quality of the procedures/documentation as the quirks will be highlighted more quickly.

Redundancy is not only useful in case of emergency, but is also great for creativity.

There are many practices that can improve knowledge sharing among team members. I’ll explore a few in the next sections.

Fresh documentation is key

I’m playing captain obvious here, but having documentation is key to survive “losing” a team member.

Key processes should be well documented so that even someone with limited knowledge of the subject could execute it. Of course without proper training it would be hard / slow, but at least you’ll know what has to be done and how.

Documentation goes much further than processes. Solutions at large need to be documented in some form or another. Whether we’re talking about software architecture, software design, coding conventions, disaster recovery procedures, etc.

Documentation needs to be a priority and part of the definition of done. You just can’t accept a situation where important information only exists in the head of some team member.

It can take many forms: text in a wiki (good), Word documents on a shared file system (yuck), schemas, videos, BDD specifications, etc. Use whatever makes sense, but ensure that it can easily be found from a single source of truth.

You need to be careful about documentation though. Having documentation is essential, but having out of date documentation is downright dangerous. Freshness does matter. A lot.

But there’s more.

Automate all the things

Documentation is super important, but automation is even more valuable. If you have the opportunity, then you should try to automate your key processes.

That way, you won’t rely on people to perform the tasks. Of course, the automated processes need to be well documented too, so that someone can adapt those if required.

For instance, if you’re developing an application, then it’s really beneficial to have a fully automated CI/CD pipeline. That way, making a change and bringing it in production is a non-issue.

Automation is a broad subject and there are many things to say about it. It should be done at so many levels that I don’t even know where to start. Let’s keep this subject for another day ;-)

Pair / Group work

In software development groups, “pair programming” is a really great way to share knowledge. It is indeed also applicable to many other domains than IT and software development.

You might think that having 2-n persons in front of a single computer working on the same thing is a waste of time, but that’s just not true. When working with another person on a problem/task, you end up with higher quality results, more creative solutions and shared understanding + shared knowledge.

If you want knowledge to better circulate in your team, then do push pair programming / pair work. Don’t discourage it, it would be a dire mistake.

This form of knowledge sharing helps reducing knowledge silos. And if you want to increase your bus factor, then knowledge silos should disappear.

If your rockstar works on a complex problem, then ask him/her to work with 1–2 colleagues. If research needs to be done, same thing, make it a group exercise. Everyone benefits from this. It does cost, but it’s well worth it for many reasons.

Knowledge transfer sessions

In the same veins, do promote knowledge transfer/sharing sessions. Encourage team members to share their ideas, designs, discoveries, problems, etc.

This increases team spirit, again fosters creativity, improves knowledge dispersion and improves the bus factor since more people will be aware of what others are doing/have done.

Simplify

Simplicity is a great weapon against the bus factor (and many problems in our world actually). If your processes/systems/whatever are simpler, then it reduces the risks of having only 1–2 persons being able to take care of those.

Whenever you have the choice between a simple/understandable design and a more complex/powerful one, do weigh in the impact of the choice on your bus factor.

Sometimes, less is more.

Invest in your team

One last idea worth mentioning is to invest in your team. And by that I mean your whole team, not only the rockstars.

Organize trainings, workshops, send them to relevant conferences. Turn your more experienced members into mentors and have them share their knowledge on a daily basis.

There are many ways to rise the overall skill level of your team; a few of which have to do with the management/leadership style.

Your best bet to increase the bus factor is to make everybody on the team a rockstar. And that’s not so far fetched ;-)

Conclusion

In this article, I’ve explained what the bus factor is, why you should care about it and how to make your team more resilient.

It’s a really risky game to bet everything on 1–2 key persons and you’ll probably be better off investing in your team, simplifying things, documenting/automating your key processes and promoting a knowledge sharing culture. Also check out my other advice about team organization; most are also relevant to rise the bus factor :)

There are many aspects, problems and solutions, but these are the first that come to mind.

That's it for today! ✨

About Sébastien

Hello everyone! I'm Sébastien Dubois. I'm an author, founder, and CTO. I write books and articles about software development & IT, personal knowledge management, personal organization, and productivity. I also craft lovely digital products 🚀

If you've enjoyed this article and want to read more like this, then become a subscriber, check out my Obsidian Starter Kit, the PKM Library and my collection of books about software development 🔥.

You can follow me on Twitter 🐦

If you want to discuss, then don't hesitate to join the Personal Knowledge Management community or the Software Crafters community.