Every maintenance department with a few years of history has that person. The one who knows by heart why a certain electrical panel occasionally throws a false alarm, which spare part must always be kept in stock even though the manual doesn’t call for it, how to work around a problem no one else even knows how to recognize. For years they’ve been the department’s most valuable resource. They are also, almost always without anyone noticing, the most fragile point in the whole organization.
The problem: tribal knowledge
That’s what it’s called, “tribal knowledge”: everything a maintenance team learns on the job, over years of interventions, that never ends up in a document — because no one had time to write it down, or because it seemed too obvious to be worth a note. It isn’t negligence. It’s the natural way experience accumulates when day-to-day work leaves little room to stop and document what was just learned.
The problem isn’t that this knowledge exists only in someone’s head. The problem is that, over time, an entire department starts depending on that head without realizing it.
Why it’s convenient to leave it that way
No manager consciously decides to rely on a single point of failure. It happens through accumulation, and it’s convenient to let it happen: asking the right person is faster than digging through a procedure that may not even exist. Whoever holds that knowledge, for their part, often has no real incentive to share it fully — not out of malice, but because being indispensable is, humanly, gratifying. And writing a procedure takes time that, under the daily pressure of the unexpected, always seems less urgent than everything else.
So the risk grows silently, one year at a time, with no metric ever flagging it. It doesn’t show up in any maintenance KPI.
The moment the risk becomes real
The risk doesn’t show up gradually: it shows up all at once, usually at the worst possible moment. A sudden illness, a retirement that came sooner than expected, a resignation no one saw coming — and the department is faced with a breakdown that person would have solved in twenty minutes, while the rest of the team starts from zero, not even knowing where to begin looking.
It’s not a theoretical risk. It’s one of the most common ways a breakdown that could have lasted an hour ends up lasting a whole day — not because the technical problem was more complex, but because the one person who would have known how to handle it quickly simply wasn’t there that day.
The real hidden cost
The most visible cost is the time lost during the emergency. But there’s a deeper cost: all the small decisions that person made every day, the trade-offs between different solutions, the “why we do it this way” that was never questioned because it was obvious to whoever had chosen it — those decisions disappear with them. Whoever is left doesn’t just inherit a technical problem to solve: they inherit years of silent choices that no one can explain anymore, and that they have to rebuild from scratch, often repeating the same mistakes that person had already overcome years before.
How a manager needs to handle it
It isn’t solved by asking someone to “write down everything they know” over a weekend. It takes an ongoing process, not a one-off project.
- Pair up, don’t just assign. Systematically have the expert and at least one younger colleague work together on critical jobs — not as occasional training, but as a recurring practice on every key asset.
- Document the “why,” not just the “what.” A checklist says what to do. The real value is in the why: why that spare part has to be kept in stock, why that threshold and not another. That’s the part that usually gets lost, and the part you actually need in an emergency.
- Make sharing a merit, not a personal risk. If sharing their knowledge makes someone feel less indispensable — and therefore less secure in their role — they’ll never do it fully. It has to be made clear, through actions before words, that the person who trains others gains value, not loses it.
- Start with the most critical assets, not everything at once. Map out where the risk of depending on a single person is highest — the most delicate system, the oldest machine, the one with the least documentation — and start there, instead of trying to codify everything at the same time.
This is never really finished work. It’s a discipline that has to be kept up over time, the same way a system is maintained: not waiting for the breakdown to realize that it needed maintenance there too.
In summary
The person who knows everything by heart is a real asset, but also the sign of a risk the rest of the organization has let grow without noticing. The cost of this risk doesn’t show up in everyday numbers — it shows up only when that person, for one reason or another, is no longer there. A manager who tackles this problem before it becomes an emergency doesn’t take value away from the person who built up that knowledge: they protect it, along with the whole team, from the moment that value would risk being lost for good.