In almost every grown system there is one person you ask. Not because they are the best, but because they are the only one who knows why the billing run runs twice and what happens if you do not let it.
The usual response is a staffing measure: share knowledge, document, build cover. It is well meant and rarely works, because it does not touch the cause. Knowledge does not accumulate because somebody hoards it. It accumulates because the system forces it.
This article describes which properties of a system create a knowledge monopoly, why the usual countermeasures fizzle out, and what works instead.
The bus factor is the measurement, not the problem
The bus factor is the number of people who would have to be unavailable for a project to stop. At one it gets uncomfortable.
What is useful about that number is that it can be measured. What is useless is treating it as a target: a team can raise the bus factor to two by having a second person change something in a module once a quarter. The number goes up, and in an emergency it helps nobody, because that person does not understand the system, they merely had access.
The more interesting question is the one behind it: why can only one person work here? That has technical answers, and technical answers can be fixed.
Five properties that force a monopoly
When I find an area where only one person has worked for two years, I almost always find at least three of the following five properties.
One: there is no way to try something safely. With no test environment, no tests and no way back, every change is an intervention on the living object. Anybody who has never done it will not touch it, and that is sensible. The monopoly comes out of justified caution.
Two: the behaviour exists only in somebody's head. Not how it works, that is in the code, but the intent: why this special case, why this order, why this one customer is different. That is the part reading does not replace.
Three: getting started takes too long. If a development environment takes three days, nobody will invest three days for a small change. The change goes to the person whose environment already runs.
Four: the failures are silent. Where a failure does not announce itself but produces a wrong number, somebody has to recognize that the number is wrong. That is the hardest kind of knowledge to transfer, and it does not come from documentation, it comes from observability.
Five: the area has no boundary. If a change to billing requires knowledge of shipping, pricing and the order process, nobody can learn the area without learning everything. That is the most expensive of the five and the only one that is genuinely architecture.
All five are properties of the system, not of the person. That is the reframing that matters: a knowledge monopoly is not a staffing topic, it is a symptom, and it disappears when the system changes.
What does not help
Three measures get decided regularly and produce effort without effect.
A documentation mandate. "By the end of the quarter the module is documented." The result is a document describing what the code already says and omitting the reasons, because those are obvious to the author. After six months it is out of date, and nobody notices, because nobody reads it.
Pair programming by decree. Two people at one screen work well when both have a task. As a knowledge transfer measure without a concrete change it becomes a demonstration, and the second person forgets it in two weeks, because they did nothing with it.
The knowledge transfer session. Two hours in which the person explains how it works. That is exactly the volume of information nobody retains, and it arrives in the wrong order: explanation before need.
What all three have in common is that they try to transfer knowledge without moving the work. Knowledge only stays where work happens with it.
What works: move the work
The effective measure is unspectacular and uncomfortable: the next real change in that area is made by somebody else. Not as an exercise, but as a task, with responsibility for the outcome.
The person with the knowledge is not the teacher here but the reviewer. They answer questions and read the change set, they do not type. That difference decides whether knowledge appears or a demonstration takes place.
For that to work, three things have to exist first, and they are exactly the first three points above.
- A way to try things. An environment with realistic data where a mistake costs nothing. Without it, every handover becomes a test of courage.
- A net of tests around the area being worked on. Not everywhere, there. It does not have to be much, it has to pin down the behaviour nobody can explain any more.
- A setup that takes half a day. That is often the cheapest of the three measures and the one left undone longest.
The fourth point, silent failures, gets handled by the same exercise: anybody working in an area for the first time notices immediately where they cannot see what is happening, and that is the best requirements list for observability there is.
How to check whether the knowledge actually moved across is covered in The handover day.
Drawing the boundary so somebody can learn the area
That leaves the fifth point, and it is the only one that genuinely requires architectural work. As long as a change to billing needs knowledge of four other areas, none of the measures above help.
What works here is not splitting into services but a boundary inside the system: a module with a clear interface that the rest does not see behind. That is more work than documentation and less than a rebuild, and it is the only measure with a lasting effect.
A practical test for whether the boundary is sufficient: can a new person make a change in this area without opening a file outside it? If yes, the area can be learned. If no, it cannot, however well documented it is.
To find out roughly where such boundaries already run in your own system, look at the version history: files regularly changed together belong together, even when they sit in different directories.
# Which files change together? A rough approximation, enough for the
# question of where a boundary would even be possible.
git log --since="2 years ago" --name-only --pretty=format:--- \
| awk '/^---/{c++} /\.php$/{print c, $0}' \
| sort -k2 | uniq -c | sort -rn | head -40What you have to write down about a system for an agent is the same thing a new colleague is missing: A coding agent in a legacy codebase.
Measuring who works where
So that this does not run on feeling, a measurement is worth taking that costs ten minutes and shows per area how many people have actually changed something there in the last two years.
for area in src/Billing src/Shipping src/Catalog src/Orders; do
echo -n "$area: "
git log --since="2 years ago" --pretty="%an" -- "$area" \
| sort -u | tr '\n' ' '
echo
doneThe list reads differently than expected. Regularly, an area everybody considers dangerous has a handful of names, and one nobody talks about has exactly one. That is where the risk sits, because it is not known.
Every area with a single name then needs a decision, and the third option is the one used least often: it is fine as it is.
When a monopoly is acceptable
Not every area needs two heads. Three cases where I leave it alone.
The area does not change any more. A module that has run unchanged for three years and bothers nobody does not need a second person. It needs a note saying nobody understands it any more, and a plan for the day it does have to change.
The area is going away. What gets replaced within a year does not get anybody trained on it. That is the same arithmetic as with a frozen legacy system: effort in a product on its way out.
The effort is out of proportion. An area somebody would need two months to learn and that gets touched once a year is cheaper bought in next time than held in-house.
In all three cases the decision is the same as everywhere in this topic: do not prevent, name it. A known monopoly with a note and a plan is a risk you take. An unknown one is a risk you suffer.
And if the person does leave before any of this has happened, the first week decides the cost: what to do then is covered in its own article. How an orderly handover works is on its own page.
This article belongs to a series about systems that already exist. The retrospective orders every article in it by situation.
