When our longest-tenured production scheduler retired, we gave him a cake, a card, and a send-off in the break room. Six weeks later we missed two ship dates in a row, and it took most of a quarter to work out that the schedule had been running on judgment he never wrote down. The fix is getting that judgment on paper while its owner is still in the building.
What counts as institutional knowledge?
Institutional knowledge is everything your operation depends on that lives only in someone's head: the workarounds, the judgment calls, the vendor quirks, and the reasons behind the settings. It's rarely the official procedure. It's the unwritten layer on top of the procedure, the part that makes the procedure work on the days when three things are slightly off.
Our scheduler knew that one customer's purchase orders always understated lead time by a week, that a certain machine drifted out of tolerance until it warmed up on humid days, and that the freight carrier's posted Friday cutoff really meant noon. None of it was in the system. The system said we were on time right up until we weren't.
I spent years as chief financial officer of a manufacturing company, and the month-end close taught me the same lesson from the office side. Our close calendar said three days. It was three days because our controller knew which report had to be re-run after the inventory posting, in what order, and what a normal variance looked like. The calendar documented the schedule. She was the schedule.
How do you know whose knowledge is at risk?
Ask one question about every process that matters: if this person were out for a month, could someone else run it from what's written down? Every no marks concentrated knowledge. Concentration is the risk, not age. A thirty-four-year-old who's the only person who can run the ERP export is the same exposure as a sixty-four-year-old with a retirement date on the calendar.
The audit itself is short. List the processes that would hurt if they stopped. Name the person each one depends on, which is often not the person who owns it on the org chart. Then compare what's written down against what that person does. The gap between those two is your risk map.
The mistake I've watched companies make is ranking the work by retirement date. Retirements at least announce themselves. Resignations don't, and neither do medical leaves. One company ranked its documentation projects by who was closest to sixty-five and lost its most irreplaceable knowledge to a competitor's job offer, accepted by a man of forty-one.
Vacations are a free diagnostic. Whatever broke, backed up, or waited two weeks the last time someone took real time off is telling you where to start.
How do you get knowledge out of an expert's head?
Interview the expert while they work, not in a conference room, and write the first draft yourself. Watch the task, ask why at every decision point, and bring back a draft for them to correct. Experts can't recite what they know. They can show it, and they can react to a version that gets it wrong.
The reason is well documented: the better someone is at a task, the less access they have to their own steps, because most of the work has become automatic. I've written before about why your best employee writes the worst documentation, and the answer to that problem is the answer to this one. Don't ask the expert to write. Ask them to perform, narrate, and correct.
In practice, sit with them through the real task at the real workstation. Every time their hands pause, ask what they just checked. Every time they deviate from the written step, ask what told them to. Then ask the two questions that surface the exceptions: what would make you stop here, and what does it look like when this goes wrong? The answers are usually the entire value of the exercise, and they almost never appear when someone types up a procedure from memory at a desk.
I've laid out the fuller method in how to document a process before you write it down. The draft you bring back for correction is the instrument. An expert reading a wrong draft will tell you things no interview reaches.
What form should the captured knowledge take?
Match the document to the decision it supports: procedures for repeatable tasks, decision notes for judgment calls, and a contact map for the relationships. A single long brain-dump document helps nobody. The knowledge should land inside the documents your team already uses, filed where the task happens.
The objection I hear most often is the video. Someone records a two-hour walkthrough of the expert explaining everything, and the company files it and feels finished. Video is a good raw source and a poor final document. Nobody scrubs through a two-hour recording at six in the morning with a line down. Transcribe it, break it into the tasks it covers, fold each task into the relevant procedure, and index the judgment calls somewhere searchable.
Where that searchable place should live is its own subject, and a knowledge base your team will actually read covers it. Knowledge filed where nobody looks is an archive, not a capture.
What if the expert doesn't want to share?
Reluctance is usually about respect, not secrecy. People guard what they know when sharing it feels like training their own replacement. Put the expert's name on the finished documents, pay for the time if they've already retired, and treat the work as their mark on the operation rather than exit paperwork.
I've seen the guarded version up close, and the honest answer to a skeptical owner is that you can't force this. What works is standing. The expert reviews and approves every document that carries their knowledge, their name goes in the revision history as the source, and the sessions are scheduled as real work instead of being squeezed into lunch.
And if the person already left? Call them. Offer a short consulting arrangement at a fair daily rate. Nearly everyone says yes, partly for the money and partly because being asked back as the authority is a compliment. Three paid days with a retired expert cost less than one reconstructed process failure, a comparison I can make with some confidence, having signed off on the cost of both.
How long does knowledge capture take, and what does it cost?
Plan on four to eight weeks per deep expert when the sessions run alongside their normal job, and start at least six months before a known departure. The final two weeks of employment are the worst capture window of an entire career: short-timer attention, farewell lunches, and a checklist mindset. Start early enough that the correction rounds have room to work.
The common failure is the exit interview scheduled in the final week. It captures passwords, a handover memo written in one afternoon, and goodwill, and it loses the judgment layer entirely. Six months lets you run shadow sessions monthly, draft between them, and put the drafts back in front of the expert while they still care about being right.
On cost: if someone inside can do the interviewing and writing, budget their time honestly, because capture done alongside a full workload slips behind every urgent thing. If you bring in an outside writer, rates vary with scope, and I've broken down the real numbers in how much it costs to document your processes. My own projects are quoted after a discovery call, because a scheduler's head and a controller's head do not take the same number of weeks to put on paper.
If you're weighing whether to handle it internally at all, when to hire a technical writer is the honest version of that decision. The place to start costs nothing: write down the one name you already know, and book the first shadow session for next week. If you'd rather talk it through first, my technical writing services page explains how I work, and the FAQ covers what owners usually ask before they reach out.
Frequently asked questions
How far in advance should knowledge capture start before a retirement?
Six months at minimum for a deep expert. That allows monthly shadow sessions, drafting between sessions, and correction rounds while the expert is still engaged. The final two weeks of employment are the least productive capture window and should be reserved for verification, not discovery.
Can we just record a video of the expert explaining the process?
Video is a useful raw source and a poor final document. Few people will search a two-hour recording in the middle of a problem. Transcribe the video, break it into individual tasks, fold each task into the relevant procedure, and index the judgment calls somewhere searchable.
What if the expert has already left the company?
Contact them and offer a short paid consulting arrangement at a fair daily rate. Most retired experts accept, and a few paid days of their time costs far less than reconstructing a failed process from scratch.
Who should write the documentation, the expert or someone else?
Someone else should draft and the expert should correct. Experts struggle to list what they know because most of the work has become automatic, but they are quick to spot what a draft gets wrong. The correction pass is where the real knowledge surfaces.
