Tribal Knowledge Walks Out the Door at 65. The Schema Doesn't.

The senior engineer who keeps your tax engine running handed in his resignation Monday. Twenty-two years in the company. His head is the only place that holds the wiring for three legacy systems, two acquired-company integrations, and a 2009 production incident that still shapes how your deployment pipeline works — nobody else was in the room for most of it. Last day in eight weeks. The reflex from leadership is already forming: ask him to "document everything before he goes."

He won't. Not because he is unwilling. Because "document everything" is an impossible ask wearing the costume of a reasonable one. No structure, no prioritization, no format, no audience. What it produces — at best — is a 200-page Word document in a folder nobody can find, a handful of orphaned Confluence pages, and a few coffee chats that evaporate the moment he badges out. Eighteen months later, a junior engineer pushes a change to the tax engine and causes a compliance incident that takes three weeks and two contractors to unwind. That re-discovery bill is the actual cost of skipping this work.

The failure mode is structural, not motivational. Between 2024 and 2030, 30.4 million baby boomers will turn 65^[1]. In enterprise software, 45% of senior engineering leaders are retirement-eligible inside five years^[2]. The people who know why the SAP customization was bolted on in 2003, why the nightly batch runs at 3 AM, and which customer has a bespoke tax exemption wired into a stored procedure are walking out. The only question is whether the knowledge leaves with them or stays as something the AI can retrieve.

The ask fails for three reasons. None of them are about effort or goodwill.

The framing is homework. You hand someone in their final eight weeks — already negotiating transition logistics, an emotional exit, and probably a new job — an unbounded, unprioritized task with no payoff they will see. Engineers who want to leave things clean will try. They write until they cannot write anymore, producing pages that are comprehensive without being organized around the person who comes after them. Effort is not the bottleneck. Structure is.

The engineer cannot see what is load-bearing. Most of what a twenty-year veteran knows feels obvious to him. He cannot reliably tell the difference between "this is critical context that saves the next owner six months" and "this is background any competent engineer figures out in a week." The hardest knowledge to extract is tacit: the moves he makes without thinking, the decisions he made so long ago he has forgotten they were decisions. Self-documentation surfaces what is salient to him, not what is load-bearing for the system.

There is no schema, so there is no destination. Without a defined artifact type, the output is whatever shape the engineer defaults to. Usually prose. Prose is not searchable by system. It does not link to a knowledge graph. It cannot be retrieved by an AI agent answering a question in 2028. It is a document in a folder, slowly aging into shelfware.

The goal is not capture from everyone. It is capture from the people whose exit produces a production incident, a compliance miss, or a six-month re-discovery spiral. That list is shorter than you think — and far more urgent than headcount data will ever flag.

Start with a bus-factor audit. For every critical system, the question is one line: how many people can debug a production issue in this system at 2 AM without calling someone? If the answer is one, that is a single-point-of-failure. If that one is within five years of retirement, the extraction is urgent. Within two, it is an emergency.

The systems that hide the most load-bearing tribal knowledge are almost always the oldest: the core billing engine, the legacy ERP integration, the custom tax module, the deployment pipeline that accreted twelve years of one-off fixes. These rarely have the best documentation. They are usually the systems nobody volunteers to touch — which is precisely why the person who does carries knowledge that has no second copy.

The format is non-negotiable. One hour. One topic. One interviewer. One note-taker or recorder. The questions are written before the session. The interviewer does not improvise. The interviewee is not asked to prepare. The objective is to extract what is already in his head — not to ask him to pre-organize it.

Free-form sessions produce unextractable output because the shape of the conversation tracks what the interviewee finds memorable, not what the organization needs to capture. A structured hour anchors the transcript to specific retrievable artifacts: decision records, runbook gaps, system gotchas, and the "why we did it that way" entries that live nowhere else. The twelve questions below are designed to surface tacit knowledge by demanding specifics — never summaries.

The interview produces a transcript. The transcript is raw source. What you do with it next decides whether the hour compounded or evaporated.

Extraction turns unstructured narrative into typed artifacts: ADR-style decision records (why this was built this way), runbook patches (the undocumented step the on-call actually executes), system gotcha entries (the landmines the interviewee named), and org-knowledge-map entries (who knows what, traceable to a source). Each artifact has a defined schema — covered in the next section — and a defined home in your existing knowledge infrastructure. No schema, no home, no extraction.

The LLM is the extraction tool, not the author. You supply the transcript, a system prompt with each artifact schema and a few well-formed and poorly-formed examples, and an explicit instruction to identify discrete knowledge claims and serialize each into the right schema. This is not summarization. Ambiguous or unverifiable claims get flagged with a confidence score — never silently dropped. Every artifact passes through human verification before it enters the live knowledge base. LLMs hallucinate institutional history with full confidence. A second senior engineer signs off on anything that will be treated as authoritative.

Meta's 2026 work on tribal knowledge in large-scale data pipelines used a swarm of specialized agents to read every file and emit structured context files — coverage went from 5% to 100% of code modules^[5]. The interview-first approach here is the human-side complement to that kind of automated extraction. Code-side and human-side feed the same retrieval surface.

Extraction is bounded by the schema you give the LLM. Vague instructions produce vague output. Decide the artifact types before the first interview — the schema is what converts a transcript from raw text into a retrievable asset.

Each artifact below maps to a specific information need and a specific home in your existing knowledge infrastructure. Fields, destination, and ownership are defined up front. No artifact without an owner. No artifact without a home.

Recording a structured interview without explicit informed consent is two failures in one — legal and trust. In most US states and across every EU jurisdiction, recording a conversation requires consent from all parties. The legal floor is the easy part. The framing of the conversation is what decides whether the engineer answers honestly or hedges.

Written consent before the first session. The form specifies: what is being recorded, how the transcript is stored and for how long, who has access to the raw audio versus the extracted artifacts, and that extracted artifacts may carry an attribution back to the interview for traceability while the raw recording stays inside the knowledge management team.

The framing for the conversation with the departing engineer is direct. This is for operational continuity, not his personnel file. The output never enters an HR process. The recording is held for 90 days and then deleted. Extracted artifacts are kept indefinitely as institutional documentation. Most engineers respond well to this framing — they want the knowledge to survive them. What they resist is the feeling of being surveilled or evaluated. Name the difference up front.

The retention policy goes in writing, communicated before recording starts. Ninety days for raw recordings is a reasonable default. Extracted artifacts are permanent documentation assets — versioned, attributed, and auditable. Treat them that way from day one.

The technical pipeline has four stages. Each one carries a tool recommendation and a specific failure mode that kills the program if you ignore it.

One honest caveat before the stages. Most extraction programs do not stall on technical failure. They stall because the first batch of artifacts has nobody querying them. If you cannot show an engineer a concrete example of a retrieved gotcha that prevented an incident inside 90 days, organizational appetite collapses and the program quietly dies. Start with a retrieval surface that already has active users — an AI coding assistant, Slack search, the runbook viewer — not a new internal wiki nobody opens.

Stage 1: Transcription. Whisper (local or API) or an equivalent speech-to-text service with speaker diarization enabled. Diarization assigns speaker labels — critical for separating the interviewer's questions from the engineer's answers, which matters the moment the LLM tries to extract artifacts. Output: plain text with speaker labels and timestamps. Store in your document system with access controls matching the consent policy. Failure mode: missing diarization turns the transcript into a single stream of unattributed claims.

Stage 2: LLM extraction. Run the transcript through a structured extraction prompt against each artifact schema. The system prompt carries the schema definition, well-formed and poorly-formed examples, and an explicit instruction to flag low-confidence entries rather than omit them. Use a long-context model — hour-long transcripts run 8,000-15,000 tokens. GPT-4o, Claude Sonnet, or equivalent. Never use a summarization prompt. The task is to identify discrete knowledge claims and serialize each into the right schema, not to compress what was said.

Stage 3: Storage and indexing. Extracted artifacts go to their defined homes — ADR directories, runbook patches, gotcha catalogs — and are chunked and embedded into your vector store in parallel. Knowledge graphs are emerging as the infrastructure layer for this in enterprise settings^[8]: typed entities (system, person, decision) connected by typed relationships (knows, made, depends-on) carry the semantic structure pure vector search lacks. Starting from scratch, a document store with a tight tagging schema and full-text search is enough. The knowledge graph earns its weight once you have the volume to justify the infrastructure cost.

Stage 4: AI retrieval integration. Artifacts have to surface where engineers already work — inside the AI coding assistant context, inside internal Slack search, inside the incident runbook. Fortune 500 companies lose an estimated $31.5 billion a year on information that exists but cannot be found^[8]. Indexing in a system nobody queries is the same as not indexing at all. Pick the retrieval surface first. Design the storage format to feed it.

The exit ramp is dated. Between now and 2030, 30.4 million baby boomers will turn 65^[1]. In enterprise software, the SPOF concentration is acute: the engineers who lived through the longest-running systems, sat in the room when the decisions were made, and still pick up the 2 AM page — every one of them is inside striking distance of exit. The bill for doing nothing is paid in incidents, re-discovery spirals, and the quiet morning when nobody on the team can explain why the deployment script runs at 3 AM.

The bill for doing something structured is two hours per interview, a working extraction pipeline, and a program owner with a quarterly calendar entry. Small relative to what it protects. The difference between a knowledge graveyard and a retrievable knowledge base is not effort. It is structure. Build the schema first. Then run the interview.