KM-101 · Module 3

KM-201b: Knowledge Capture Deep Dive

3 min read

KM-201b: Knowledge Capture is the practitioner course for getting knowledge out of people's heads and into systems — with a heavy focus on tacit knowledge extraction, the hardest part of the problem. The course covers knowledge interview techniques in detail: how to structure a 90-minute elicitation session with a subject matter expert to surface the judgment calls, edge cases, and pattern recognition that never make it into formal documentation.

The decision capture module addresses a specific type of knowledge loss that most KM programs miss entirely: the reasoning behind decisions. Organizations document what was decided constantly — in meeting minutes, in project trackers, in JIRA tickets. They almost never document why. Two years later, when someone asks 'why does this process work this way?' or 'why did we choose this architecture?' the answer is 'I don't know, ask Dave — oh, Dave left.' Decision capture is the practice of recording not just the decision but the options considered, the criteria used, the information available, and the tradeoffs made.

The runbook module teaches a specific document pattern that is underused outside of software operations teams and should not be. A runbook is a procedure document written at the level of detail required to transfer capability to someone who has never performed the task. It is not a high-level process overview. It is a step-by-step transfer of executable knowledge. The difference between a process overview and a runbook is the difference between 'review the customer contract before renewal' and the eleven steps that actually constitute a competent contract review, written at the level of detail that lets a new person do it correctly.

KM-201b also covers passive capture pipelines — the systems that extract knowledge from daily work without requiring extra effort from knowledge holders. AI-assisted meeting summarization, decision log automation, and Slack-to-wiki integration are all covered with enough implementation detail to actually build them.

Do This

  • Start knowledge capture before turnover creates urgency — the best extraction window is before someone decides to leave
  • Use structured interview techniques rather than open-ended documentation requests
  • Build passive capture pipelines to reduce the per-document cost of capture
  • Prioritize decision capture for any decision that will be hard to reverse or expensive to re-derive

Avoid This

  • Wait until an expert announces their departure to start knowledge extraction
  • Ask subject matter experts to self-document their expertise without structured support
  • Build a knowledge base template and assume the structure alone will drive capture
  • Focus capture effort on explicit knowledge and ignore the tacit layer