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.
Related Concepts
- Knowledge-Silos-Pattern — Structural cause of high bus factor
- Architect-as-Knowledge-Facilitator — Architect’s role in reducing it
- 02-T-Shaped-Skills-Model — T-shaped teams naturally lower bus factor through breadth
- Conway’s-Law — Organizational structure concentrates knowledge; architecture follows
- Team-Warning-Signs — Bus factor of 1 is a warning sign for team health
- Growth-Mindset-in-Software-Teams — Cultural foundation for knowledge sharing
- Knowledge Flow vs Knowledge Stock — High bus factor = knowledge stock, not flow
- Code-Review-as-Feedback — Code review spreads knowledge and lowers bus factor
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.
- Popularized the concept in mainstream software development literature
- Available: https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/
-
Skelton, Matthew and Manuel Pais (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. ISBN: 978-1942788812.
- Team structure as root cause of knowledge concentration; cognitive load limits
- Available: https://teamtopologies.com/book
-
Tornhill, Adam (2015). Your Code as a Crime Scene. Pragmatic Bookshelf. ISBN: 978-1680500387.
- Quantitative analysis of code ownership using commit history; identifying knowledge concentration hotspots
- Available: https://pragprog.com/titles/atcrime2/your-code-as-a-crime-scene-second-edition/
-
Forsgren, Nicole, Jez Humble, and Gene Kim (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. ISBN: 978-1942788331.
- Cross-functional knowledge as predictor of delivery performance
- Available: https://itrevolution.com/product/accelerate/
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.