Map Your Organization's Hidden Knowledge Before Someone Leaves
The most valuable knowledge in your company is not in any document. Three prompts that extract it before it walks out the door.
The Problem
Every company has people who know things nobody else does. How the billing system actually works when the API returns error code 47. Why the Barcelona office handles procurement differently from Munich. Which supplier contact to call at 2 AM when the production line stops. Who made the decision to switch vendors in 2019, and why the obvious alternative was rejected.
This knowledge exists in exactly one place: someone's head. It is not in your wiki. It is not in your Confluence. It is not in your Slack history. It lives in the accumulated experience of people who have been solving problems long enough to develop intuition about how things really work, as opposed to how documentation says they should work.
When that person leaves, the knowledge leaves with them. What follows is weeks of the remaining team discovering gaps they did not know existed. Processes break in ways nobody predicted. Decisions get revisited because nobody remembers the constraints that shaped the original choice.
The fix is not better documentation. It is structured knowledge extraction while the person is still available to answer questions.
The Fix
Map knowledge dependencies, not job descriptions. A job description says what someone does. A knowledge dependency map shows what only they can do. The difference matters. Many tasks on a job description can be transferred in an afternoon. Knowledge dependencies take weeks to identify and months to transfer, because they involve context, judgment, and relationships that were never written down. Start by asking: "If this person were unreachable for 30 days, what would break?"
Extract three layers: decision, process, and relationship. Decision knowledge covers why choices were made. "We picked Vendor A over Vendor B because B had a 6-week lead time that would have killed the Q3 launch." Process knowledge covers how things actually work. "The order system requires you to enter the discount code before the shipping address, or it silently drops the discount. This is not documented anywhere." Relationship knowledge covers who to call for what. "Maria in compliance will fast-track your review if you send the request before 10 AM on Tuesdays. After that, it goes into the standard queue."
Cross-reference against documentation to find the gaps. The most dangerous knowledge is the kind that contradicts your official documentation. The process manual says step 3 comes after step 2. The person who actually runs the process knows that step 2 causes a timeout if you do not run step 5 first. This gap between documented reality and operational reality is where most post-departure failures originate. Finding it requires comparing what the documentation says against what the person actually does.
Copy-paste prompt: knowledge dependency mapper
"I need to map the knowledge dependencies for a key team member who may be transitioning out of their role. I will provide their job title, team, responsibilities, and any available documentation about their workflows. Analyze this information and produce: (1) A knowledge dependency map organized into three categories. DECISION knowledge: decisions this person was involved in where the reasoning is not documented anywhere. For each, identify the decision, the context that shaped it, and what would happen if the decision were revisited without that context. PROCESS knowledge: processes this person runs where the actual execution differs from any existing documentation. For each, describe the documented version, the actual version, and what breaks if someone follows the documentation literally. RELATIONSHIP knowledge: contacts, vendors, stakeholders, or internal colleagues where this person has a unique relationship that affects outcomes. For each, describe who, what the relationship enables, and what happens if a new person approaches the same contact cold. (2) A risk assessment for each knowledge item: HIGH (no backup, no documentation, process breaks immediately), MEDIUM (partial documentation exists, team could recover in 1-2 weeks), LOW (documentation is adequate, transfer is straightforward). (3) A prioritized extraction plan: which knowledge items to capture first, what questions to ask, and what format to store the answers in for maximum usefulness to the successor."
Optional: structured interview generator
"Based on the following knowledge dependency map, generate a structured interview script for extracting the identified knowledge from the departing team member. For each HIGH and MEDIUM priority item, create 3-5 specific questions designed to capture the knowledge in a transferable format. The questions should follow this pattern: (1) Start with the current state: 'Walk me through exactly what you do when X happens.' (2) Probe for exceptions: 'What is the most common way this process fails, and what do you do when it does?' (3) Capture context: 'Why was it set up this way? What alternatives were considered and rejected?' (4) Identify dependencies: 'Who else needs to know this? Who do you call when this goes wrong?' (5) Test completeness: 'If I followed your instructions exactly, what would I still get wrong the first time?' Group the questions into 45-minute interview sessions. No session should cover more than 3-4 knowledge items. Order sessions so that foundational knowledge comes first and dependent knowledge comes later. Include a brief summary template at the end of each session for the interviewer to fill in while the conversation is fresh."
Optional: documentation gap analyzer
"I will paste the transcript or notes from a knowledge extraction interview, plus the existing documentation for the same process or area. Compare what the interview reveals against what the documentation says and produce: (1) Confirmed accuracy: documentation items that match what the person actually does. Mark these as verified. (2) Gaps: knowledge from the interview that has no corresponding documentation at all. For each gap, classify it as critical (process breaks without it), important (process degrades without it), or contextual (nice to have but not operationally essential). (3) Contradictions: places where the documentation says one thing and the person does another. For each contradiction, identify which version is correct, what happens if someone follows the documentation, and what needs to be updated. (4) Tacit knowledge: things the person mentioned as obvious or assumed that would not be obvious to a successor. These are often the most dangerous gaps because the departing person does not recognize them as specialized knowledge. (5) A knowledge transfer document that incorporates everything from the interview into a format a new person could use on day one. Organize it by workflow, not by interview question. Include decision context, exception handling, and contact information for key relationships."
What you get
A complete map of where your organization's knowledge actually lives versus where you think it lives. Structured interview scripts that extract knowledge in transferable format before the person leaves. Documentation that reflects how work actually gets done, not how someone imagined it would get done three years ago. A clear list of single points of failure that you can address proactively instead of discovering after the departure.
Extraction time
~3 sessions
Knowledge gaps found
60-80%
Post-departure disruption
Cut in half
Why documentation alone does not solve this
Documentation captures what people choose to write down. The problem is selection bias. People document the easy, obvious parts of their job. The hard, contextual, judgment-based parts feel too complicated to write down, too obvious to bother with, or too political to commit to paper.
The knowledge that leaves when someone leaves is precisely the knowledge that was never documented. Not because nobody cared, but because the kind of knowledge that accumulates over years of hands-on experience resists the format of a wiki page. It lives in stories, in exceptions, in "well, that depends on..." answers. Structured extraction interviews, guided by AI-generated questions that specifically target undocumented knowledge, get at what voluntary documentation never captures.
The real cost of knowledge loss
When a senior engineer leaves, the team typically spends 3 to 6 months recovering the lost knowledge through trial and error. That means 3 to 6 months of slower decisions, repeated mistakes, and processes running at reduced efficiency. For a team of ten, losing one person's institutional knowledge can cost the equivalent of 2 FTEs for a quarter.
The hidden cost is even larger: decisions get revisited without the context that shaped them. A vendor chosen for specific reasons gets replaced because nobody remembers those reasons. A process designed around a constraint gets "optimized" by removing the step that handled the constraint. The new team reinvents the wheel, except this time it is slightly worse, because it lacks the accumulated lessons that shaped the original design.
Works for
HR and people teams managing offboarding for senior or long-tenured employees
Engineering managers preparing for a key developer's departure or team transition
COOs who suspect critical processes depend on single individuals
New managers inheriting a team and needing to understand undocumented workflows quickly
M&A integration teams trying to capture institutional knowledge from acquired companies before reorganization
Three interview sessions can capture what took someone years to learn. The question is not whether you can afford the time. It is whether you can afford the loss.