Bus Factor

The bus factor is the minimum number of people whose simultaneous absence would incapacitate work within a defined scope. Avelino and colleagues use this minimum-number definition for the truck factor of a software project. For operational use, specify the service or tasks, the disruption threshold, and the period of absence being considered. Departure, leave, and illness can all expose dependencies, but their duration and available cover differ. A value of one identifies a single-person dependency under those assumptions; it does not measure the size of the resulting loss.

The scope can be a project, team, system, or subset of work. Inspect the underlying tasks rather than count names. If only A can restore data and only B can authorize the required access, either person’s absence blocks recovery: two participants do not imply a bus factor of two. Counting fully interchangeable operators works only when each can perform all the required tasks with the necessary access. GitLab’s emergency-successor concept helps ask who could cover a role for a period, but a successor list is not a complete service dependency model. No available successor implies a factor of one only when one current operator demonstrably meets the defined requirement. If capability is unknown, record it as unverified; if the required work already cannot be performed, record that current gap instead of inventing a resilience score.

A risk, not a rating, and how to raise it

GitLab separates a single point of failure from key talent. Keep the dependency assessment separate from performance ratings, then assess its consequences: which work stops, how quickly harm develops, and what recovery options remain. The same factor can conceal very different risks. Restricted access, system complexity, missing teaching time, and unassigned learning may each contribute. Repeated inability to take leave can add strain and retention risk, but does not establish that a person will leave or explain why they do.

Choose a remedy for the dependency found. A second operator should use the documentation, practice representative tasks, obtain authorized access, and demonstrate readiness before independent duty. Supervised primary work with an expert available as backup can help that learning. A pairing deadline schedules a review; it does not confer competence. Google’s on-call guidance emphasizes retaining production familiarity, and the UK capability framework includes developing others in senior technical work. Managers must allocate the time and cover that make it possible.

Knowledge sharing may need to be combined with automation, simpler recovery procedures, access changes, or alternate support. Set the resilience target from the service requirement. Two genuinely interchangeable operators can cover one person’s absence only while the remaining operator is available and has enough capacity for the required work. Concurrent incidents, additional absence, or round-the-clock coverage may require more. Review readiness after relevant changes as well as on a chosen cadence.

A fictional pipeline team verifies a second operator’s access and recovery skills before assigning independent responsibility in The Same Engineer Every Night. Its target covers specified tasks during one planned absence; it is not a universal two-person staffing rule. Rated Alone, Delivered Together explains succession readiness and the distinction between operational dependency and talent assessment.

References

• GitLab Handbook, Talent Assessment.
• Google, Site Reliability Engineering, Chapter 11: Being On-Call.
• UK Government Digital and Data Profession Capability Framework, Software developer.
• Avelino et al., A Novel Approach for Estimating Truck Factors (2016).