Knowledge Capture Interviews: Recording What Experts Know Before They Leave

What these interviews can and cannot capture

Some knowledge is already written down: the system manual, the policy, the checklist. Knowledge capture interviews go after the rest, the judgement experienced people use without thinking about it. Which supplier to call when the usual one cannot deliver. Which warning on the control panel can be ignored and which cannot. Why the quarterly report is always run on a Tuesday.

This kind of knowledge is often called tacit, and some of it cannot be fully put into words. An interview will not turn twenty years of experience into a document. What it can do is surface the decisions, exceptions, contacts and warning signs that a successor would otherwise learn the hard way, and record them in a form people can find. That is usually enough to prevent the worst surprises.

Choosing what to capture

You cannot record everything someone knows, and you should not try. Start from risk: what goes wrong, or stops, when this person is not there?

Build a short list with three groups of people:

• The expert, who knows what is hard but may underestimate what others do not know.
• Their manager, who knows which outcomes depend on them.
• The people who call or message them for help, who know exactly which questions keep coming back.

Then rank topics by two questions: how much damage would a mistake cause, and how undocumented is it today? Tasks that are critical, rare and undocumented come first. A task done every day is usually well understood by others already; a task done once a year, like the annual system reconciliation, is where knowledge vanishes. Keep the first round to a handful of topics. You can schedule more later.

Planning the sessions

Several focused sessions beat one long farewell conversation. A common pattern is 45 to 60 minutes per session, one topic each, spread over a few weeks so the expert can remember things between sessions and you can review each transcript before the next.

Decide who asks the questions. The best interviewer usually knows enough about the work to follow the answers but not so much that they skip steps the expert also skips. If possible, include the person who will inherit the work, who will ask the questions they genuinely need answered. Send the expert the topic list in advance and ask them to bring artifacts: spreadsheets, checklists, emails, screenshots, contact lists.

Be thoughtful about framing. Being asked to document your job before leaving can feel like being erased. Make it clear the goal is to preserve their work and protect the people who follow, and give them credit in the documents.

Questions that draw out real knowledge

General questions produce general answers. "How do you handle supplier problems?" gets a tidy summary of the official process. Questions about specific cases get the real one.

• Walk-through: "Take me through the last time you ran the year-end close, step by step."
• Critical incident: "Tell me about a time this went wrong. What did you notice first?"
• Cues: "How do you know when the machine is about to jam?" "What makes you decide to escalate?"
• Contrast: "What does a new person usually get wrong?" "What would an expert do differently from a competent beginner?"
• Exceptions: "When does the normal process not apply?"
• People: "Who do you call when you are stuck, and for what?"
• Artifacts: "Can you show me the spreadsheet you use? Why that column?"
• Close: "What have I not asked that I should have?"

Follow-up probes matter more than the prepared list. When the expert says "you just check it", ask what exactly they check, where, and what result would worry them. When they say "it depends", ask on what. Many of the most valuable answers come from the third or fourth "why".

Recording setup

The recording is the raw material for everything that follows, so make it easy to transcribe and easy to revisit.

• Get consent and explain use. Tell the expert how the recording and transcript will be used, who will see them, and how long they will be kept. Follow your organization's policies on recording employees.
• Choose video when the work is visible. If the expert demonstrates equipment, software or a physical process, video lets you show a successor what "the valve should look like this" means. A screen recording works for software walkthroughs.
• Use a decent microphone close to the speaker, in a quiet room. A lapel microphone or a USB microphone on the table is a large improvement over a laptop's built-in microphone across the room.
• For remote sessions, record locally where possible and ask the expert to wear headphones to avoid echo. The details are in recording a remote interview.
• Name files consistently: date, expert, topic, session number.

From transcript to procedures and FAQs

A transcript of a good interview is rich and disorganized. The expert jumps ahead, doubles back, tells a story, and mentions the most important warning in passing. Your job is to restructure it into documents people can act on.

1. Read the full transcript once and mark four kinds of content: steps, decision points, warnings and contacts. A fast way to work through long sessions is in reviewing long recordings quickly.
2. Draft procedures in plain imperative steps ("Open the reconciliation workbook. Check that column F totals match the ledger."), with each decision point written as a condition ("If the totals differ by more than a rounding amount, stop and check the import log.").
3. Put warnings next to the step they apply to, not in a list at the end.
4. Turn recurring questions into a short FAQ, using the questions colleagues actually ask as the headings.
5. Build a glossary of local terms, nicknames and abbreviations. Every team has words that mean nothing to outsiders.
6. Add timestamps to the source recording for anything a reader might want to see or hear, such as a demonstration at 23:40.

Where a topic is best taught by showing, a short edited clip from the recording may be more useful than any paragraph. Turning demonstration videos into written help is covered in turning videos into help center articles, and the same structure works for internal documentation.

Validation by the expert

An unvalidated procedure written from an interview is a guess with good intentions. Validation turns it into something people can rely on.

• Send each draft to the expert with specific questions: "Is step 4 right? What happens if the import fails?" Open requests to "have a look" get skimmed.
• Ask the expert to mark what is missing, not just what is wrong. Interviews tend to capture the normal path and miss the exceptions.
• Test with a novice. Have someone who does not know the task follow the procedure while the expert watches silently. Every hesitation points to a gap.
• Where possible, ask a second experienced person to review, since one expert's habits are not always the best or only way.
• Give each document an owner and a review date, so it does not quietly go stale after the expert has gone.

Schedule validation while the expert is still around. Once they have left, questions get harder to ask and answers harder to get.

Pitfalls and limits of knowledge capture

• Starting too late. Interviews in the final week produce rushed, shallow answers. Begin as soon as a departure is known, or better, before anyone is leaving.
• Asking about the official process. You already have that. Ask about what actually happens.
• Filing the recordings and stopping there. Nobody will listen to ten hours of interviews. The procedures and FAQs are the deliverable.
• Treating the transcript as accurate. Machine transcripts can misrecognize names, part numbers and jargon, so check those against the recording and with the expert.
• Ignoring sensitivity. Interviews may stray into colleagues, conflicts or personal matters. Edit those out of shared documents and restrict access to the raw recordings.
• Assuming documents replace people. Some judgement only transfers through practice. Pair documents with supervised hand-over time.

A related but different exercise, interviewing customers to write their story, is covered in writing a case study from a customer interview.

Where mydubly fits in knowledge capture

mydubly handles the step from recording to text. You choose the interview file from your device, video (MP4, MOV, WebM, MKV, M4V) or audio (MP3, WAV, M4A, AAC, OGG, FLAC), up to 2 hours per file, and download a plain transcript.txt to draft from, a timestamped transcript with [m:ss] labels for pointing readers to demonstrations, and SRT and VTT subtitle files if you share clips with captions. The picture of a video stays on your device; only compressed audio chunks are sent for recognition. Details are on video to text, and audio to text covers audio-only sessions.

If your team works in several languages, you can add a translated transcript in one of 21 languages in the same job, which gives colleagues a readable draft. Procedures in another language should still be reviewed by a fluent person who knows the work. mydubly does not label speakers, so mark interviewer and expert yourself, and it does not write procedures, summarize, or store recordings: results are deleted within 30 minutes of a job finishing. Transcription costs 1 credit per minute with a 5-credit minimum per file, so five 50-minute sessions cost 250 credits (25¢).

Next step: pick one person and three topics

Choose one colleague whose absence would hurt most, ask them, their manager and their most frequent askers for the topics only they handle, and pick three. Schedule the first session, record it cleanly, and turn the transcript into one validated procedure before the second session. That first document will show you which questions to ask next. For more on turning interviews into text, see the interview transcription use case.