Guide · · 2 min read
Bus factor in software teams: knowledge only one person has
Which topics in your team hang on one person? What the bus factor measures, what Git misses and how to capture knowledge before someone leaves.
Felix KünneckeCo-founder of Scibly
The key points at a glance
- The bus factor is the smallest number of people a team can lose before a project stalls. At 1, a topic hangs on a single person.
- In a study of 133 popular GitHub projects, 65% had a bus factor of 2 or less.
- The Git history only shows who changed code. Agreements with customers, reasons and workarounds live in meetings and conversations.
- Scibly sees in meetings and what is written down who knows a topic, and shows topics that hang on one person.
- When a topic hangs on one person, Scibly's Interview asks them about it. What they approve, colleagues and their agents find with its source.
- Writing it down makes knowledge reachable. The bus factor only rises once a second person works on the topic.
What is the bus factor?
The bus factor, also truck factor, is the smallest number of people a team can lose before a project stalls. The name comes from the grim question of what happens if someone is hit by a bus tomorrow. What is usually meant is milder: parental leave, a team change, a resignation. When a topic's bus factor is 1, it hangs on a single person.
That is common. Avelino and colleagues went through the Git history of 133 popular open-source projects on GitHub: in 65% of them, losing two people or fewer would leave more than half the files with no one who could maintain them (Avelino et al., 2016).
Try it: who can you do without?
A small team, eight topics. Each dot shows how much a person has contributed to a topic in meetings and in writing. Click a person to take them out of the team:
How the team's knowledge is spread5 people · 8 topics- topics no one knows any more
- 0
- topics only one person knows
- 3
- people missing
- 0
Look at the payment service. Markus has a small dot there: he was in on it once. Still it says "Only Daniel", because almost everything the team knows about it comes from Daniel. Having sat in on a meeting once does not make someone a backup.
Why is the Git history not enough?
Git shows who changed which file. Why a customer's export runs on Mondays, what was agreed in the call with the payment provider and which workaround only one customer needs is not in it. That kind of knowledge comes up in meetings and conversations. A method that also reads code reviews and meetings therefore estimated the bus factor more accurately than one that reads Git alone (Jabrayilzade et al., 2022).
How does Scibly find that knowledge?
Scibly sees in meetings, and in what people write down and approve, who knows which project, system or customer. When a topic hangs on one person, the dashboard shows it under Knowledge with one person, and your AI agents, in Claude Code or ChatGPT for example, see it too. How Scibly handles this data is under security.
What do you do when a topic hangs on one person?
- Let Scibly ask. In a short Interview, spoken or typed, Scibly asks the person about what is still missing on their topics.
- Check and approve. The answers become drafts. What the person approves, colleagues and their agents find, with them as the source.
- Bring in a second person. Written down, the knowledge can be reached, but no one else knows it yet. Give the next payment service ticket to Markus, with Daniel reviewing.
How do you estimate the bus factor yourself?
Without code, one question to each team lead is enough: which three topics could only one person on your team explain? For the repository, give your agent this task:
Go through this repository's Git history for the last 12 months. For each top-level directory, tell me each person's share of the changes, and flag every one where a single person made almost all the changes. Then list topics that are not in the code, such as agreements with customers, release steps or on-call, and ask me for each who besides the person in charge could explain it.
The page for leadership shows how a lead sees where knowledge is missing before a long absence.
