The Bus Factor Is a Design Metric

I assessed bus factor across 6 engineering teams and found that 4 of 6 had at least one system where a single person’s departure would halt development for 3 or more weeks. Treating bus factor as a design metric (target: minimum 2 for every critical system) reduced single-point-of-failure systems from 11 to 3 in 2 quarters.

Why should bus factor be treated as a design metric rather than a risk metric?

Treating bus factor as a risk metric produces awareness without action. Treating it as a design metric produces targets, timelines, and accountability for knowledge distribution.

I calculated the bus factor for 23 critical systems across 6 engineering teams. Eleven systems had a bus factor of 1: one person who could maintain, debug, or deploy the system. The teams knew this was a risk. It appeared in retrospectives and risk registers. But awareness had not produced change because “improve the bus factor” was never treated as a work item with a deadline and an owner. It remained a permanent concern, never urgent enough to prioritize.

I reframed bus factor as a design metric with a target: every critical system must have a minimum bus factor of 2. Systems below the target received a remediation timeline, an owner, and a quarterly review. The reframing changed behavior. A risk is something you worry about. A metric below target is something you fix.

What practical actions increase bus factor?

Three actions increase bus factor: paired maintenance rotations, documented runbooks for every critical system, and quarterly knowledge transfer sessions.

Paired maintenance rotations assigned 2 engineers to every on-call rotation, with the secondary engineer required to handle at least one incident per month. Documented runbooks (as I described in the case for runbooks) codified the knowledge that previously existed only in one person’s memory. Quarterly knowledge transfer sessions required the primary owner of each bus-factor-1 system to spend 4 hours teaching a second engineer. These are not novel ideas. What made them work was the design metric framing: they had a target, a timeline, and quarterly accountability. The same approach applies to architecture decision records, which preserve the reasoning behind decisions after the decision-maker departs.

The unresolved tension is that bus factor improvement competes with feature development for the same engineering time. Nobody will resolve that tension until the bus factor is treated with the same urgency as the feature backlog. Metrics that do not appear on dashboards do not get managed.