The Bus Factor: How Many People Can You Afford to Lose?

The bus factor is the number of team members who would need to suddenly disappear before a project stalls. Someone quits, gets hit by a bus, takes parental leave, or gets acquired into a different team, and critical work grinds to a halt.

It’s one of the most overlooked risks in engineering organizations because it doesn’t show up in sprint metrics. You only discover it when it’s too late. And no, documentation alone doesn’t fix it. Knowledge transfer requires active pairing, rotation, and shared ownership.

Understanding the Risk Levels

Bus Factor of 1 (Critical): One person holds all knowledge. If they leave, the project stops. This is your auth system that only Alice understands, or the deployment pipeline that only runs in Bob’s head.

Bus Factor of 2 (Fragile): Two people share it, but there’s little to no overlap. Each owns half. Better than 1, but you’re still one departure away from someone being completely underwater.

Bus Factor of 3 (Manageable): Real overlap exists. A departure hurts but doesn’t stop delivery. The team can absorb the loss and recover within a sprint or two.

Bus Factor of 4+ (Resilient): Deep Knowledge. The team absorbs departures without missing a beat. This is where you want to be for anything critical.

Map Your Knowledge Distribution

Take your critical systems and map who actually knows them. Not who touched them once, but who could debug a production issue at 3am without calling someone else.

You’ll probably find patterns like this: the auth system is all Alice. The API gateway is mostly Alice and Bob, with Charlie having partial knowledge. The CI/CD pipeline is Bob’s domain. The data pipeline has good distribution across three people.

The gaps are obvious once you map it. If Alice leaves, you lose the auth system entirely. If Bob leaves, you lose both the API gateway and CI/CD.

Ways to Actually Fix It

Pair programming rotation: Rotate pairs across domains specifically for knowledge spreading, not code quality. If the auth system is all Alice, pair her with Bob for two weeks. Then pair Bob with Charlie. Create intentional overlap.

Shared on-call: If only one person can be woken up for a system, you have a bus factor of 1 on that system. Broaden the rotation. Force people to learn by putting them in situations where they have to figure it out.

Code review breadth: Require reviews from people outside the domain. It’s slower today but builds resilience tomorrow. The person who reviews the migration today can help debug it next quarter.

Architecture Decision Records: Document the “why” behind decisions, not just the “what.” That’s what’s hardest to transfer. When someone asks “why did we choose this approach?” the answer shouldn’t live in one person’s head.

Run the Audit

For every critical system, count how many people could debug a production issue at 3am without calling someone else. If the answer is 1 for anything, that’s your highest-priority knowledge-sharing investment this quarter.

Don’t wait until someone gives notice to discover you have a problem.