Every small company has one person who knows how things actually work. They know which supplier needs a phone call rather than an email, why that setting looks wrong but is right, and what to do when the monthly report does not add up. Then they step back, go on leave or move on, and the rest of the team discovers how much lived in one head.

Across the communities we follow, this keeps coming up in different shapes. A founder of a small tech company wants to step back from daily operations and is wondering how to hand over without becoming the bottleneck forever. An HR lead maintains job aids that change so often that any polished training is out of date by the time it ships. A company asks how to get employees to actually finish the training they are assigned, and gets answers ranging from "make it mandatory and track it" to "if people avoid it, the training is the problem". A sales leader wants new reps productive sooner. An instructional designer leaving a big authoring suite asks which material genuinely needs an authoring tool and which could just live as plain lessons.

Underneath all of these sits one question we find genuinely open: should a small team capture what people know as a wiki, or as a course?

Side A: write it down and make it searchable

The case for a wiki, a shared doc space or a set of runbooks is simple:

  • People look things up at the moment they need them. Nobody remembers a module they took three weeks ago; they search when the problem appears.
  • It is cheap to keep current. Change one line when the process changes. No re-recording videos, no rebuilding quizzes.
  • It respects experienced hires. Someone who already knows most of the job does not want to sit through what they know to find the two things they do not.
  • Mandatory training breeds box-ticking. Several people argued that forcing completion mostly measures who clicked through fastest.

The wiki camp's motto is roughly: document the process, keep it current, and trust people to read.

Side B: a short course with checks

The other side is just as firm:

  • A wiki tells you what exists, not whether anyone understood it. A handover is not done when the page is written; it is done when someone else can handle the situation without help.
  • Order matters for new people. Someone new does not know which of forty pages to read first. A short sequence gives them a path.
  • Scenario checks catch gaps early. Two or three "what would you do if" questions per topic reveal misunderstandings before a customer does.
  • A record helps the team. Knowing who can handle refunds, the month-end close or a supplier escalation is useful information, not surveillance.

The course camp's motto: if it matters enough to hand over, it matters enough to check.

The grey areas

This is where it gets interesting, because many teams end up somewhere in between.

  • Change rate. Material that changes every few weeks seems to belong in a wiki; material that rarely changes but is costly to get wrong seems to belong in something with checks. But what about the process that changes often and is costly?
  • Who it is for. A brand-new hire and a colleague covering for a week need very different things. Is one format ever right for both?
  • Mandatory or available? Some argue the problem with forced training is the content, not the requirement. Others say any requirement turns learning into compliance.
  • Who keeps it alive? Both formats rot when nobody owns them. A wiki goes stale quietly; a course goes stale loudly. Which failure is easier to live with?
  • Tool weight. Big authoring tools make polished modules, but some teams say plain text, a short video and a few questions do the job, and are far easier to update.
  • The outgoing person's role. Should the person leaving write the material, review it, or watch someone else use it and fill the gaps?

Where we lean

We work with teams on both sides of this, so we hold the view loosely. Our lean: keep the reference material in a searchable place, and wrap only the handful of situations that are costly to get wrong in a short sequence with scenario checks. One module per recurring problem, two or three questions each, reviewed by the person who knows it best before they step away. Everything else stays as pages people search.

That is a middle path, and we would genuinely like to hear where it breaks.

Your turn

  1. When someone key left your team, what actually got the knowledge across: documents, recorded walkthroughs, shadowing, or something else?
  2. Have you ever made internal training mandatory? Did completion go up, and did the work get better?
  3. For material that changes every few weeks, how do you keep it current without a full-time owner?
  4. Where would you draw the line between "look it up when needed" and "prove you can do it"?