How to reduce your bus factor before someone leaves

Every team has a sentence like "only Dave really understands billing." It's said half as a joke, until Dave goes on holiday the week the payment provider changes its API, or hands in his notice. Then the team discovers how much of the system lives in one head, and how little of it was ever written down.

That risk has a name, the bus factor (or truck factor): the number of people who would have to disappear before a project stalls. This guide covers how to measure yours and how to raise it without turning your team into a documentation factory.

How common a low bus factor is

Low bus factors are normal, not a sign of a badly run team. A 2016 study of 133 popular GitHub projects found that 65% had a truck factor of two or less. These were well-known, actively maintained projects, and most of them depended heavily on one or two people.

Private teams tend to be worse, because small companies naturally grow around a founding engineer or an early hire who built most of the system. And people do move on. In the United States, median employee tenure was 3.9 years in January 2024. Over the life of a product, you should expect most of the people who made its key decisions to leave at some point.

The real loss isn't the code, which stays in the repository. It's the reasoning: why it's built this way, what was tried and rejected, which parts are fragile and why. That knowledge often lived in conversations, DMs and memory, and it leaves with the person.

Measure your bus factor in an hour

You don't need a tool to get a rough picture. Start with git.

# Who has committed to each top-level area, most active first
for dir in src/*/ ; do
  echo "== $dir"
  git shortlog -sn --no-merges --since="18 months ago" -- "$dir" | head -3
done