Your team has a 47-step deployment playbook. The first three steps are read carefully. Steps 4-30 are skimmed. Steps 31-47 are skipped entirely. Six months in, when something breaks at step 39, the post-mortem says "the playbook wasn't followed."

The post-mortem is right. The playbook also wasn't going to be followed. Long playbooks reliably degrade into shorter de-facto checklists in the head of whoever's running them. The question is whether your written version matches the de-facto one or doesn't.

Most teams write the long version aspirationally and the team uses the short version operationally. The gap between the two is where bugs live.

The data: where attention drops off

Studies of checklist adherence in clinical settings (which is what most of the rigorous research is in) find sharp dropoffs. A 5-item pre-flight checklist gets ~95% adherence. A 25-item one drops to under 50%. A 50-item one drops below 20%, and the items that get skipped aren't random — people skip the middle.

Software engineering doesn't have rigorous data on this, but the pattern reproduces. Watch a team execute a long playbook. Steps 1-3 are read. The middle is glossed. The last 1-2 are remembered because they're the "verify" steps people actively want to do.

Optimizing for actual behavior means writing for a 5-step format and putting only what's actually load-bearing in those 5 steps.

The compression rules

Three rules that tighten any playbook to 5-7 steps without losing safety:

1. Merge adjacent verification steps into the action that needs them.

Bad:

3. Run database migration
4. Verify migration succeeded
5. Check new column exists

Good:

3. Run migration; verify with SELECT column_name FROM information_schema.columns WHERE column_name='status'

The verification is part of the same atomic action. Splitting them suggests they're two separate decisions; they're not.

2. Bundle setup into the first step's preconditions, not as separate steps.

Bad:

1. SSH into server
2. cd to project directory
3. Pull latest changes
4. Activate virtualenv
5. Run deploy script

Good:

1. From project directory on server (with venv active and main branch pulled): run ./deploy.sh

The first four "steps" are environment, not actions. Capture them as the precondition.

3. Move "if-then" branches into linked sub-runbooks, not inline.

Bad: a 47-step playbook full of "if X then jump to step 23, else continue to step 19"

Good: a 5-step main path with [see also: rollback runbook] links for branches.

The reader executes the main path linearly. If something diverges, they consult the linked runbook for that branch. The two mental modes — "happy path execution" and "something's wrong, pivot" — get separate documents.

What a compressed deploy playbook looks like

## Deploy production

PRECONDITIONS
- main branch pulled, CI green
- VPN connected, AWS profile = prod
- Slack #deploy channel open

THE STEPS

1. Tag the release
   git tag -a v$(date +%Y.%m.%d.%H%M) -m "Release"
   git push --tags

2. Run the deploy script and watch logs
   ./scripts/deploy.sh prod 2>&1 | tee /tmp/deploy.log
   Watch for any line containing ERROR or FAILED.

3. Verify health
   curl https://api.example.com/health  # expect: {"status":"ok"}
   curl https://api.example.com/version # expect: matches the tag

4. Smoke-test the canary route
   ./scripts/smoke-test.sh prod
   All assertions should pass.

5. Post in #deploy: "prod deploy v<tag> complete, smoke tests green"

ROLLBACK: see rollback-runbook.md

That's the entire deploy. Five steps. Each has a verification baked in. Sub-runbooks handle the branches. The 47-step version compressed without losing meaningful safety.

The thing that makes compression work

The skill isn't writing fewer words. It's diagnosing what's load-bearing.

A long playbook contains four kinds of content:

Required actions that materially affect the outcome (5-7 of these usually)
Verification steps for those actions (merge these into the actions)
Setup/preconditions (move to a precondition list)
Edge case branches (link to sub-runbooks)

The compression task is sorting the long playbook into those four buckets, then expressing each bucket in its appropriate place. The result is structurally clearer, not just shorter.

If you struggle to identify the 5-7 load-bearing actions, that's a signal that your team doesn't actually agree on what's load-bearing. Worth resolving before you write anything.

When long playbooks ARE the right format

Three contexts where length is justified:

First-time setup that you'll do once and never again. Length is fine because frequency is zero.
Compliance / audit requirements that require documenting every step regardless of practical utility.
Training material for genuinely-new engineers who need the why.

For day-2 operations — the activities your team does weekly or monthly — short wins.

How this applies to AI-agent runbooks

A separate angle: if you're maintaining runbooks for AI coding agents to consume, the compression rules apply more strictly. Agents have limited context windows; long playbooks consume context that could be used for actual work. A 5-step compressed runbook plus 2-3 linked sub-runbooks is the right format for both human and agent consumption.

The agent will pull just what it needs. The human will read just what they need. The 50-step version serves neither well.

The honest objection

"But what about the rare edge cases?"

The 47-step version exists because someone's deploy went sideways once and step 39 was added in response. The instinct is correct (codify the lesson) but the implementation is wrong (insert it inline in the main path).

The right move: add the lesson as a sub-runbook (troubleshooting-deploy-step-3.md), and if step 3 frequently encounters that branch, that's the signal to redesign step 3 itself, not to bloat the main path.

Compressed playbooks aren't less safe. They're safer because they get followed. A 5-step playbook executed completely beats a 47-step playbook executed partially. Optimize for the actual behavior, not the aspirational one.