Bus Factor: When One Person Is the Single Point of Failure

Bus Factor: When One Person Is the Single Point of Failure

An SME owner reads a resignation email, then reaches for the deploy runbook. It turns out to live only in one person's head. The vault has an admin password nobody else has touched in two years. The vendor's direct line is saved in a phone walking out the door in two weeks.

None of this shows up on a risk register until the day it does. This risk has a name, and it's older and better studied than most owners assume.

What "bus factor" actually means

Think of your team like a padlock with a single key. Lose that key and everyone's locked out. That's a low bus factor.

The term traces to a post on the Python mailing list on June 29, 1994. NIST researcher Michael McLay wrote a fictitious news item — "Guido's unexpected death has come as a shock to us all..." — to provoke discussion about how dependent the young Python project was on its creator, Guido van Rossum. The post itself never uses the phrase "bus factor." The term's naming history runs separately through "truck number" in the Pattern Languages of Program Design literature of the mid-1990s.

Even so, the McLay post is widely cited as the earliest documented instance of the question being raised about a real project.

Wikipedia's bus factor article gives the working definition. It's the minimum number of team members who have to suddenly disappear before a project stalls for lack of knowledgeable people to carry it. The same idea also goes by lottery factor, truck factor, or circus factor, depending on who's asking.

Williams and Kessler's 2003 book Pair Programming Illuminated defined truck factor as a headcount. It's the number of people who'd have to be hit by a truck — or quit — before a project is in serious trouble. That name stuck as the standard software-engineering term for the risk.

What the data says

It's tempting to assume this only happens to sloppy teams. It doesn't. Researchers at UFMG built an automated tool to estimate truck factor across 133 popular GitHub projects. Combined, that's more than 373,000 files, 41 million lines of code, and over two million commits.

Sixty-five percent of those projects had a truck factor of 2 or less. Losing one or two contributors would put most of them in serious trouble, and these are well-known, actively maintained codebases, not abandoned side projects.

The researchers checked their estimates against reality by asking the developers themselves. They opened GitHub issues on 114 of the 133 systems and got answers from 67, totaling 106 respondents. After excluding five unreliable responses, they had usable data from 62 systems.

Among those, 84% agreed or partially agreed that the people the tool flagged as truck-factor authors really were the main contributors. 53% gave a positive or partially positive assessment of the number itself. Knowledge concentration isn't a hypothesis. It's the normal state of most codebases, confirmed by the people who wrote the code.

How SMEs find out the hard way

Larger organizations sometimes catch this in an audit or a succession plan. Smaller ones usually find out during an event. A resignation, a sudden illness, a consultant's first week through the infrastructure, or an incident nobody on-site can fix at 2am.

The worst-case version played out in San Francisco in 2008. Network administrator Terry Childs was the only person holding administrative passwords to the city's FiberWAN, the network carrying payroll, email, and law-enforcement and jail data.

When his supervisors asked for the credentials, he refused, and the city lost administrative control of its own network. Childs was later convicted of felony network tampering in April 2010. He was sentenced to four years in state prison, and ordered to pay the city nearly $1.5 million in restitution.

Most bus-factor incidents end in an expensive week of downtime rather than a courtroom. But the underlying failure is identical: one person held keys nobody else could reach.

The three usual suspects in a small IT operation

Most SMEs I work with carry some version of the same three single points of failure. IT is just the easiest place to spot the pattern:

• The one admin with root or vault access. Server credentials, domain registrar logins, cloud console access, all reachable through one person's memory or one unshared password manager.
• The one developer who understands the legacy codebase. No comments, no architecture notes, undocumented business rules buried in conditionals nobody has touched since they were written.
• The one freelancer or vendor contact who never wrote anything down. A hardware integration, a custom script, a firmware quirk, all living in someone else's head, on someone else's payroll.

Fixes, in order of effort

Write the runbook. Google's Site Reliability Engineering team states plainly that it works to minimize single points of failure, including humans. It also requires on-call processes to be documented before a product launches, while the knowledge is still fresh in someone's head. This is the cheapest fix, and the one most SMEs skip because nobody bills for writing things down.

Move credentials into a shared vault with role-based ownership. A password manager with team accounts, not one person's memory and not a spreadsheet on a laptop. Access should survive a departure without a scramble to reset everything at once.

Use code review as a forcing function. A pull request only one person can approve, because only one person understands the code, is a bus factor problem wearing a process disguise. Even light review spreads context that would otherwise sit in one head.

Build a structured handover checklist. Access lists, vendor contacts, architecture notes, known quirks: written down before someone leaves, not reconstructed under pressure after they're gone.

Where hiring a consultant fits in

Bringing in outside help can move this number in either direction. A consultant who documents as they go, adds entries to the shared vault instead of a personal notebook, and writes reviewable code raises your bus factor.

A consultant who builds something only they understand, with credentials only they hold, lowers it. You've paid to add a single point of failure instead of removing one. Before you sign anything, check how a freelance engagement handles IP and documentation ownership, because that contract is where this risk gets decided.

Check this week

A low bus factor isn't a hypothetical. It's measurable, and it's fixable with a few concrete questions:

• If your most senior technical person left tomorrow, who has the deploy credentials?
• Is there a written runbook for your top three operational processes, or does it live in one person's head?
• Are vendor and freelancer contacts documented somewhere the whole team can reach, not just in one phone?
• Has anyone reviewed the code that runs your business besides the person who wrote it?

None of these take more than an afternoon to answer. Most SMEs find the answer worse than they assumed — still better than finding out during a resignation.