What Is the Bus Factor in Software Development? (And Why Almost No One Measures It)

The bus factor (or truck factor) is the minimum number of people who'd have to leave a team overnight — by resignation, leave, or any other reason — before the project stalls for lack of anyone who understands how to keep going. A bus factor of 1 means it takes just one person leaving for nobody else to know how to touch a certain module, access production, or explain why a key architecture decision was made. The higher the number, the more that critical knowledge is spread across the team — and the less the project depends on nothing ever happening to any one person.

The term emerged in the software development community in the early 2000s as a colloquial way to name a risk that already existed: knowledge concentrated in too few heads. Today it shows up both in technical due diligence audits — to gauge how fragile a team is before an acquisition — and in the day-to-day management of any engineering team.

How is a team's bus factor calculated?

There's no single formula. The most-cited academic approach — used in a 2016 study by Avelino, Passos, Hora, and Valente on hundreds of popular GitHub repositories — estimates bus factor by looking at what share of a project's code is concentrated in its top authors' commits: if two or three people already cover most of the history, that's the number. In practice, the simplest version is to ask one question per critical area of the project: if this person left tomorrow, could someone else step in without everything grinding to a halt?

• Architecture decisions and why they were made
• Production access and incident response
• The most complex or least documented code modules
• Infrastructure, DevOps, and vendor credentials or access
• Client context: what was agreed, what was tested, what didn't work before

Why is the real bus factor of most teams lower than they think?

The same Avelino study found that 65% of the GitHub repositories they analyzed had a bus factor of 2 or lower — meaning two people (or fewer) held enough concentrated knowledge to stall the project if they left. This isn't a problem specific to small or neglected projects: these are the same popular repositories anyone would assume were well organized.

A later study focused specifically on how industry teams experience this (Jabrayilzade et al., ICSE 2022) found something even more uncomfortable: most developers know the risk exists, but the practices that reduce it — documenting, rotating ownership of critical code, pair programming — get applied inconsistently until someone actually leaves and the problem becomes real.

And the odds of that someone actually leaving aren't low: according to LinkedIn data, turnover in the tech sector ran between 20% and 25% in 2025, well above the 10.9% average across all industries. A low bus factor in a high-turnover sector isn't a theoretical risk — it's a bet with the odds stacked against it.

Does an already-formed squad have a better bus factor than a freelancer or an ad hoc consultancy?

A freelancer working alone has, by definition, a bus factor of 1 — there's nobody else to ask. A consultancy that assembles a new team for each project doesn't start off much better either — the team is still in the literal "forming" stage of Tuckman's model, and hasn't yet built the shared ground that lets knowledge get shared instead of piling up in one person.

A squad that already worked together on previous projects starts from a different place: architecture decisions, code standards, and the context behind each milestone already passed through several people before the current project even began. That doesn't eliminate the risk — no team has an infinite bus factor — but it distributes it from day one, instead of having to build that distribution on the fly while the project is already underway.

How do you reduce the bus factor without doubling the team's cost?

The most expensive fix is the most obvious one: put two people on every role, full time. The approach that actually scales is making knowledge visible as it's generated, instead of rebuilding it after someone's already gone. Documenting decisions at the moment they're made — not in a separate wiki nobody updates —, rotating code review across the most critical modules, and making sure production access never depends on a single person are all cheap compared to the cost of rebuilding that knowledge from scratch.

Evidence also makes it easier to measure from the outside: when a project's progress is documented in the repository — who touched what, in which milestone, against which acceptance criteria — the knowledge stops living only in one person's head and the meetings they happened to attend. It's the same logic that makes replacing a squad mid-project far simpler when the work done up to that point is verifiable, not just a promise that it's "almost done."

Before a squad ever shows up as an option in a Zenit match, it's already gone through ZenitRank verification — which measures signals like milestone completion and client diversity, not just a résumé. A low bus factor tends to show up there before it turns into a problem halfway through a real project.