The post-event review that nobody runs
Fifteen minutes that change the function
End-of-shift reviews are the easiest source of real-time improvement and the most consistently neglected. Fifteen minutes is enough. The structure is simple. The cumulative effect over a quarter is significant. Operations that run the review build a real-time function that gets measurably better; operations that don’t produce the same patterns of intervention every week, never learn what works, and pass the same problems to the next shift.
The five questions
1. Forecast vs actual. What did the day actually do, by interval, against what was forecast? The aggregate answer takes thirty seconds; the interesting bit is the shape of the variance — when in the day was it most off, and in which direction.
2. Where did SL deviate? Which intervals, which skills, by how much? Not just the headline daily SL but the texture across the day. The team that lost SL for two hours mid-afternoon is a different story from the team that lost it all day at a smaller margin.
3. What did we do? Which levers fired, when, and at whose authorisation? This question creates the link between the lever menu (from the previous piece) and the actual decisions made. Over months it produces a record of how the menu is actually being used.
4. What worked? The honest assessment of whether each lever recovered SL, by how much, and how quickly. Some levers reliably work; some reliably don’t; some work in specific conditions only. The post-event review is the only mechanism that builds this knowledge.
5. What would we do differently? The question that most teams skip. The structured assessment of whether, knowing what we know now, we’d have made different calls. This question is the one that produces improvement; without it, the review is a record rather than a learning loop.
Why most operations skip it
The pattern is familiar. End of shift, everyone wants to go home. The day was busy and the analyst is tired. The TLs are dealing with end-of-day admin. The next shift is starting and needs a brief. The post-event review keeps getting deferred, then never happens. Within a quarter, the discipline has died entirely.
The structural fixes that work. Calendar-block the review as a non-negotiable part of the shift (the day ends with the review, not before it). Keep it short (15 minutes, hard stop). Make the format the same every day (no thinking required, just answer the five questions). Capture it in a shared log (so the cumulative pattern is visible). Operations that build these structures find the review survives the inevitable busy days; operations that don’t lose it within months.
What to do with the cumulative learning
The single biggest payoff isn’t from any individual review. It’s from reading the rolling log of reviews over a quarter. Patterns emerge that no single shift could surface.
The lever that’s pulled often but rarely recovers SL meaningfully (probably needs to come off the menu, or have its trigger condition tightened). The recurring time-of-day SL drift that nobody’s scheduled against (the schedule needs adjusting; this is exactly a schedule-ages-out signal). The TL who’s consistently the first to flag emerging problems (worth involving in the design of the early-warning rules). The week-day-of-week effect that’s not in the forecast yet (feed back to planning).
Operations that run a quarterly read-out of the log to operations leadership find the function gets taken more seriously, because the leadership audience can see specific patterns being learned and acted on rather than vague claims of “we’re getting better.”
The cultural prerequisite
The review has to be safe. If “what would we do differently” produces blame for individual analysts, the answers become defensive and the review stops being honest. The analyst learns to say what protects them rather than what was actually true, and the learning loop closes.
The fix is mostly tone. The review is about the function’s decisions, not the individuals. The fifth question is “what would the team do differently next time” rather than “what should you have done.” The TL or manager running the review models this language; the team picks it up. Within a few weeks the review feels honest. This is essentially the psychological-safety point applied to a single recurring meeting.
Conclusion (and series conclusion)
The post-event review is the closing piece of this series because it’s the discipline that compounds all the others. The team that runs it consistently catches its own noise-reactions in the “what worked” column. It catches its dashboard-vs-floor blind spots in the “what would we do differently” column. It refines its lever menu based on the lever-effectiveness pattern. It feeds its communication improvements into the standing channels. The review is the mechanism through which the function teaches itself.
That’s the six failure modes. Don’t react to noise. Get off the dashboard and onto the floor periodically. Write down the lever menu. Build the four standing communication channels. Run the post-event review. Build the upstream relationships that turn real-time from reactive to anticipatory. Each is correctable; together they produce a real-time function that’s materially more effective than the headcount or tooling would predict.
Series end. Read from the start: Where real-time most often goes wrong.
Pair this with the planning cycle, psychological safety, and bad news, communicated well.