Bus factor teaching infographic: a team of ten around a server rack, bar chart of measured GitHub bus factors, and three structural interventions with their costs Engineering & Growth • Sensei Learning System

The Number That Tells You How Fragile Your Team Really Is

The bus factor — what it actually measures, the numbers that make it concrete, and the interventions that genuinely raise it.

Core Concept

The bus factor is a measure, not a principle. It counts the minimum number of people who would need to leave a project — resignation, illness, transfer, promotion — before the project stalls due to knowledge loss.

A bus factor of 1 means one departure halts progress on that component. A bus factor of N means the knowledge is distributed across at least N heads, so any single departure is survivable.

What Most Summaries Miss

It is not about the risk of someone leaving. It is about the distribution of understanding. A team of ten with a bus factor of 1 has nine people who cannot continue the work — which means nine people who also cannot meaningfully review it, challenge its assumptions, or propose alternatives to it.

The knowledge silo is a design defect in the team's information architecture, not a personnel risk.

Key Components

① A Count of Survivability

Minimum departures until the project stalls. 1 = one resignation or illness halts that component outright.

② Distribution, Not People

Measures where understanding lives. A BF-1 component means everyone around it is a bystander, not a backup.

③ Structural Interventions

Code review by someone who could take over, pair programming on critical paths, deliberate rotation between subsystems.

④ Each Intervention Has a Cost

Review adds latency; pairing halves throughput on that task; rotation slows specialists. The BF is the metric that justifies paying them.

The Number That Makes It Concrete

Avelino et al. (2016) measured bus factor across 133 popular GitHub repositories:

2
median bus factor across all 133 repos
57
Linux — knowledge spread across the kernel community
~60%
of projects sit at bus factor 1 or 2

Most widely-used open-source software depends on one or two people for its core subsystems.

How It Works in Practice

  1. Measure before prescribing. Count how many people committed to each subsystem in the last 90 days. One committer = a bus-factor-1 component.
  2. Reframe the question. Not "should we fix this?" but "can we afford to discover the cost during an incident rather than during a planned rotation?"
  3. Apply a structural fix. Mandatory review by a second person who could take over (not a rubber stamp), pairing on the critical path, or rotating a person into the subsystem.
  4. Let the metric justify the cost. If it is 1, you are already paying the price of fragility in unplanned incidents — you just have not invoiced it yet.
Why "just document everything" fails: documentation raises the bus factor only when it is maintained — which requires the same distributed understanding it is meant to create. Stale docs are worse than no docs, because they teach the wrong model.

Where You Meet It in the Wild

Checkpoint — Answer Before You Move On

  1. A team of ten has bus factor 1 on the billing subsystem. What does that say about what the other nine can — and cannot — do with that code? It is a statement about distribution, not departure risk.
  2. From the measured data (median 2, Linux 57, ~60% at 1–2): name one structural intervention that raises bus factor, and the concrete cost it carries. Review adds latency, pairing halves throughput, rotation slows specialists.
  3. Why does "just document everything" only raise the bus factor under one condition — and why are stale docs worse than none? Maintenance needs the very understanding the doc is supposed to create.