Bus Factor: How to Find and Raise It on Your Team

One person set up your deploy pipeline two years ago. They are the only one who knows why the staging cutover has that one manual step, and where the secret rotation actually lives. Last Tuesday they were out with the flu. A release that normally takes twenty minutes did not ship for two days, because the four engineers who tried could not find the thing that lived in one head, and that head was asleep with a fever.

That is a bus factor of one. Most teams have several, and cannot name a single one of them, because the knowledge that would let them notice is the same knowledge that is missing. The number stays invisible right up until the person who holds it is unreachable, and then it is the only number that matters. This is a measurable property of your team, not a vibe, and it is fixable. Here is how to find your real bus factor, what a bus factor of one looks like before it bites, and how to raise it in a way that lasts.

What is the bus factor?

The bus factor is the number of people who would have to suddenly become unavailable, by quitting, going on leave, getting sick, or the morbid original framing, being hit by a bus, before a project stalls because the knowledge to keep it running left with them. It is also called the truck factor or the lottery factor, and it measures one thing: how well the critical knowledge on your team is distributed, which tends to track the shape of your org chart more than anyone intends. Wikipedia's definition puts it as the risk that comes from information and capability not being shared.

A bus factor of one is the dangerous case. One person holds knowledge nobody else has, so their absence stops the work. A high bus factor is the resilient case: the knowledge is spread across enough people that losing any single one is survivable. The goal is never a specific number. It is knowing your number for the things that matter, and making sure none of them sits at one.

Search the term and you get that definition, and then three lines of advice that show up on every page: write documentation, cross-train, do code reviews. All true, and all close to useless on their own, because none of them tells you your actual number or which thing to write down first. The two questions worth your time are the two nobody answers: how do you measure your bus factor, and how do you raise it without generating a pile of documents that rot?

How to measure your bus factor

There is real academic work on computing a bus factor from commit history, assigning authorship of files to people and finding the smallest group whose loss would orphan a large share of the codebase. The theory and practice of computing the bus factor is a good survey if you want the algorithm. For a working team, you do not need it. Commit history also lies: the person who committed a file is often not the person who understands the system it belongs to, and plenty of critical knowledge (the deploy runes, the customer who must be called before a migration, the reason a config value is what it is) never touches the repository at all.

The fast version that actually reflects risk is a conversation and a table. List your critical systems and capabilities, the things that would hurt if they broke on a bad day. For each one, ask a concrete question: how many people could take this over tomorrow, with no ramp-up, if the current owner were unreachable? Count them. That count is the bus factor for that capability, and the lowest numbers are your exposure.

Read the table and the work becomes obvious. You do not have "a bus factor." You have one per capability, and the number that can hurt you is the lowest one sitting under something important. Rank the rows by criticality multiplied by fragility, and the top of that list is where you spend your effort. In the example, Priya is a single point of failure for two critical systems and Sam for one; that is where you start, not with a blanket "write more docs" mandate that treats the deploy pipeline and the office coffee order as equally urgent.

What a bus factor of 1 looks like

You do not have to wait for someone to leave to find your ones. A bus factor of one has a smell, and it is consistent across teams. The warning signs are worth learning because they show up months before the person actually disappears.

• One name comes up in every incident. When anything breaks in a given area, the same person gets paged, gets pulled into the thread, or gets a "quick question" on their day off. The team has quietly agreed that this is theirs.
• A system nobody else will touch. There is a service or a script that engineers route around. It works, so nobody has had to learn it, which means nobody has learned it. That avoidance is Chesterton's fence in reverse: the safest-looking move is leaving it alone forever, when the actual fix is figuring out why it works the way it does.
• "Ask X" is the documentation. The onboarding answer to a whole category of questions is a person's name, not a page. When the real documentation is a human, that human is a bus factor of one.
• Onboarding means shadowing one senior for weeks. If a new hire can only get productive by sitting next to a specific person, that person is carrying knowledge that exists nowhere else. Often they have not written it down because they can no longer imagine not knowing it.
• Vacations get interrupted. The clearest signal of all. If someone cannot take a week off without a "sorry, one thing," their bus factor is one and everyone already knows it, including them.

As Laws of Software Engineering puts it, a bus factor of one means one person holds critical knowledge and the project is effectively doomed if they disappear. The uncomfortable part is that a bus factor of one is usually comfortable, right until it is not. The single owner is efficient. They are fast, they do not need to coordinate, they never have to write anything down. That efficiency is exactly what hides the risk, and it is why raising a bus factor always feels like slowing down before it feels like insurance.

How to raise your bus factor

Here is where the generic advice fails hardest. "Write documentation" is advice nobody can act on, because it does not say which document. Dumping everything one person knows into a wiki page produces a wall of text that goes stale in a month and helps no one. Different kinds of knowledge need different artifacts, and each artifact has a shape and a home. Match the knowledge to the right one and you get something a second person can actually use.

The point of the table is that "raise your bus factor" becomes a list of specific, small acts instead of one impossible one. Priya does not need to document the deploy pipeline in the abstract. She needs to write one runbook for the release procedure and one ADR for why the staging cutover has that manual step. Sam writes one design doc for the schema and one runbook for migrations. Each of those is an afternoon, not a quarter, and each one moves a bus factor from one to two the moment a second person reads it and can follow it.

Cross-training and pair working matter too, and they do something the artifacts cannot: they transfer the judgment that never fits on a page, the sense of when a procedure is about to go wrong. But person-to-person transfer has a bus factor of its own. If Priya trains Sam and they both leave, you are back where you started. An artifact moves knowledge from a person to a page, and a page does not quit, does not go on vacation, and does not forget. The strong teams do both: they pair to spread judgment, and they write to spread the facts. Keeping those artifacts in version control and reviewed like code is what stops the writing from being a one-time event that decays the day after.

The catch: documentation raises your bus factor only if it is true

This is the part the three-line advice never mentions, and it is the part that decides whether any of this works. Writing something down raises your bus factor only for as long as what you wrote stays true. The moment it drifts, it does the opposite of what you built it for.

A runbook that points at a database you decommissioned in the spring is not a bus factor of two. It is a bus factor of one with extra steps. The one person still knows the real procedure. Everyone else now has a page that confidently tells them the wrong thing, so they follow it, hit the wall, and page the one person anyway, having lost an hour first. Stale documentation is worse than no documentation, because no documentation at least makes people ask. A wrong page makes them trust.

This is the half-life problem that sits under every written artifact. Code changes. The runbook, the ADR, the onboarding doc all keep rendering exactly as they did the day they were written, describing a system that has moved on without them. Nobody edits a document to make it wrong; it goes wrong by standing still while the world moves. So the honest version of "write it down to raise your bus factor" has a second clause: and give the writing a way to tell you when it has stopped being true. A last-verified date that is separate from the last-edited date. A trigger that flags the page when the thing it describes changes. An assistant that reads what you wrote and checks it against the code or the system it points at, and surfaces the mismatch before an incident does.

That is the problem Scribelet is built around. A note is not a place you dump knowledge and hope; it is something that should fight its own decay, telling you which of your team's runbooks, decisions, and docs have quietly gone out of date since anyone last looked. You can try it free and keep the knowledge that would otherwise live in one head somewhere it gets checked instead of merely trusted.

Getting started

You can start this afternoon, and you should start small. Pull up your critical systems and score them the way the table above does: for each one, how many people could own it tomorrow. Find the lowest number sitting under something important. That is your most expensive bus factor, and it is the only one worth fixing first.

Then write the single artifact that captures what that one person knows, the runbook or the ADR or the design doc, whichever matches the kind of knowledge it is. Have a second person follow it, without the expert in the room, and fix everything they get stuck on. That act, done once, has already moved a bus factor from one to two. Do it again next month for the next-lowest number. And put a verification date on each one, because a bus factor you raised with a document you never re-check will quietly slide back to one while the page still looks fine.

The bus factor is not really about buses. It is about whether your team's ability to keep working depends on any single person staying reachable. You cannot make that risk zero, but you can find it, name it, and spread it, one artifact at a time, before the sick day that would have found it for you.