--- title: "A Critical Chain of Bus Factors" url: "https://www.5whys.com/articles/a-critical-chain-of-bus-factors.md" canonical: "https://www.5whys.com/articles/a-critical-chain-of-bus-factors.html" published: "2017-02-21T22:02:03.767000+00:00" updated: "2017-02-22T07:22:57.363000+00:00" tags: [] author: "Roy Osherove" description: "How chains of bus factors form when single experts depend on other single experts, and steps like pairing and shared access that keep work from stalling." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Critical Chain of Bus Factors I've [spoken before about the meaning of a bus factor](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html). It's basically the idea that if there is only one person in your team that can do a critical part of the work, and that person gets hit by a bus, the team stops functioning. (I've been asked to call this the "Lottery" factor... which is a nice twist on it). It's not just developers who are susceptible to this. In any team, IT teams in particular, this seems to happen very commonly. In larger organizations, you might even have an infrastructure group and an "IT" group, and they both have different areas of responsibility, and in each group, there's only one person who can do some critical task.  **A chain of bus factors** happens when you have bus factors depending on bus factors: Your one developer who knows how to configure the pipeline can't test the changes because the agent is down. The one guy in IT who has access to the agent needs to reboot it, but does not have access. The one person who has access to reboot it (in the Infra team) is sick, so now there are three people waiting, and there is nothing in this earth that can help that situation.  **Here is another example of a critical bus factor chain:** - Developer can't check in the one feature only they can code so the application is released, - because the source control is down, and the source control person can't fix it, - because the private cloud node is down, and the one person who can fix it, can't,  - because the certificate is expired, and the one person who can fix it, can't, - because the person who acquires certificates is away etc... **Steps to avoid this hell on earth may include:** - Giving more access to other groups for the same resource - Sharing knowledge and responsibility with other people - pairing while working on critical things so knowledge sharing is guaranteed - Create a company policy of (2 bus factors or more) required. Look around you at work right now, and realize how many bus factors you see, and are a part of. Each one slows down the system more and more. Each one causes the system to be more and more fragile.  When you are a bus factor you might think: > "I need to work only on this one thing, otherwise I'll have too much to do, and so will everyone else on my team". **But realize that you are also creating more work for yourself this way:** Whenever someone needs work done on this topic, **you** will be the one person they turn to. **You** will be the pain point for every project that needs this type of worl from now on. Sharing the burden also means alleviating the load, and letting more people finish their work without needing you. Yes, there is a balance to be had, but remember that balance means not only "I won't give admin rights to the whole world" but it also means "I won't be the only one with the ability to do something". How much time, money, pain and sufferingin the workplace is caused by people just waiting for people who are waiting for people who are waiting for people? The answer will shock you! (OK, bad ending, but hey, great punch lines are not my job...) ## Read next - [Two Techniques to Avoid the Bus Factor In your Teams: Push and Pull](https://www.5whys.com/articles/two-techniques-to-avoid-the-bus-factor-in-your-teams-push-an.html): How push based and pull based learning help a team remove bus factors, told through an architect who fixed a search server without learning anything. - [Team Bus Factors: How to Reduce Them and How to Prevent Them](https://www.5whys.com/articles/team-bus-factors-how-to-reduce-them-and-how-to-prevent-them.html): A book chapter on team bus factors: why single experts are a risk and a bottleneck, and how pairing, rotation and apprentices remove them. - [The Bus Factor - Why your ‘best’ developer is your biggest problem](https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html): How to spot a bus factor of one in your team and reduce it with standups, pairing, code reviews and knowledge sharing, including the team leader as one. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/