Section 1
Two different things are being transferred
Separate them and both improve. Procedure is the reproducible sequence: how to raise an invoice, where the deploy runs, who approves a refund above a threshold. It should be written, searchable, dated and owned by someone, and a new hire should never have to ask a colleague for it. Every time they do, that is a documentation defect. Judgement is different. It is the accumulated set of decisions about what to do when two reasonable rules conflict: when to escalate rather than fix quietly, when to say no to a customer who is technically entitled to a yes, how much certainty to demand before shipping. Judgement does not survive being written as a principle, because a principle omits the conditions. It travels as cases, with the specifics attached, including the ones where the company got it wrong. The compression problem here is the same one a founder faces in a funding meeting, and [Telling Your Story to Investors: What Works, What Doesn't](/blog/telling-your-story-to-investors-what-works-what-doesn-t) is instructive on how much can be transferred in limited time.
Section 2
What makes a training case work
A case that teaches has four parts and one deliberate omission. The situation as it actually appeared, with the information that was available at the time and no more. The options that were genuinely on the table. The choice made and the reasoning behind it. What it cost, including the part that went badly. The omission is the answer. Give the case to the new hire before the resolution and ask what they would do. Their answer tells you what model they arrived with, which is information you cannot get any other way and which shapes everything else you need to teach them. Cases with the answer attached are read as content. Cases with the answer withheld are experienced as a decision, and decisions are what people remember making.
Section 3
Sourcing your case library
Use the model that follows to build the first ten cases. Each row names a recurring decision point, the incident that best illustrates it, and who currently holds the knowledge. That last column doubles as your key-person risk register, which is usually the more uncomfortable finding.
Section 4
Keeping the library honest
Case libraries rot in a specific way. The incidents stay while the conditions change, so a new hire learns a caution that made sense when the company was twelve people and applies it at eighty, where it is now an obstacle. Date every case, review the set annually, and retire the ones whose lesson no longer holds rather than editing them into vagueness. Watch the selection bias too. Cases that survive tend to be dramatic, and dramatic incidents teach exception handling rather than the ordinary work where most value and most error live. Deliberately include a boring case. Where the material is procedural and physical, a recording usually beats a document, and [Visual Storytelling: Using Images and Videos to Enhance Your Message](/blog/visual-storytelling-using-images-and-videos-to-enhance-your-message) covers where that swap pays off.
Section 5
Where the material should come from
The best cases are not written by the training function. They come out of the record the company already produces: support tickets that escalated, deals lost with a stated reason, post-incident reviews, the renewal conversation that went sideways. That material has the two properties invented scenarios never have. It is real, and someone in the building can be asked what actually happened. Make collection routine rather than heroic. One line at the close of each post-incident review answering what someone joining next year would need to know. Reading that corpus at scale is its own problem once volume grows, and [Using AI to Analyze Customer Feedback at Scale](/blog/using-ai-to-analyze-customer-feedback-at-scale) covers the tooling side. You are ready to build a case library if you can name three decisions your team gets wrong repeatedly. If you cannot, the gap is measurement, not training.