Cramming has a half-life. So does your last all-hands.

There is settled math for how often to revisit something so it survives. A meta-analysis of 317 experiments (839 effects) found the optimal gap between practice sessions is roughly 10 to 20 percent of how long you need to remember. Need it in a month? Revisit every few days. Need it in a year? Space it out to weeks. Cram it all at once and the curve falls off a cliff. The study.

This is across domains, not specific to engineering, so it is a shape to borrow, not a literal schedule to copy. But the shape explains why the offsite that "covered" the incident playbook produced a team that cannot run it four months later.

Comprehension debt: the gap between what gets shipped and what the team can still reason about.

Knowledge is not a state you reach, it is a thing that decays, and a one-time training is a deposit that quietly drains. The lunch-and-learn did not fail because people did not care. Nothing pulled it back up at the right interval, so it followed the forgetting curve down. And the playbook the team cannot run four months later is a roadmap line you are quietly carrying on one person's memory. When you plan how the team retains anything important, plan it as spaced repetition, not as an event with a date.

One for your next review:

A page was slow, so an engineer added a cache with a one-hour expiry. The page is fast now. A week later, support reports that users sometimes see data that is up to an hour out of date.

This one turns on a single question: did someone choose the staleness window on purpose, naming which fields can live with an hour stale and which cannot, or did an hour just happen to be the default? Being shocked that the cache is "wrong" is the answer that should worry you, because the cache is doing precisely what it was told. A freshness window nobody decided is how a cache quietly becomes an outage.