training · learning
Training people on a process once is almost the same as not training them
The forgetting curve applies to runbooks too. Why a single onboarding session on a procedure doesn't hold, what retrieval practice and spaced refreshers change, and how to tell who actually knows the process.
A new support agent joins. In week one they sit through the triage process: a walkthrough of the Confluence page, maybe a slide deck, a quiz at the end. They pass. Six weeks later they escalate a "not a bug" to engineering with no evidence, and their lead says: we covered this.
They did cover it. The agent isn't lying when they say they don't remember. Both things are true, and the reason is a hundred and forty years old.
The forgetting curve is not a metaphor
Hermann Ebbinghaus measured it in the 1880s and it has been replicated many times since: without reinforcement, most of what is learned in a single session is gone within days. The exact numbers vary with the material and the person; the shape doesn't. One exposure decays fast.
For a procedure that an agent uses twice a week, the common path survives on practice. The exceptions — the compliance-critical branch, the "expected behaviour, not a bug" list, the step that only matters for one customer in twenty — are precisely what decays, because they're rarely rehearsed. They're also precisely what the document exists for.
What the learning science says works
Three findings with decades of evidence behind them, all cheap to apply to process training:
Retrieval practice. Being asked to produce the answer (what's the next step here?) beats re-reading the document by a wide margin. The act of retrieving is what strengthens the memory. A walkthrough is re-reading; a scenario is retrieval.
Spacing. Reviewing at expanding intervals — a couple of days, a week, a month, a quarter — produces retention that a single long session cannot. Each review arrives just as the memory is fading, and the effort of retrieving it then is what makes it last.
Calibration. People who are confidently wrong make the costly mistakes; people who know they're unsure ask. Asking "are you sure?" before showing the answer, and treating a confident miss differently from a hesitant one, teaches people where their own knowledge stops.
What this looks like for a runbook
- Build the course from the document itself, so what's taught is what will be followed. Realistic scenarios — a ticket, a situation, four plausible options — not definitions.
- Practice until each stage holds, not until a fixed number of questions is answered. Someone who already knows the escalation rules shouldn't answer five questions about them; someone who doesn't should answer more.
- Pass the check, then refresh: three questions at 2, 7, 30 and 90 days. Two minutes each. A lapse brings the next one sooner.
- Put the misses where the owner can see them. When four of six people pick "escalate" on the same scenario, the document is unclear at that stage. That's the single most useful piece of feedback a process owner can get, and most training systems throw it away.
- When the document changes, tell the people trained on the old version what changed, and ask them to re-check only if the steps changed, not the wording.
How to tell who knows the process
Not from the completion certificate. From mastery per stage: which stages each person holds, which are shaky, how many sure-but-wrong answers they've given, and when their last refresher was. That's the report a team lead can act on — "the whole team is shaky on the escalation branch" is a training problem; "everyone's fine except on stage 3, where the document says two different things" is a document problem.
This is the model we built into Learn. It isn't novel; it's what every good language-learning app has done for a decade, applied to the procedures that run a company.