Three types of knowledge that retire when experts do.

Ask an NHS EFM professional what is lost when a thirty-year veteran retires, and almost everyone reaches for the same two words: historical knowledge.

“I think that knowledge that is lost is historic knowledge, that isn’t captured anywhere,” one Projects Manager told us. A Director of EFM was blunter: “at the moment, most of it’s lost.” A Programme Manager described “a lot of historical cultural innuendos about the way things are done at a local level, which is very difficult for somebody coming in new to that environment to pick up.”

An independent consultant called it “operational tacit knowledge” and described it as “a powerful thing, because you understand the nuances, the genuine nuances about how things generate, how they really work.”

The trouble is that “historical knowledge” is not a category you can design for. Any knowledge generated in the past is historical. It is a feeling, not a specification.

So we kept probing. A Knowledge Specialist framed the real question: “what do we need to package up, so that, if we do need to pick it up and carry on with it further down the line, then we’ve got some history and some corporate memory?”

Three distinct answers emerged. They are not variations of the same thing. They fail differently, they hurt differently, and they each need to be addressed directly.

Knowledge Type 1: The rationale — Knowing the “why”

Outcomes leave a trace. Reasoning does not. A contract exists. A valve was not replaced. A system was configured a particular way. What is almost never recorded though is why.

An independent consultant identified the gap precisely: “often you’ll know the output, but you won’t always know the thought process. And sometimes, actually understanding the thought process is important.”

Derogations from standard operating procedures make this concrete. A Director of EFM explained: “What you should do is fix the valve. And if you don’t, then future management will think: ‘Oh, he was lazy. It was too much hard work. He didn’t want to do it.’ And that might not be the case. And if it’s not the case, you would really want to document why you didn’t do it.”

That example carries more weight than it first appears. A future colleague inheriting an unfixed valve has two options: assume there was a good reason and leave it, or assume there was not and change it. Both are guesses. Both can be wrong. As a Projects Manager put it: “you need the history behind it to be able to diagnose the problem.”

The same logic scales to strategic decisions. A consultant used outsourcing as an example: “you can see that the decision was to outsource, because you’ve got an outsourced contract. What you can’t always see is, why did we go through that process? What was the decision-making? What was important?” Without that, revisiting the decision means starting from zero and potentially making mistakes.

This is not a retrospective concern. It is a forward-looking one, and it becomes more urgent the more the organisation restructures. Every reorganisation re-opens decisions whose reasoning has already left the building.

The awareness is there. A Head of Capital Projects noted: “There’s a much greater onus on us now to become better at capturing the rationale behind the decisions we make.” A consultant stated the requirement in one line: “You want to be able to go into the records and retrieve the historic decision making.” Another summarised the payoff even more simply: “If you can explain the why, it helps everybody.”

But the practice lags well behind the intent. As one Director of EFM admitted, “we’re still not great at registering derogations,” with a warning attached: “if all of the people that were around the table when they made that decision leave, in the future, if something happens, they’re going to start complaining.”

Knowledge Type 2: The speed — “Knowing where the valve is”

The second knowledge type surprised us, because strictly speaking it is not lost at all. Much of what feels like lost knowledge is documented somewhere in the organisation. The drawing exists. The manual exists. What leaves with the retiring engineer is not the information but the speed at which it can be reached.

A Director of EFM described the mechanism: “I think people, as they go through their job, you build up that knowledge of where everything is, how to access data easily and how to then assimilate that. And you lose all of that when somebody moves on.”

An independent consultant explained why that speed is worth protecting: “You can’t also underestimate the value of the people-based work streams or channels. You know they’re fast. People will think about the problem there and then, especially in the crises.”

In an emergency, the difference is stark. A consultant with 42 years in the sector gave the clearest illustration: “If you have a disaster, they’ll know where the valve is with water. They’ll know where the isolating valve is that needs to be shut off to stop this flood.”

A Director of EFM drew the same contrast in terms of pure elapsed time: “If somebody wants to know where you isolate the oxygen for a particular ward or whatever, the person that’s been there for sort of 10, 20, 30 years has probably worked on it in the past and has that information,” whereas “it just takes more time and more effort to go on the shared drive, find the drawing and trace the pipe, find the valve.”

Every lookup carries a time penalty against having the answer already in your head. In a water leak, a power outage, or a fire, that penalty is not administrative friction. It is a clinical variable.

This reframes the problem usefully. For this type of knowledge, the answer is not more documentation. The organisation already has the documents. The answer is retrieval fast enough to compete with asking the person who has been there thirty years — because if it is slower, staff will keep asking the person, and the dependency never breaks.

Knowledge Type 3: The relationships — Knowing “who”

The third knowledge type is arguably the least surprising, but likely the hardest to capture. An Assistant Director of Innovation captured its dual nature in a single sentence: “It’s who to speak to and how to do it. I think they’re kind of big factors.”

An independent consultant described experienced colleagues as people who “are going to know the people to talk to […] the people to make things happen,” while a Knowledge Specialist called it “tacit knowledge that are in people’s heads in terms of who they know and who they speak to and who their go to people are.”

Crucially, this is not a contact list. Another Knowledge Specialist described knowing “who’s more open to help with various projects, and who might not be quite as open, but might have some expertise”. A distinction between willingness and capability that appears on no organisational chart.

A Project Director explained why that matters so much in hospitals specifically: “Hospitals are complex places. They rely a lot on hierarchy and unofficial hierarchy as well, in terms of wanting to get things done. So those relationships that get lost when someone leaves the organisation.”

Teams do try. An HR Specialist described compiling “key contacts. The movers and shakers,” and valued the list left behind by a predecessor as “really useful.” But a name is a thin approximation of what was actually known. It carries none of the annotations: who is an ally, who needs a particular approach, who is better reached informally?

And even where the names transfer, the relationship does not. A Procurement Specialist noted: “you can’t necessarily build that same relationship back depending on the rapport that the person had with the client.” A Knowledge Specialist reflected on a colleague’s departure: “some of it was tied to the person and her relationships and her personality.”

The same applies inside the team. A Director of EFM described how experienced managers “build up that relationship with staff. […] They know how to get the best out of their staff,” knowledge entirely invisible to whoever replaces them.

There is also an honest limit here, and it deserves stating plainly. Asked about passing on candid assessments of colleagues, an Assistant Director of Innovation replied: “it’s quite hard to be truthful […] because there’s a cost associated with hurting somebody’s feelings.” Some relational knowledge is not merely undocumented. It is subjective, socially costly, and arguably should not sit in a central repository at all.

That is a design constraint, not a reason to give up. Some know-who can be captured. Some of it cannot. Knowing the difference is the work.

Why the distinction matters

Lumping these three knowledge types together under “historical knowledge” is why so many knowledge management initiatives disappoint. They are three different problems wearing the same coat.

Decision rationale is lost at the moment it is created, because nobody writes down the why. It needs to be captured in the flow of work, when the decision is made, not reconstructed at an exit interview years later, when, as one Projects Manager warned, “they aren’t even going to remember that knowledge, are they? It’s probably too late.”

Access speed is not a documentation problem at all. It is a retrieval problem, and throwing more documents at it makes it worse.

Know-who is partly capturable, partly relational capital that has to be rebuilt rather than transferred, and partly information that carries ethical weight. It needs structure and guardrails in equal measure.

A single system that treats all three as one problem will fail all three. Which is precisely why the first step is naming them separately.

In the next post, we turn to the harder question: given that everyone we interviewed was aware of the challenge, why is so little knowledge being captured? The answer runs through five interconnected barriers that must be overcome.

At CompliMind, we are building against exactly this distinction — connecting people, knowledge, and systems so critical insights reach the right hands at the right time. Because the why, the where, and the who each need their own answer.

Want to dig into the details? Read pages 41–44 in the full thesis here.