Every business I talk to has one. Sometimes two. The person who knows how the thing actually works — not how it is supposed to work, not how the process document describes it (if there is a process document), but how it works. The workarounds. The exceptions. The three suppliers who need to be called in a specific order. The way the system sometimes drops a line item and what to check when it does. The undocumented logic that holds the operation together.
I have started calling this person the load-bearing wall. The renovation looks fine until you start knocking things through.
In the course of conversations with business owners, I have noticed that this person is almost always identifiable within thirty seconds of asking: “Is there anyone in your business whose absence for two weeks would create genuine disruption?” The answer is rarely “no.” And the hesitation before the answer is itself revealing — the business owner knows exactly who it is, and the brief pause is the moment they acknowledge, perhaps for the first time in a while, that this is a risk they are carrying.
Let me describe a composite archetype that I have encountered in enough variations to be confident it is a real pattern.
His name, for the purposes of this article, is David.
David has been at the company for seven years. He started in the accounts function, moved across to operations when the business was expanding, and in the process became the person who understood both sides: the financial implications of operational decisions and the operational implications of financial ones. No one planned for David to become indispensable. It just happened, in the way that things happen in businesses that grow faster than their processes — someone fills the gaps, and filling the gaps becomes their job.
David knows which clients have non-standard billing arrangements and why. He knows what the month-end process actually involves, as opposed to what the finance manual says it involves (the finance manual has not been updated since 2019). He manages three supplier relationships that involve personal contact at the account level — relationships that exist because of David, not because of the business. When the project management software was upgraded last autumn and three months of historical data came in corrupted, David fixed it over a weekend because he was the only person who understood the export format well enough to reconstruct it.
David is also, it should be said, tired. Not resentful. Tired. The weight of being the person everyone leans on is a real weight. He has asked twice whether the business could document some of his processes. Both times, the conversation has trailed off into busy-ness.
The risk that David represents is threefold.
The first is his holiday. When David is off for two weeks in August, the business copes — just. There are workarounds. Some things wait. Some things are handled imperfectly. The annual cost of this is not zero, but it is absorbed. Nobody explicitly calculates what two weeks of suboptimal operations costs because the cost is distributed across enough people and enough tasks that no single item is large enough to demand attention.
The second is the business’s growth constraint. Businesses with a David are often making decisions — about new clients, about capacity, about what they can take on — with David as an implicit limit. “We could probably take that on, but it would really pile the pressure on David.” This is not a cynical or unreasonable position. It is a sensible, well-intentioned recognition of a real constraint. But the constraint is not David. The constraint is the concentration of operational knowledge in David. Those are different problems with different solutions.
The third is his departure. David is good. The kind of businesses David works in are not the only ones that want someone with his particular blend of operational and financial understanding. If David leaves, the business faces what I would describe as a knowledge cliff: an abrupt drop in operational capability that is almost impossible to communicate to a recruiter or price into a job advertisement. “Must understand our specific billing exceptions and know how to talk to Gary at the transport supplier” does not appear in job specifications. It shows up in the first three months of whoever replaces David, during which the business discovers, methodically, all the things David knew.
The industry benchmark for time-to-competence in a replacement for a multi-domain role of David’s type — based on comparable business service contexts — is typically four to seven months before the replacement is performing at the predecessor’s level. The cost during that period is not just the recruitment fee. It is the distributed operational inefficiency of a team missing a critical connective node.
The fix, when I describe it to business owners, often prompts a reaction of recognition followed by mild embarrassment that it has not been done already.
It is not complicated. It does not require David to spend three weeks writing a manual. It requires, in essence, that the work David does is observed, recorded, and translated into pathways. What does David do when a non-standard billing query arrives? What are the steps? Where does it depend on David’s specific knowledge, and where does it follow a pattern that could be written down? Where is the line between the objective part of David’s job — the part that follows a pathway — and the subjective part, where David’s seven years of context and relationships are genuinely irreplaceable?
When that line is drawn, the objective parts can be documented. They can be handled, with the right support, by someone other than David. The subjective parts stay with David — but they are smaller than people expect, and they are clearly defined. David is no longer the load-bearing wall. He is a structural expert who has been asked to do structural work instead of holding up the ceiling.
For David, this is usually a relief rather than a threat. Being indispensable because you know things nobody else knows is not a comfortable position. It means you cannot properly hand over when you are on holiday. It means you are the person who gets called when the system drops a line item on a Sunday. It means that the value you add is trapped in your continued presence, which is not the same as your contribution being valued.
For the business, the change is a risk reduction that is worth quantifying. A 30-person professional services firm with one clearly identifiable key-person dependency might be carrying £60,000 to £120,000 of implicit insurance liability — the cost of one departure and the operational disruption of finding, hiring, and bringing up to speed a replacement while the rest of the team covers the gap. That is not a number from a specific engagement. It is a reasonable benchmark drawn from the components: recruitment fees, reduced productivity during the gap, and the time cost of the knowledge reconstruction that follows.
Process mapping and knowledge capture are not glamorous. They do not have the appeal of a new system or a strategic pivot. They are, essentially, the work of making implicit knowledge explicit — of taking the things that live in a person’s head and putting them somewhere more resilient.
But the effect is structural. A business where the operational knowledge is in the system rather than exclusively in the people is a fundamentally different kind of business. It can grow without David as the limiting constraint. It can survive David’s holiday without workarounds. It can, if the time comes, replace David’s operational role without a knowledge cliff.
This is protective work, not corrective. There is no crisis requiring it right now. That, in my experience, is exactly why it keeps not happening.
Most businesses know who their David is. The question is not whether to address this. It is whether to address it before or after the moment when you find out what the cost is.