When the Last Expert Leaves
Posted on July 20, 2026 • 6 min read • 1,156 wordsA critical system nobody understands anymore, a departure that takes years of knowledge with it: a team's memory is invisible technical debt. How to preserve it and pass it on before it's too late.
In almost every organization there is a system people talk about in hushed tones. It has been running for ten years, it is critical, and exactly one person truly knows how it works. The day that person leaves — retirement, resignation, transfer — it isn’t just a colleague walking out: it’s an entire library closing down without ever having been copied. That lost knowledge is a form of technical debt, the most insidious of all, because it shows up on no dashboard.
I. The day the last expert walks away
A team’s fragility is often measured by one brutal question: the bus factor. How many people would have to “disappear” for a project to grind to a halt? When the answer is “just one,” you are sitting on a powder keg.
The scenario is always the same. The system works, so nobody worries about it. The expert answers the questions, fixes the incidents, knows every trap by heart. As long as they are around, everything is fine — and that is precisely what lulls the organization to sleep. The risk stays invisible until the day of the departure, when you discover, too late, everything that only ever existed inside a single head.
II. Technical debt isn’t only a code problem
Technical debt is too often reduced to bad code: shortcuts, patches, missing tests. But there is a debt far harder to repay: knowledge debt.
Code can be clean and still be incomprehensible, because the why behind its choices was never written down anywhere. Why is this parameter set to that exact value? Why this odd workaround right here? The answer exists — in someone’s memory. The day that memory fades, the code becomes a text in a dead language: readable letter by letter, but with its meaning gone.
Chesterton’s fence: never tear down a fence before you understand why it was put up. Without the team’s memory, every line of code becomes a fence whose reason nobody knows.
III. Write down what you know, pass on what you sense
Faced with that risk, the first instinct is the right one: document. And let’s say it plainly — the written word is what remains when people leave. A recorded decision, a tested procedure, an up-to-date diagram keep speaking years after their author. Writing can be read at any hour, by anyone, without taking up anyone’s time. It is the bedrock of a team’s memory, and nothing replaces it. An organization that doesn’t document its decisions condemns itself to rediscovering them.
But writing has a limit you need to know about, so you don’t rely on it blindly. Part of an expert’s knowledge is explicit: it can be put on paper, and it should be. Another part is tacit — the intuitions, the reflexes, the “this smells wrong” when a symptom shows up, the mental map of hidden dependencies. That part resists documentation, not out of negligence, but because the person who holds it often doesn’t even know they hold it. You don’t document what you don’t know you know.
That kind of knowledge is passed on through contact: by working side by side, by watching the expert diagnose a problem, by hearing them think out loud. That is where the essential part — everything no wiki will ever retain — actually changes hands.
So the right strategy isn’t to choose between the two, but to combine them: write down everything that can be written — decisions, procedures, constraints — and pass on the rest through shared work. Writing ensures continuity; contact ensures understanding.
IV. The symptoms of a fading memory
An organization losing its memory gives off signs before the accident. Learn to recognize them:
- “We don’t touch that.” A module nobody dares modify anymore is a module whose knowledge has already walked out.
- Fear when incidents hit. When an outage triggers panic rather than a procedure, the knowledge isn’t shared.
- Cargo cult. People repeat gestures without understanding why — “we’ve always done it this way” — because the original reason has disappeared.
- A single person copied on every critical message. The mandatory checkpoint is also the breaking point.
Each of these symptoms is a warning: memory is concentrating instead of spreading.
V. Pass it on before it’s too late
The good news: knowledge debt can be repaid, provided you start before the departure, not after. A few proven practices:
- Document decisions, not just code. An ADR (Architecture Decision Record) captures the why behind a choice — the context, the alternatives rejected, the consequences. It’s the missing link the code never gives you.
- Work in pairs. Pair programming and mob programming spread tacit knowledge in real time: two heads share what no document captures.
- Rotate roles. Regular rotation on critical systems turns a bus factor of 1 into 3 or 4, at almost no extra effort.
- Write living runbooks. An incident procedure, tested and kept up to date, replaces panic with sure moves — available to everyone, not to the expert alone.
- Take onboarding seriously. The best documentation is the one a newcomer actually uses. Have them shadow a real incident, walk through the code with a veteran, and ask every “dumb” question they have.
VI. Make knowledge sharing a culture, not an event
The classic mistake is to treat knowledge transfer as a last-minute operation: three weeks of “handover” before someone leaves. That’s an illusion — you don’t transfer ten years of expertise in a month.
Transfer isn’t an event, it’s a habit. It plays out every day, in a thousand small gestures: a decision written down rather than kept in someone’s head, a coding session shared rather than a fix made alone, a question encouraged rather than brushed aside. A team that transfers knowledge continuously no longer fears anyone’s departure, because its memory doesn’t live in one head, but in its practices.
It is also a management choice: value the people who document and teach as much as the one who “saves the day” single-handedly. As long as individual heroism is rewarded more than sharing, memory will keep concentrating exactly where it is most fragile.
Conclusion
The departure of the last expert is never really a surprise: it is the culmination of a thousand missed chances to pass knowledge on. A team’s memory is an asset as valuable as its code — and far harder to rebuild. Preserving it takes no magic tool, only a conviction: knowledge that doesn’t circulate is a debt that grows in silence.
The true robustness of an organization isn’t measured by what its best person knows, but by what would survive their departure. Start today: write down the why behind a decision, share a session, ask a question. That is how you keep a library from burning.