If only one person on your team knows how the billing service works, your bus factor for billing is one: everything waits when that person is on vacation.
📊 In the 2024 Stack Overflow survey, 30% of developers say knowledge silos impact their productivity ten or more times per week. But can you as an individual actually do something about it?
Visual representation of how knowledge silos can isolate information and reduce team productivity
What is the bus factor?
The bus factor is the minimum number of team members who would have to suddenly be gone, hit by the proverbial bus, before a project stalls because nobody left knows enough to keep it going. Nobody has to get hurt for it to matter: a resignation, a long sick leave or a three-week holiday has the same effect. A bus factor of one means a single person is a single point of failure.
Low numbers are common. A study of 133 popular open source projects on GitHub found that 65% of them had a bus factor of two or less (Avelino et al., 2016). A later analysis of the top 1,000 GitHub projects came to a similar picture: almost half had a bus factor of two or less, and only 10% had six or more (Metabase, 2022). That's open source, so it won't transfer one to one to a company team, but it shows that knowledge sitting with one or two people is common even on well-known projects.
A low bus factor is what a knowledge silo looks like once you put a number on it. A knowledge silo, sometimes called an information silo, is knowledge that one person or one team has and that the others who need it can't get to, so their work slows down.
From a company's perspective, disrupted access to knowledge can block production flow or even cause standstills, resulting in costly delays. For employees, it's often annoying and demotivating. The typical reaction? Complaints about poor organization and resigned acceptance.
The same Stack Overflow survey shows what that costs day to day: 53% of developers say waiting on answers disrupts their workflow, and 61% spend more than 30 minutes a day searching for answers (Stack Overflow, 2024).
How to find your team's bus factor
You don't need a tool for this, just a list and one question.
Write down the systems your team can't afford to lose: the payment flow, the deployment pipeline, the database, the one integration your biggest customer depends on. Then ask for each of them: how many people could fix it at 3 a.m.? Not “has seen the code once”, but could actually find the problem and get it running again without calling someone.
An example of what the list can look like:
| System | Who could fix it at 3 a.m. | Bus factor |
|---|---|---|
| Payment flow | Anna, Marc, Deniz | 3 |
| Deployment pipeline | Marc, Deniz | 2 |
| Reporting export | Anna | 1 |
| Legacy customer integration | Tom, who left in March | 0 |
The lowest number on the list is your team's bus factor, because that's where the work stops first. Every row with a one depends on a single person. A zero means the knowledge is already gone, and you'll find out during the next incident.
If you don't want to do the full list, a few signs point to the same thing: work waits whenever one specific person is on vacation, the same name shows up in every incident, and the documentation for a system is “ask Marc”.
Why knowledge silos happen
Silos usually aren't a tooling problem. A team can have a wiki and still have them, because the reasons are on the people side. Three common ones:
- Knowledge as job security: If you're the only one who understands the system, nobody can replace you. That feels safe. It also means nobody can cover for you, so you get the call at 3 a.m. and on your holiday. And someone who can't be replaced in their role is hard to move out of it, including upwards.
- No time: Writing things down or walking a colleague through a system doesn't close a ticket. When the sprint is full, sharing is the first thing that gets dropped.
- No credit: Fixing the outage at night gets you a thank-you in the channel. Writing the runbook that would have let anyone fix it usually gets you nothing. People do what gets noticed.
None of that is bad intent. It's what happens by default when sharing knowledge is nobody's job, and it looks like something only management can fix.
How to raise your bus factor
However, as an individual you have more influence over this situation than you might think.
Like Michael Jackson sang: If you wanna make the world a better place, take a look at yourself and make a change. 🎶
So, what can you do? Here are some actionable steps:
- Host a Developers Day: Showcase your department's work and plans to other departments, and invite their questions.
- Monthly Personal Knowledge Sharing Sessions: Allow colleagues to ask questions about your area of expertise. Great for self-marketing too!
- Organized Consultation Hours: Set specific times for providing guidance, similar to university office hours of professors, to minimize work interruptions so people know when you will be available.
- Share Learning Resources: Regularly share articles, courses, and resources to promote continuous education.
- Make Your Contribution Visible: Highlight your role in the bigger picture, encouraging others to do the same and fostering mutual understanding.
Those five get knowledge moving between people and across teams. Three more work directly on the number:
- Write the Runbook First: For every system with a bus factor of one, write down the minimum: how to start it, how to check that it's healthy, what usually breaks and how to fix it. One page that exists is worth more than a perfect wiki that never gets written.
- Pair on the Work Only You Can Do: Next time a task lands on you because you're the only one who knows the system, do it together with a colleague, and let them drive while you explain.
- Rotate Who Handles What: Let someone else take the next bug, on-call shift or release in your area while you're still around to answer questions. It's slower the first time, but a lot cheaper than finding out during an incident that nobody else can do it.
How to bring it up with your manager, as a risk
Some of this you can just do. Pairing and rotation cost team time, though, and for that you need your manager on board. “We should share more knowledge” won't get you there. It sounds like a nice-to-have, and nice-to-haves go to the backlog.
A bus factor of one is a risk, so present it as one. The same four steps I use for getting refactoring ideas out of backlog hell work here: Problem, Impact, Approach, Outcome.
- Problem
“Only Anna can fix the reporting export. Nobody else has worked on it in two years.” - Impact
“If it breaks while she's on vacation, month-end reporting for finance stops until she's back.” - Approach
“She pairs with Deniz on the next two changes and they write a one-page runbook.” - Outcome
“In four weeks two people can fix it, at a cost of roughly two days of team time.”
Now your manager isn't deciding whether knowledge sharing is a good thing. They're deciding whether two days are worth removing a single point of failure, and that's a much easier yes.
FAQ
One day or day one
Now, of course, you can think: “Hey, sounds logical, I'll do that too one day” and simply procrastinate on the next article. Or you can think to yourself: “Let's go, I'm going to change something”. One day or day one, you decide.
In our video course, you'll learn more about the IT industry and Skills Beyond Code, including the topics mentioned here. Spreading knowledge is at the heart of multiplier leadership, one of the 7 essential soft skills for software engineers.