Recurring activities often get treated as things that "just happen." We execute them on autopilot, with quality that varies based on how we're feeling that day. A presentation to stakeholders. A client onboarding. A database migration. A difficult conversation with a team member. These aren't one-off events. You do them repeatedly. And every time, you're either applying what you learned last time, or starting from scratch.
The difference between mediocre execution and excellent execution often isn't talent or effort. It's whether you've taken what works and made it repeatable.
Your engineering team has people who conduct brilliant code reviews, run effective retrospectives, and handle production incidents with calm precision. But that expertise lives in their heads. When they're on vacation, sick, or moving to a new team, it disappears. Your team's expertise is tribal knowledge, transmitted through osmosis and luck.
Playbooks are how you can change that. For lean practitioners, this is the software equivalent of standard work—capturing your current best practice as a baseline that the team owns and continuously improves.
The Code Review Problem
Let's take code reviews. Many engineering teams do them, but they can often feel useless at best, a source for drama at worst. At least that's what I've observed across the teams I've worked with.
Here's a common pattern: A junior engineer submits a PR. It sits for two days. Someone finally reviews it with "LGTM" and nothing else. The code ships. Three weeks later, you're debugging a production issue that any experienced reviewer would have caught. The knowledge existed on your team. It just wasn't accessible when it mattered.
Another actually worse scenario: Your senior engineer does review thoroughly, but their feedback is inconsistent. One day they're meticulous about error handling. The next week they let similar issues slide because they're tired, busy, or distracted. The team never learns what "good" actually looks like because the standard shifts based on who's reviewing and what mood they're in.
This isn't primarily a people problem. It's a systems problem. You're asking humans to hold complex, nuanced quality standards in their heads and apply them consistently under time pressure. For most teams, that's difficult and often unrealistic.
What a Playbook Actually Is
A playbook is not documentation. Documentation explains how a system works. A playbook explains how to execute an activity well.
Think of it as your team's best practitioner writing down exactly what they do, in a format that anyone can follow. Not a 40-page manual. A single page with four layers:
Overview: A brief description of the activity and essential context needed before starting. What is this? When should you use it? What should you know upfront? Keep it short—three to five sentences maximum.
Quick Checklist: The essential actions, scannable in 30 seconds. Execute immediately without reading everything.
Practice Guidance: Context for the activity (what it is, why it matters, red flags to watch for), followed by a table of do's and don't's with clear reasoning. Read this when you want to understand quality, not just complete the task.
Supporting Information: Tools, templates, edge cases, escalation paths. Consult when you need to go deeper or handle unusual situations.
This is progressive disclosure—a pattern that works well for recurring tasks: start simple, go deep only when needed.
Here's what a code review playbook might look like:
## Overview
Code review is peer evaluation of code changes before they merge to production. Use this playbook when reviewing pull requests of any size. You'll need access to the codebase, ability to run code locally, and 15-30 minutes of focused time per review.
## Quick Checklist
- [ ] Read the PR description and linked issue → Context before code
- [ ] Run the code locally → Verify it works
- [ ] Check test coverage → New code has tests
- [ ] Review error handling → Failures fail gracefully
- [ ] Look for security issues → Input validation, auth checks
- [ ] Suggest improvements → Make it better, not just acceptable
- [ ] Approve or request changes → Clear next action
## Practice Guidance
**what**: Code review is quality assurance performed by peers before code merges. It catches bugs, shares knowledge, and maintains team standards.
**why it matters**: Reviews are your last line of defense before production and your primary mechanism for spreading expertise across the team.
**common gaps**: Reviews done too late (after significant work invested), reviews that focus only on style, reviews that rubber-stamp without understanding the change.
| ✓ do this | ✕ not this | why |
|---|---|---|
| Read PR description and linked issue first | Jump straight to code without context | You catch architectural issues that code-level review misses |
| Run the code locally in your environment | Review purely by reading diffs | Edge cases, performance issues, and integration problems surface when code actually runs |
| Check for meaningful tests, not just coverage | Accept tests that only hit happy paths | Tests that don't catch real issues give false confidence |
| Look for graceful error handling | Let failures bubble up as generic 500s | Users and ops teams need actionable feedback when things go wrong |
| Suggest improvements even when code works | Rubber-stamp with "LGTM" | Reviews are coaching moments that level up the whole team |
One page. Scannable in under a minute. The table format makes it immediately clear what good looks like versus what to avoid, with the reasoning right there.
Why This Works
In my experience, process documentation often fails because it's either too vague or too verbose. Vague guidelines like "write good tests" don't help anyone. Verbose 20-page standards documents never get read.
Playbooks work because they respect how people often operate under time pressure:
When you're executing, you often don't want to think deeply. You want clear steps. The quick checklist gives you that.
When you're learning, you need to understand the reasoning. The practice guidance explains what good looks like and why it matters.
When you're stuck, you need specific help. The supporting information provides tools, templates, and escalation paths.
One document, three use modes. You meet people where they are instead of forcing them to wade through everything to find what they need.
The other reason playbooks work: They're living documents. Version 1.0 is based on your current best understanding. You execute it in real situations. You notice what works and what doesn't. You refine it. Version 1.1 is better. After a year, you have Version 2.0 that represents genuine team wisdom instead of one person's initial guess.
Where playbooks don't work well
This approach fits recurring activities with some variability. Tasks where you need consistent quality but also judgment. It's less useful for novel problems where you're figuring things out for the first time, or highly creative work where rigid structure can constrain thinking. If the activity changes significantly each time, a playbook becomes a constraint rather than a scaffold.
Getting Started: Your First Playbook
Pick one recurring activity your team does inconsistently. Not your most critical process. Not your most complex. Just something that happens regularly where quality varies based on who's doing it.
Code reviews are perfect. So are incident response runbooks, onboarding checklists, or deployment procedures. The specific activity doesn't matter. What matters is choosing something real that you'll actually use.
Then follow this structure:
Step 1: Write the overview. In three to five sentences, describe what this activity is, when to use it, and what someone needs before starting. Keep it concrete and actionable.
Step 2: Capture the checklist. What are the essential steps your best practitioner takes every time? Write them as action-outcome pairs: "Do X → Get Y." Aim for 5-10 items. If you have more, your scope is too broad.
Step 3: Add practice guidance. Start with context: what is this activity, why does it matter, what common gaps do people fall into? Then create a simple table with three columns: ✓ do this | ✕ not this | why. One row for each critical practice. Keep each cell to one sentence. The table format makes it scannable and highlights the contrast between good and bad practice.
Step 4: Identify supporting information. Are there templates, tools, or escalation paths people need? Link to them. Don't embed them in the playbook.
That's it. Write it in markdown, put it in your team repo, and use it next time the activity comes up. Timebox this to 45 minutes. Version 1.0 doesn't need to be perfect. It needs to exist.
What Changes
In teams where playbooks stick, here's what typically changes over time:
New team members ramp up faster because they can execute at quality without asking 20 questions. Your experts stop being bottlenecks because their knowledge is documented and reusable. Quality becomes consistent because the standard is explicit instead of implicit. Your team develops a shared vocabulary for what "good" means in different contexts.
And perhaps most importantly: Your team's expertise becomes reusable. It becomes your team's baseline.
Your code reviews, your incident responses, your retrospectives, your stakeholder presentations. Any recurring activity where quality matters deserves the same level of intentionality. Not because process is valuable in itself, but because the outcomes of those activities matter too much to leave to chance.
Start This Week
Choose one activity. Write one playbook. Use it three times. Refine it based on what you learn.
That's how you turn experience into practice, and practice into capability. Experiment with the format, adapt it to your team's needs, and share what works. Your insights matters and help others build better practices too.