Every team we work with has one. The person who knows why the payment service retries three times and not five, which service you don’t deploy on a Friday and the real reason why, what that flag with the unhelpful name actually switches on. None of it is written down anywhere the company owns. It is in their head. At some point they will hand in their notice, and it goes with them.
The half that was never checked in
The code is the easy part. It is in version control, it is searchable, and it runs. What isn’t checked in is the reasoning around it: why the system is shaped like this, which decisions were deliberate and which were accidents that hardened into behavior other things now depend on, what breaks if you touch the wrong file. That is the operating knowledge of your system, and almost none of it was ever written down. It got learned, one incident at a time, by people.
Which is why onboarding onto an old system takes weeks. The code isn’t unreadable. The context is missing, and the only copy of it is a person with a calendar.
Pick your two most senior engineers. If both resigned this month, what leaves the building with them? For most teams it is most of what makes the system safe to change. Bus factor gets talked about as a joke. It is a liability that never appears on any register.
What it costs to keep knowledge in people
When the only copy of something critical lives in someone’s head, every transfer of it costs their time. A new joiner’s questions arrive as interrupts on your most expensive engineers. A 2 a.m. incident routes to whoever remembers how the thing really works, regardless of who is nominally on call. Writing it all down would help, except that writing it down is unrewarded work with no deadline attached, so it loses to whatever ships this month. The knowledge stays where it is and the dependency gets deeper.
There is a second cost that we think gets badly underrated. This arrangement wears down the people it depends on. Being the human documentation is a bad job. So is doing routine work by hand because nobody has gotten around to automating it. The engineers you would least like to lose are the ones with the most options elsewhere, and the concentration of knowledge you are relying on for stability is part of what makes them start looking.
“Every team has a person they can’t afford to lose. That isn’t resilience. It’s a single point of failure with a salary.”
Make the system answerable instead of the person
The fix isn’t a better note-taking culture. We have watched enough documentation initiatives start well and quietly stop by March to stop believing in that one. What we went after instead was making the codebase itself something you can question: a model derived from the code that holds what is there, how it connects, and what changed over time.
Once that exists, the shape of the problem changes. A new joiner queries the model on day one rather than booking half an hour with the one person who remembers. An incident responder asks the system how a service behaves instead of paging the engineer who wrote it four years ago. And that engineer gets their afternoons back, because most of the questions people used to extract from them are now answerable without them.
A new joiner interrogates the model directly instead of spending weeks borrowing senior time in half-hour blocks.
What the org understands about its own systems is held by the org, not by whoever happens to still be here.
Bus factor turns into a scheduling problem. Uncomfortable, survivable, no longer existential.
They stop being the reference manual and go back to the work that made them senior in the first place.
People leave. That is fine, and a company built on preventing it has a worse problem than the one it started with. The only variable you actually control is how much leaves with them. Worth deciding before the notice lands rather than during the handover, when the clock is already running.