Checklists, runbooks & the pre-shift briefing

High-pressure work doesn’t run on heroics — it runs on a page of writing that catches the errors experts make under load.

The idea

Skill isn’t the problem. Under load, even experts skip a step they’ve done a thousand times. A checklist is a memory backstop for exactly those moments. A runbook goes further — it turns a failure you’ve seen before into a rehearsed if this, then that so nobody improvises during the fire. And a tight pre-shift briefing — today’s risks, who owns what, when to escalate — beats a long one, because people actually remember it.

The catch: a checklist only helps if it holds the load-bearing items. Spend your slots on cosmetics and it’s theater.

How it works

The rush is a simple queue: orders arrive, baristas serve them. When a prep item is skipped, that station slows down — service falls behind arrivals and the wait climbs. Here is the logic the simulator runs each minute:

capacity(t) = base_speed - (sum of drags from every prep item that got skipped)
queue(t+1) = queue(t) + orders_arriving(t) - orders_served(t)
wait(t)     = queue(t) / capacity(t)

# A skipped item's drag is active for the whole rush — one slip at 7am
# is still costing you at 8am. That's why prep, not hustle, sets the day.

from memory : each item is remembered ~55% of the time under load
with a list : listed items are done every time; the rest still ride on memory
a runbook   : doesn't prevent the failure — it shrinks its drag from 0.50 to 0.12

Notice the runbook line: it doesn’t stop the card reader from dropping. It makes the response cheap, because you rehearsed it. That is the whole point of a runbook.

When to use it

Watch out for

• A checklist full of cosmetics. Watering the plants doesn’t survive a rush and doesn’t need to. Every slot you spend on tidy-up is a load-bearing item left on memory.
• Treating a checklist as a to-do list. It’s a verification tool — a backstop against the slip you don’t notice — not a plan of the day.
• A runbook that’s never rehearsed. A response you read for the first time mid-incident isn’t rehearsed — the drag stays high. Practice it cold once.
• The marathon briefing. Fifteen minutes of everything drowns the two things that matter today. If it doesn’t name a risk, an owner, or a trigger, cut it.
• Blaming the person who forgot. Under load, forgetting is normal — that’s the premise. The fix is a better backstop, not a sterner talking-to.

Worked example

An interviewer asks: “Your on-call keeps getting paged for the same disk-full alert at 3am. What do you do?” A weak answer says “I’d be more careful.” A strong one reaches for these three tools. First, a runbook: if disk > 90%, then rotate logs on host X and page the owner if it’s still climbing in ten minutes — so the half-asleep responder executes instead of investigates. Then a checklist line in the deploy that verifies log rotation is on, so the alert stops recurring. And a note in the shift briefing: “host X is close to full tonight, here’s the runbook.” Same three moves, whether it’s a café or a data center.