Three months’ notice sounds like enough time.
It isn’t.
Not for the files nobody else has ever touched. Not for the modules where one person made every decision for the last two years. You discover those files during the handover. Or after it.
We call it a knowledge transfer problem. It isn’t one.
It’s a visibility problem.
What bus factor actually means
The term comes from a thought experiment: how many people on your team would need to be hit by a bus before the project is in serious trouble?
Morbid — but precise.
A bus factor of 1 means exactly one person understands a critical part of your system well enough to maintain it, extend it, or explain it to someone else. If that person leaves — for any reason — that knowledge leaves with them.
Most teams have a rough intuition that this exists somewhere. Few have any idea where exactly, or how severe it is.
Why it’s hard to see
The standard tools don’t help here. Git blame shows you who last touched a file. It doesn’t tell you who understands it.
There’s a subtler problem too: ownership today says nothing about who built the mental model. A file can have three active contributors right now — but the person who designed the core logic left eighteen months ago. The three people touching it today are working from partial understanding, adding to something they didn’t fully architect.
This is what we mean by temporal ownership. It’s not just who is working on something now — it’s who has the accumulated context from the decisions that shaped it.
Standard tooling shows you the present. It doesn’t show you the history of understanding.
What the data looks like in practice
We ran Calyntro against a large open-source repository — MongoDB’s public codebase — to see what the numbers actually show.
The result: 72.6% of files had a bus factor of 1. Nearly three quarters of the codebase carried by a single contributor.
This isn’t a failure of the MongoDB team. It’s a structural reality of how software evolves. Specialization happens naturally. People go deep on the parts they own. Over time, the knowledge concentrates — not because anyone planned it that way, but because that’s how complex systems and human teams interact.
What makes it a risk is when that concentration meets high churn. A file that only one person understands, that is actively being changed, in a module that is critical to your product — that is where the real exposure lies.
The question worth asking
If your most knowledgeable developer on payments, or authentication, or your data pipeline gave notice tomorrow — how long would it take your team to regain full operational confidence in that part of the system?
Days? Weeks? Longer?
Most engineering leaders I speak with pause when they hear this question. Then they name a module. Sometimes two.
That pause is the bus factor.
What visibility changes
Knowing where the concentration is doesn’t eliminate the risk — but it changes how you respond to it.
Instead of discovering the gap during a stressful handover, you can act before it becomes urgent: structured pairing on high-risk modules, documentation sprints, deliberate knowledge transfer as part of normal development — not as a crisis response.
The goal isn’t to eliminate specialization. Deep expertise is valuable. The goal is to make the invisible visible, so you can make informed decisions about where the exposure is acceptable and where it isn’t.
Calyntro is a self-hosted repository analytics platform that maps knowledge concentration, ownership history, and structural risk across your codebase. It’s currently in open beta — free to use, runs on your own infrastructure, and never sends your code anywhere.