The Bus Factor

It's 4:47pm on a Friday. You know the rest.

Someone who has been quietly holding a significant chunk of your platform together has sent a politely worded email explaining that they've accepted an offer elsewhere and their last day is in four weeks. Congratulations are extended. Drinks are arranged. A Slack message goes out.

Then, somewhere around 9am on Monday, the questions start.

"Do you know how the notification automations work?" "Where does the data actually live?" "Is any of this documented?" The answers, when they come, are variations on the same theme: in Jamie's head, mostly. Or Sarah's. Or whoever it is that just handed you four weeks to reverse-engineer years of accumulated knowledge before they walk out the door with it.

This is the bus factor. The uncomfortable little metric that asks: how many people on your team would need to be hit by a bus before you couldn't keep the lights on? (The concept was coined in software engineering circles in the 1990s, probably by someone who'd already lived through this exact scenario and needed a name for the feeling.)

Most teams, if they're honest, have a bus factor of one for at least a few things. Often the most important things.

The cruel irony is that bus factor problems are usually created by the best people. Not the difficult ones, not the ones cutting corners - the ones who care. The developer who built a fragile system and then, quietly and without fanfare, spent the next two years keeping it running through sheer expertise and institutional memory. The analyst who knows every quirk of the data model because they were there when the decisions got made and can remember exactly why. You don't notice the bus factor until the person who's been carrying it stops carrying it.

I've watched organisations discover their bus factor in real time. A council platform with twenty live applications, where three of them are held together by the mental model of a single developer who is now leaving for the private sector. A charity's entire reporting function tied to a spreadsheet only one person fully understood, and she retired in March. A startup where the only person who knew how the payment integration actually worked was the CTO, who was also responsible for sales, strategy, and apparently sleep deprivation.

None of these were failures of intent. Everyone meant to document it. There just wasn't time, and then there was even less time, and then one day there was a leaving card and a collection and a very difficult two weeks.

The fix isn't complicated. It's just unglamorous enough that teams avoid it until the crisis forces their hand.

The first part is structural: no application should be built or maintained by a single person working in isolation. Pair building - one person leading, one in review - isn't just about catching bugs before they reach production. It's a knowledge distribution mechanism. Two people understand the system when you're done, not one. That's twice the bus factor, achieved at the cost of some coordination overhead. Worth it.

The second part is documentation that someone will actually maintain. Not a wiki page that gets created in a burst of good intentions and then silently decays. Something small enough to stay current. A single structured record per application that captures the things you'll actually need when something goes wrong. Where the data lives, who owns it, what the known quirks are, when it was last touched and by whom. An App Passport, essentially. The name matters less than the discipline of keeping it alive.

The third part is the one that actually changes culture: a regular session where people share what they know. Not a training course, not a knowledge management initiative, not a policy. A fortnightly meeting where one person shows the rest of the team something they've figured out. A technique, a pattern, a lesson from a production incident. The presenter rotates. The sessions get recorded. Over time, you build a library of practical learning that outlasts any individual.

Call it a Builder Guild, or a tech talk. The name doesn't matter. The consistency does.

None of this eliminates the bus factor entirely. Someone leaving will always take some knowledge with them. That's just the nature of expertise. It accumulates in people, not documents, and the best you can do is slow the leak.

But there's a difference between a team that loses someone and needs a few weeks to absorb the impact, and a team that loses someone and spends three months trying to understand what they were actually doing. The difference is whether you treated knowledge as an asset worth managing, or as a side effect of getting the work done.

The bus, in my experience, doesn't usually arrive on a Friday afternoon. It arrives as a politely worded email at 4:47pm, giving you four weeks and a lot of questions you should have been able to answer already.

Start answering them now.