The Bus Factor: The Metric Most Engineering Teams Ignore Until It's Too Late

Your bus factor is not theoretical. It is a business continuity metric.

If you haven't heard the term, here's the short version: bus factor is the number of people on your team who, if they suddenly disappeared, would put your project in serious trouble. Illness, vacation, burnout, or a resignation letter are all far more likely culprits than an actual bus, but the effect is the same. Knowledge walks out the door, and momentum stops with it.

A bus factor of 1 is the most dangerous number a team can have. It means your project's continuity depends entirely on one person's calendar staying clear. A higher bus factor means your team can absorb a surprise without missing a beat.

Why This Keeps Happening

Most teams don't set out to create single points of failure. They emerge naturally: one engineer owns the payments service because they built it, one person understands the deploy pipeline because they set it up two years ago, one person is "just faster" at fixing a certain class of bug. Every one of these is a reasonable short-term decision that compounds into long-term risk.

The problem is rarely visible until the person is gone (a new job, a long illness, a well-earned vacation), and suddenly a ticket that should take an hour takes a week, because nobody else knows where the bodies are buried.

How to Actually Raise Your Bus Factor

Increasing bus factor isn't about grand initiatives. It's about a handful of consistent habits:

• Redistribute ownership, not just work. When a low-urgency bug comes in, resist the urge to hand it to the person who already knows that code. Hand it to someone who doesn't, with support available if they get stuck.
• Make documentation part of "done." Design docs, code comments, and README updates aren't optional extras; they're what lets someone else pick up where you left off.
• Everyone reviews code, not just the senior engineers. Reviews are one of the cheapest ways to spread context across a team.
• Keep a regular pulse on the team. Standups, syncs, or async updates all work. The goal is that critical information isn't trapped in one person's head.
• Team leads should aim to be dispensable. A mature team can run its day-to-day without the lead in the room. That's a sign of strength, not a threat to the lead's role.

Why This Is a Business Risk, Not Just an Engineering One

We've seen it play out the same way across teams and companies: a project stalls or ships late, and when you trace the root cause back far enough, it's the same story: the person who knew the most left, and nobody else was close behind.

This is exactly the kind of risk that's invisible until it isn't. That's why surfacing it matters; not as a surveillance exercise, but as an early warning system. At BetterEngineer, we do this by interviewing engineers directly about ownership: who actually understands a system, who'd be stuck without them, and where the gaps are before they become emergencies. We think of bus factor the same way a CFO thinks of runway: a number you should always know, not one you discover in a crisis.

Know your bus factor. Then go raise it