Key person risk: why processes depend on single people in manufacturing
The continuity of company processes depends on specific employees because it’s these people, not the organization as a whole, who hold the knowledge that runs those processes. That’s no accident. A large part of what people know is tribal knowledge: know-how that builds up over years of experience rather than coming from training or a written instruction. The process engineer who knows the quirks of an old press has it. So does the maintenance technician who’s the only one able to diagnose an aging controller.
Without deliberate effort, the information that gathers in employees’ heads never gets recorded anywhere outside of them. And so a process that formally belongs to the organization can’t, in practice, run without one person. For business continuity, that’s a flashpoint — and it shows up in different ways.
In one manufacturing company we talked to, the production schedule had been built by the same person for years. The plan stayed workable because the planner kept rules in their head that nobody had written down. They knew which orders to combine into a single run to limit changeovers, what each line’s output was, and which customers would tolerate a delay. When the planner wasn’t around, someone else built the plan — and in every non-obvious case, something started to go wrong.
At almost every workshop that kicks off a new engagement, we meet another face of the same problem: an Excel file the company runs one of its processes on. Day to day, different people across the company use the file: they know where to enter data and what each column means. The trouble starts when something in the sheet needs to change — a formula breaks, or an exception comes up that the file doesn’t handle. That’s when it turns out that only the author knows the logic the tool runs on.
This dependence has a name: key person risk. In food production, especially fresh food, that risk gets particularly expensive. Raw material has a shelf life, so a process halted by someone’s sudden absence can mean a lost batch or a delivery that doesn’t ship on time. And when the person leaves for good, those losses stop being one-offs — because the person who used to prevent them is often impossible to replace.
In Cedefop’s EU-wide skills forecast to 2035, more than 90% of all job openings come from replacement needs: filling posts left by people who retire or move on, not newly created jobs. Those posts are hard to fill. In ManpowerGroup’s 2026 Talent Shortage survey of 39,000 employers across 41 countries, 72% report difficulty finding the people they need — manufacturing sits exactly at that average, and in Germany the figure reaches 83%. And the wave is only building: per Eurostat data, nearly one in five employed adults in the EU is aged 55 to 64 — 39 million people at or approaching retirement.
Turnover, a shrinking labor market, a wave of retirements — the problem is coming from several directions at once, and sooner or later it will reach even the plants that handle knowledge management well today. Many companies react on reflex: employees get told to write down what they know. And that’s exactly where the next problem starts.
Is writing down procedures enough to protect knowledge?
Writing knowledge down doesn’t protect it by itself. Whether documentation protects the company isn’t decided by the fact that it exists, but by what’s in it and whether anyone uses it. A written record works when it’s part of daily work: someone opens it because it serves a purpose, and someone updates it when the process changes. A document or a knowledge base alone guarantees neither.
The “let’s write everything down” reflex has an understandable source. A company that’s noticed its processes depend on one person wants to keep that person’s knowledge, so it orders a write-up. A few weeks later it has a binder of procedures or a folder of instructions — and with it a sense of control, of risk handled. The problem is that this sense rarely has any backing in reality, and the company only finds out when a crisis hits. It happens because of the very nature of human knowledge, not because someone was negligent.
First, every record is created in someone’s context — and whoever reaches for it later doesn’t have that context. As long as the author is in the company, the gap may not even be visible: whatever the document doesn’t say, people simply ask about. The real test comes after they leave. That’s when it comes to light how much the record is missing — and how often the answer to questions was simply the author.
Second, even when someone genuinely wants to write down their knowledge accurately, in a way a person without context can follow, they rarely manage it. After years on the job, an expert stops seeing what’s non-obvious in their work — the steps they perform automatically, the exceptions they recognize without thinking. They feel so obvious the expert skips them without realizing. It’s a cognitive bias called the curse of knowledge (Camerer, Loewenstein, Weber, 1989). The better we know something, the harder it is to reconstruct what it’s like not to know it. That doesn’t mean the knowledge can’t be extracted. But it rarely works solo, from an instruction to “write down what you know.”
Third, some knowledge can’t be captured in any material form at all. What the process engineer knows about the old press can partly be put into words — but their sense that the machine is running wrong before any measurement shows it can’t. The same goes for a planner’s call in an unusual situation, when they have to weigh order urgency, machine condition, and customer attitudes all at once. Individual rules can be written down, but not the judgment itself, because it can play out differently under every set of conditions. This kind of knowledge isn’t preserved on paper — it develops when an experienced employee passes it on to a successor.
These three reasons don’t rule out writing things down, but they do set its limits. Since you can’t capture everything, and a document’s mere existence guarantees nothing, protecting knowledge should start with a decision about which knowledge to protect.
Which employee knowledge should you protect first?
Two factors decide which operational knowledge to protect first: what losing it would cost, and how urgent it is to secure it.
Start with the cost of loss. It’s easy to assume this means knowledge whose absence stops production right away. Some gaps do work like that: no planner, no person for a specific machine, and the process stops. But not all consequences show up immediately. A missing piece of knowledge may stop nothing today and hit with a delay instead — at the next audit, for example, or as a problem that built up for a long time and became hard to reverse.
The second factor is urgency: the time left before the person with that knowledge is gone. Urgency decides whether you secure the knowledge on your own terms or under crisis pressure. You can see retirement coming well in advance, so there’s time to plan the handover of the role. A notice period gives you three months at most. Sudden absence carries the biggest risk, because it leaves no window to prepare at all.
It helps to lay both factors out on a matrix: cost of loss on one axis, urgency on the other. Every area of knowledge lands in one of four quadrants, and the priority is the one where both are high — the loss costs a lot, and there’s little time left to react. That’s where you start.
This tells you which knowledge matters most to secure. What’s left is to actually keep it — and how you do that depends on what that knowledge is.
Two kinds of knowledge in employees’ heads — and different ways to keep each
The knowledge employees carry in their heads isn’t uniform. It falls into two types: explicit and tacit. Which one you’re dealing with determines how to capture it, make it available across the organization, and get it used day to day.
How do you capture explicit knowledge?
Explicit knowledge is the kind that can be expressed in words or numbers and recorded in a form someone else can use. There’s plenty of it around a plant — from the shop floor to the office:
- machine settings and changeover parameters
- line cleaning procedures: concentrations, temperatures, times
- quality control settings on the metal detector, weight limits
- recipes and product specifications
- the logic of the spreadsheet a plan or report runs on
- the batch numbering scheme and its recall path
The right format depends on how often the knowledge is needed and how much rides on applying it correctly. Knowledge needed once in a while is fine as an instruction in an openly accessible, searchable knowledge base. For repetitive tasks, where it’s easy to skip a step in the rush, a checklist at the workstation works better.
A simple record can also do more than its form suggests. Robert Grelowski of JPB System, an aerospace parts manufacturer, describes shift handover notebooks that have worked there for years. Operators write down the problems they ran into and how they solved them. He himself admits the solution is “a bit contrary to digitalization” — and yet those notebooks pass knowledge about faults and fixes from one shift to the next.
Sometimes, though, it pays to go further and build the knowledge directly into the tool the team works in. In production planning, the planner’s rules — combining orders around changeovers, sequencing products with allergens, each line’s capacity — then stop being their private knowledge. Someone else can build the plan, and the tool won’t let them put allergens in the wrong order or schedule more onto a line than it can produce. The next step is automation, where the tool can propose a schedule itself, and the planner verifies it and resolves the exceptions.
How do you keep tacit knowledge?
Tacit knowledge is feel and judgment: what an experienced employee recognizes by hand, eye, or ear, and how they resolve situations no rule covers. A cheesemaker knows by the touch of the curd that it’s ready to cut, and a maintenance technician facing an unusual breakdown knows where to look first, even though the manual doesn’t cover the case. No form of written record passes this knowledge on in full — it transfers only through working together.
How you organize that shared work depends on how much time there is to pass the knowledge on and how many people need to learn it. When the departure date is known, succession planning with a period of overlapping roles works well. Without a set date, you’re left with mentoring aimed at judgment — the same knowledge passes to a second person gradually, in daily work.
Both forms, though, pass knowledge to only one person. When its loss costs a lot, companies reach for cross-training: employees learn each other’s stations, so several people can do the same work and one departure leaves no gap.
An employee working their notice: what you can save in four weeks
Treat the notice period as a time budget for a knowledge transfer plan, not a countdown in which the departing person writes down whatever they manage to.
Always start with a conversation with the person leaving — what the expert would skip as obvious comes out when a second person asks questions. That second person doesn’t have to be the successor, who at this stage often doesn’t exist yet. The conversation can be led by a manager or by someone on the team who’ll work closest with that knowledge. The point is to map what the departing person knows, not to capture it right away. Rather than asking about knowledge directly, you look for the traces it leaves in daily work — in incidents, in routine, and in tools. It’s these traces that lead to the knowledge the departing person wouldn’t have listed on their own.
Three areas are worth walking through with the person leaving:
- The absence test. What ground to a halt the last time they were on vacation? Who called them, and about what? Incidents show the truth about dependencies that are harder to spot day to day.
- The week review. What do they do regularly that nobody else does? A job description misses many of the specifics, so after they leave, nobody will know those tasks are there to take over.
- The artifact review. Which files, spreadsheets, and settings depend on them alone? Some only they have, though the process needs them; others the whole team uses, but nobody besides the author can fix or change them.
You filter that list through the cost-of-loss and urgency matrix. When there are only a few weeks left to save the knowledge, urgency is settled up front — only the consequences of loss set the priorities now. Not everything that comes up in the conversation weighs the same: losing some of it will stop a process, losing other parts won’t have much consequence.
Four weeks won’t be enough for everything: you can save some knowledge in that time, but some you have to consciously let go. What can’t be saved needs to be named and entered into the risk register. An honest, visible loss is cheaper than an illusion of completeness, because you can prepare for a named risk — not for a hidden one.
The next conversations take one item at a time from the filtered list and go deep. Their goal is to discover how the departing person thinks when they make decisions. For this, you use the incident-based interview — a method developed in research on the decisions of fireground commanders and paramedics. The departing person walks through one specific case from start to finish, and the interviewer then goes back to the decision points and asks about:
- Cues — for example, how did they know it was time to act before any measurement showed it?
- Rejected options — for example, what else could they have done at that moment, and why didn’t they?
- The novice mistake — for example, what would someone new have done there, and what could have gone wrong because of it?
Talking about incidents has a practical advantage too: a departing employee’s motivation is usually low, and telling the story of a specific case is easier than writing documentation.
Once you’ve extracted the knowledge, what’s left is choosing how to keep it. Parameters, contacts, file locations, or the logic of a spreadsheet can be written down. Judgment takes years to build; in a few weeks you can only start developing it. That start happens in the successor — or, until there is one, in whoever temporarily takes over the duties. Ideally, the departing person and the one taking over start working together right away, even part-time. Judgment develops in action — solving current problems together, working in parallel, going over a just-finished task and asking why it was done this way and not another. In Peter Massingham’s multi-year study of knowledge transfer, forms like these were rated highest, while document repositories without context scored lowest.
What if the employee is already gone?
In that case, you start with a review of what’s left: spreadsheets, files, the process mailbox. Better not to change anything in them until you know how they work. An inherited spreadsheet without its author is a black box, and changing one formula can break it without anyone noticing. The second step is a conversation with the team, who may be able to help reconstruct the missing knowledge. What exactly is missing usually becomes clear only in practice: with a question nobody is left to answer, or a task nobody took over. Every such gap should go into the risk register.
Knowledge retention is a process, not a one-off project
Knowledge retention doesn’t end once you’ve saved what was at risk. Processes change, people rotate, and the risk areas shift with them. Even a carefully done selection stops describing the company after a while. That’s why it should run as a repeated review. In its simplest version, a skills matrix is enough: a plain table of who can do what and how well, where you can see at a glance where a process still depends on one person.
That review can be a quarterly meeting, or one held after every major process change or departure. We work the same way ourselves. Polaris, our internal quality standard for projects, doubles as a repository of knowledge about how we build software. To keep it in step with how we actually work, the team reviews the standard every six months with the question “what works, what doesn’t, what’s changed” — and updates it.
See Polaris from the inside
In a free ebook, we describe the whole standard, how we work with it, and how we keep it current. Download the ebook here.
At that rhythm, protecting knowledge stops being firefighting. It starts working like machine inspections in maintenance: routine, before anything goes wrong.
From debt to asset
Knowledge security isn’t measured by the size of your documentation, but by the number of places where a process still depends on a single person. So the goal isn’t to write everything down — it’s to make sure no single departure can stop the company. The rest of the knowledge can stay in people’s heads, as long as it has a name in the risk register. Then it stops being a surprise and becomes a decision.
An approach that combines writing knowledge down with passing it between people turns it from a debt into an asset. A process that in practice belonged to one person returns to the organization. The knowledge that no record or tool can take over stays in the company through a culture of passing it on: practices built into daily work, like onboarding every new person with an assigned mentor, learning each other’s stations, or promoting from within into key roles. The expert gains too: they stop being hostage to their own irreplaceability and get back the right to an ordinary absence.
You can do all of this work with your own resources. Sometimes, though, someone is leaving right now, has already left, or is approaching retirement — and you don’t know where to start. That’s a situation we can help with: together with your team, we’ll extract the knowledge that would cost the most to lose and leave it in a form ready for everyday use. Book a call and start turning debt into an asset.
