Bus Factor of One

What It Is

The bus factor is the number of people who would need to be hit by a bus — that is, suddenly become unavailable — before a project is in serious trouble. A bus factor of one means a single person holds knowledge or access so critical that the project stalls without them. They are the only one who understands a key system, holds a vital credential, or can perform an essential task.

It is one of the most common and dangerous risks in software organizations, and it often hides in plain sight because the indispensable person makes everything look effortless.

Why It Happens

• Specialization. One person built a system and naturally became its sole expert.
• No documentation. Knowledge lives in heads and chat threads, never written down.
• Time pressure. Cross-training and documentation are deprioritized in favor of shipping.
• Comfort. It is faster, in the short term, to let the expert handle their domain alone.

Why It Hurts

The project has a single point of failure. A vacation, illness, or resignation can halt delivery, lock the team out of systems, or lose institutional knowledge permanently. The indispensable person cannot take real time off without things breaking, which leads to burnout and resentment. Onboarding new engineers is slow because there is no shared, written understanding to draw on.

Warning Signs

• "Only Alex knows how that works."
• Key systems have no documentation or runbooks.
• The team gets nervous when a particular person takes vacation.
• There is no cross-training or rotation across critical areas.

Better Alternatives

• Pair programming and mob sessions. Knowledge transfers naturally as people build together.
• Documentation and runbooks. Capture how critical systems work and how to operate them.
• Code review. Every significant change is seen by at least one other person, spreading understanding.
• Shared ownership. Rotate responsibilities so no single person owns a critical area alone.

How to Refactor Out of It

Identify the bus factors first: list the critical systems and ask who, besides one person, could maintain each. Prioritize the riskiest. Use pairing and rotation to deliberately spread knowledge, and require that the expert document and demonstrate their systems to at least one teammate. Make code review mandatory so understanding diffuses with every change. Run "vacation drills" where the expert is unavailable on purpose to surface gaps. The aim is a team where any critical task can be done by at least two people, turning a fragile dependency into a resilient capability.