The bus factor, also called the truck factor or lottery factor, is the minimum number of team members who, if they suddenly disappeared, would leave a project unable to continue. The morbid framing, “how many people have to be hit by a bus,” is a memorable way of asking a real management question: how concentrated is the knowledge required to keep this software alive? A bus factor of one means a single person is irreplaceable, and the project is one resignation or accident away from a crisis.
The metric captures the danger of knowledge silos. When one developer is the only person who understands a critical subsystem, the deployment process, or an undocumented integration, the team carries a hidden single point of failure that no amount of redundant hardware can offset. The risk is invisible while that person is present and acute the moment they are not, which is exactly what makes it easy to ignore until it is too late.
Researchers have tried to measure it concretely. A 2016 paper by Guilherme Avelino and colleagues, “A Novel Approach for Estimating Truck Factors,” defines the truck factor as “the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated,” and computes it from version-control history using a model of code authorship. Applied to 133 popular GitHub systems, their method found that the large majority of projects had a very low truck factor, with most depending critically on only one or two developers. The result quantified a long-held worry: even widely used open-source software is often sustained by a tiny number of people.
Several forces push the bus factor down. The natural tendency of contributors to specialize, the speed advantage of letting the existing expert handle their own area, and the absence of documentation all concentrate knowledge over time. The same individual variation that drives the “10x developer” story can make matters worse, because a single highly productive author may write code so quickly and idiosyncratically that no one else ever learns it, raising output while lowering the bus factor.
Raising the bus factor is mostly about deliberately spreading knowledge: code review so more than one person has read every change, documentation of the non-obvious decisions and operational procedures, pair programming and rotation so ownership of critical areas is shared, and avoiding the cult of the indispensable hero. The goal is not to eliminate expertise but to ensure that no single departure can stop the project, turning resilience into a property of the team rather than a property of any one person.