Manu's Vault

Bus Factor

6 min readStatus:Seedling

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?

Definition:

  • The smallest number of people whose simultaneous loss would make a project unable to proceed
  • A measurement of concentration of critical, irreplaceable knowledge
  • Also known as “truck factor” (same concept, different accident) or “lottery factor” (what if someone wins the lottery and quits?)

The Core Risk:

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

Why “Bus”?

  • The metaphor is deliberately provocative: what if this person gets hit by a bus?
  • The more palatable framing “lottery factor” captures the same risk: voluntary departure (promotion, new job, extended leave) is far more likely than accidents
  • Either way, the risk profile is the same: sudden, unplanned unavailability

How Bus Factor Manifests

In codebases:

  • A module or service only one developer has ever touched
  • Commit history shows 90% of changes to a critical area come from one person
  • “You have to ask Alice, she wrote that” — but Alice is on holiday

In processes:

  • Only one person knows how to deploy to production
  • A single individual manages all infrastructure credentials
  • One person understands the legacy integration with the third-party vendor

In domain knowledge:

  • Only the original architect understands why the system is structured a certain way
  • Business rules exist only in one engineer’s head, not in code or documentation
  • The “bus problem” extends to non-technical knowledge: only one person talks to the key stakeholder

Measurement Approaches

Qualitative indicators:

  • “Only X can do Y” statements in team conversations
  • Bottlenecks that form when someone is out
  • Slow onboarding because tribal knowledge isn’t documented

Empirical methods (for codebases):

  • Analysis of code ownership by commit history (tools like git log or code-maat)
  • Ratio of files touched exclusively by one author
  • Coverage of code review: what percentage of code has been reviewed by multiple people?

Research baseline: Empirical studies of open-source GitHub repositories found median truck factors of 2, meaning most projects stall if just 2 people become unavailable — a surprisingly fragile state for widely-used software.

Why It Happens

Organizational causes:

  • Teams organized around individual specialists (see Conway’s-Law)
  • No time or incentive for knowledge sharing (“we must ship”)
  • Promotion of individual heroism over team resilience
  • Lack of pairing, code review, or cross-training practices

Cultural causes:

  • Knowledge hoarding for job security (see Knowledge-Silos-Pattern)
  • “Only I can do this right” mentality
  • Management that rewards individual expertise but not team knowledge-building

Technical causes:

  • Complex, undocumented legacy systems that take years to understand
  • No runbooks, no architecture decision records
  • Systems built without teaching others how they work

Mitigation Strategies

Code and documentation practices:

  • Pair programming and mob programming: Spread knowledge in real time during creation
  • Code reviews: Every PR must be understood by at least one other person
  • Architecture Decision Records: Capture the why, not just the what
  • Runbooks and playbooks: Every operational procedure documented and rehearsed

Team practices:

  • Rotation: Deliberately rotate people through critical areas before knowledge concentration hardens
  • Cross-training sessions: Regular knowledge-sharing between domain owners and the rest of the team
  • “No lone wolves” policy: Any task that can only be done by one person is treated as a risk item in sprint planning
  • Onboarding-driven documentation: Force new team members to document what they learn — gaps surface immediately

Structural interventions:

  • Build T-shaped teams where breadth is valued alongside depth
  • Measure and track bus factor as an engineering health metric
  • Include knowledge distribution as a criterion in architecture reviews

Bus Factor vs. Knowledge Silos

These concepts are closely related but distinct:

ConceptScopeFocus
Knowledge SilosOrganizational / teamInformation trapped behind boundaries
Bus FactorIndividual / codebaseDangerous concentration in a person
  • Knowledge silos describe the structural problem: information not flowing across team or system boundaries
  • Bus factor describes the risk outcome: a specific, measurable vulnerability to individual absence
  • A bus factor of 1 is the most extreme symptom of a knowledge silo

Connection to Architecture

Architects directly influence bus factor:

  • Systems with poor documentation and hidden complexity increase bus factor
  • Architectural decisions that concentrate understanding in one person (e.g., a single service with no documentation owned by one team) directly raise it
  • The facilitative architect treats high bus factor as a structural risk to address — not just a people problem

Conway’s Law implication:

  • Architectures that mirror organizational silos tend to produce high bus factors
  • If Conway’s Law says “the system mirrors the communication structure,” a low-communication team produces a system only a few people understand

Team warning sign:

  • A bus factor of 1 for any production system is a team warning sign — it means knowledge distribution has failed
  • It typically appears 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 of truck factors across 133 GitHub open-source projects
    • Median truck factor found to be 2; most projects are fragile
    • Provides algorithmic methodology for calculating codebase 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.

    • Chapter 3: Team-first thinking and cognitive load limits
    • Team structure as root cause of knowledge concentration
    • Available: https://teamtopologies.com/book

  • Tornhill, Adam (2015). Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs. Pragmatic Bookshelf. ISBN: 978-1680500387.

  • Forsgren, Nicole, Jez Humble, and Gene Kim (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. 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.

Graph View

Backlinks