You know the speech. A new quarter starts. The slide says "Ownership. Quality. Pace." Somebody senior tells the room how much they believe in you. People clap.
Then at 3am on Tuesday the pager goes off, and the engineer holding it has no idea where to start.
The speech didn't help her. It was never built to.
Garry Ridge, the former CEO of WD-40 Company and a guest on my podcast Corey-osity Unleashed, boils it down to one line: give people the playbook, not the pep talk. Coaches don't wing it. They follow a system.
I agree with him, and I think most tech leaders get this backwards. We spend hours polishing the all-hands deck and minutes on the documents our teams use when things go wrong.
Pep Talks Change Feelings. Playbooks Change Behaviour.
A good pep talk lifts how people feel about a goal. It does nothing for what they do when the goal meets reality.
Psychologists have studied this gap for decades. Peter Gollwitzer and Paschal Sheeran pulled together 94 independent tests in a 2006 meta-analysis. Their starting point: a strong goal intention does not guarantee you reach the goal. People stall when they hit problems mid-stream.
What helped? Spelling out the when, where and how in advance. They call it an implementation intention: "If situation Y happens, then I will do X." Across those 94 tests, the effect on goal attainment came out at d = .65, which the authors describe as medium to large.
Read the format again. "If this happens, do this." You are reading a one-line playbook.
A pep talk gives your team the goal intention. A playbook gives them the if-then. One without the other leaves people fired up and stuck.
Google Measured the Cost of Winging It
Engineers love to believe the best people improvise their way out of trouble. Google's own Site Reliability Engineering team tested the hero myth and wrote down what they found.
In the introduction to the Google SRE book, they say recording best practices ahead of time in a playbook produces roughly a 3x improvement in mean time to repair, compared with "winging it."
Three times faster. Same engineers. Same systems. The only difference was a document written before the fire started.
They go further: "The hero jack-of-all-trades on-call engineer does work, but the practiced on-call engineer armed with a playbook works much better."
They also say no playbook replaces smart engineers who think on the fly. I like the honesty. The playbook doesn't remove judgment. It removes the first twenty minutes of panic, so judgment has room to work.
Surgeons Didn't Lack Motivation Either
If you think checklists are for juniors, look at medicine.
In 2009, a team led by Alex Haynes published a study in the New England Journal of Medicine on the World Health Organization's 19-item Surgical Safety Checklist. Eight hospitals in eight cities took part, from London and Seattle to Ifakara in Tanzania. They tracked 3,733 patients before the checklist and 3,955 after.
The death rate fell from 1.5% to 0.8%. Inpatient complications fell from 11.0% to 7.0%.
The study design compared before and after, so the authors say the checklist was "associated with" the drop. Fair. Still, those are big numbers from a single sheet of paper.
A few years earlier, Peter Pronovost's team ran a similar effort across intensive care units, mostly in Michigan. Their 2006 NEJM paper covered 103 ICUs and 375,757 catheter-days. The mean rate of catheter-related bloodstream infections dropped from 7.7 per 1,000 catheter-days to 1.4 after 16 to 18 months. The authors report a reduction of up to 66%, held for the full study period.
Nobody in those operating theatres or ICUs needed a motivational speech. Every surgeon and nurse wanted the patient to live. Desire wasn't the gap. The steps were.
Your engineers are no different. They want the release to go well. They want the outage short. Telling them to care harder won't fix a missing step.
What a Useful Playbook Looks Like
Most teams already have a "runbook" somewhere. Usually it's a wiki page last edited by someone who left in 2022. Here's what separates a playbook people use from one they ignore.
Write it before the fire
Nobody writes good instructions at 3am. Pick the situations your team dreads most and write the steps on a calm Wednesday afternoon.
Start with the trigger
Every section opens with "If you see this..." Copy the Gollwitzer format. The alert name, the error message, the customer complaint. Make the trigger easy to match.
Keep it short enough to use under stress
The WHO checklist runs to 19 items. Not 190. If your playbook needs a table of contents to find step one, it's a manual, not a playbook.
Let the people who run it write it
Your on-call engineers know where the traps are. Hand them the pen. I wrote about this in Nobody Sabotages a Plan They Helped Write, and it applies double here. People follow steps they designed.
Rehearse it
Google pairs its playbooks with a role-play exercise it calls the "Wheel of Misfortune." A playbook nobody has practised is a theory. Run a drill once a month. Time it. Fix the steps where people got stuck.
Update it after every use
Every incident review should end with one question: what would we change in the playbook? If the answer is "nothing" five times in a row, nobody is reading it.
It's Not Only for Outages
Incidents make the easiest case because the cost shows up on a dashboard. The same logic holds everywhere your team repeats work under pressure.
- Onboarding. A new hire's first week shouldn't depend on which colleague happens to sit nearby.
- Releases. If a release only goes smoothly when one particular person runs it, you don't have a process. You have a hostage situation.
- Hiring loops. Interviewers who wing it ask different questions and grade on gut feel. A shared scorecard is a playbook.
- One-to-ones. A short list of questions you ask every time beats a weekly status update dressed up as coaching.
When a system only works because of heroes, the system is broken. I made the same argument in Your Engineers Aren't Fragile. Your System Is. A playbook is one of the cheapest ways to stop leaning on heroes.
The Pep Talk Still Has a Job
I'm not against inspiration. People need to know why the work matters, and a leader who never explains the why ends up with a team of box-tickers.
The pep talk answers "why." The playbook answers "how." Trouble starts when leaders deliver the why with passion and leave the how to luck.
Garry built a culture at WD-40 on patient, repeated habits. I wrote about his crockpot view of culture in Microwaves Don't Build Culture. Crockpots Do., and about his daily self-check in Did I Do My Best Today? Neither one is a speech. Both are routines written down and repeated until they stick.
Your Move This Week
Pick the one situation your team dreads most. The 3am database alert. The release with too many moving parts. The new starter who arrives Monday.
Sit down with the people who handle it. Write the first page together. Run it once as a drill before Friday.
Then look at your next all-hands agenda. What would happen if you spent half of it walking the team through the playbook instead of the vision slide?