Core Idea

The bus factor (also called “truck factor” or “lottery factor”) is the minimum number of team members who, if suddenly unavailable, would cause the project or system to stall. A bus factor of 1 means the entire operation depends on a single person’s knowledge. It is a quantitative proxy for how dangerously concentrated knowledge is in a team or codebase.

What Is the Bus Factor?

  • The smallest number of people whose simultaneous loss would make a project unable to proceed
  • A measurement of concentration of critical, irreplaceable knowledge
  • “Lottery factor” captures that voluntary departure (promotion, new job) is far more likely than accidents — but the risk profile is identical

Risk scale:

  • Bus factor = 1: Single point of failure — one person holds critical knowledge
  • Bus factor = 2: Still fragile — simultaneous vacation or illness can cripple delivery
  • Bus factor ≥ 3–4: More resilient — knowledge is spread enough to survive normal team churn

How Bus Factor Manifests

  • In codebases: A module only one developer has touched; commit history shows 90% of changes to a critical area from one person
  • In processes: Only one person knows how to deploy to production or manages all infrastructure credentials
  • In domain knowledge: Business rules exist only in one engineer’s head; only the original architect understands why the system is structured a certain way

Research baseline: Empirical analysis of 133 GitHub open-source projects found a median truck factor of 2 — most projects stall if just 2 people become unavailable.

Why It Happens and How to Address It

Root causes:

  • Teams organized around individual specialists (see Conway’s-Law)
  • No time or incentive for knowledge sharing; promotion of individual heroism
  • Knowledge hoarding for job security (see Knowledge-Silos-Pattern)
  • Complex, undocumented legacy systems with no runbooks or ADRs

Mitigations:

  • Pair/mob programming and mandatory code review spread knowledge at creation time
  • Rotation through critical areas before concentration hardens
  • Architecture Decision Records capture the why, not just the what
  • Build T-shaped teams; measure bus factor as an engineering health metric

Connection to Architecture

Architects directly influence bus factor through the systems they design. Systems with poor documentation and hidden complexity raise it; the facilitative architect treats high bus factor as a structural risk. Conway’s Law implies that architectures mirroring organizational silos tend to produce high bus factors — low-communication teams produce systems only a few people understand.

A bus factor of 1 for any production system is a team warning sign that knowledge distribution has failed, typically appearing alongside slow onboarding, bottlenecks, and developer frustration.

Sources

  • Avelino, Guilherme, Leonardo Passos, Andre Hora, and Marco Tulio Valente (2016). “A Novel Approach for Estimating Truck Factors.” Proceedings of the 24th IEEE International Conference on Program Comprehension (ICPC 2016). Austin, TX, USA. DOI: 10.1109/ICPC.2016.7503718.

    • Empirical measurement across 133 GitHub projects; median truck factor of 2; algorithmic methodology for calculating bus factor
  • Hunt, Andrew and David Thomas (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley. ISBN: 978-0201616224.

  • Skelton, Matthew and Manuel Pais (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. ISBN: 978-1942788812.

  • Tornhill, Adam (2015). Your Code as a Crime Scene. Pragmatic Bookshelf. ISBN: 978-1680500387.

  • Forsgren, Nicole, Jez Humble, and Gene Kim (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. ISBN: 978-1942788331.

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.