Why your operations playbook should be workflows, not essays
If your handbook is 200 pages, no one reads it under time pressure. The most useful documentation isn't a reference. It's a workflow with a stop signal.
Addy Osmani published a piece on Agent Skills this week. It's written for software engineers using AI coding agents, but buried in it is a framing every operator should steal: process over prose.
His argument: if you put a 2,000-word essay on testing best practices into an AI agent's context, the agent reads it, generates plausible-looking text, and skips the actual testing. If you put a workflow there (write the failing test first, run it, watch it fail, write the minimum code to pass) the agent has something to do and you have something to verify.
That distinction (workflows over reference, steps with exit criteria over essays without them) explains why most operations documentation doesn't get used.
The reference document trap
Pull up your business right now. How many of the following do you have?
- An employee handbook
- An onboarding doc
- A standard operating procedure for one of your core processes
- A "how we do things" wiki
- A brand guidelines document
- A customer service playbook
If you have any of them, the next question: when did anyone actually use one to make a decision?
Most operational documentation in small businesses suffers from the same problem Addy identifies in engineering documentation. It's reference material. It explains principles. It describes context. It's beautifully written. And under time pressure, when someone actually needs to make a decision, nobody opens it.
The reason is simple: reference material doesn't tell you what to do. It tells you what to think about while you do it. That's not the same thing.
What works instead
Addy's framing for engineering is: workflows with checkpoints that produce evidence, ending in a defined exit criterion.
Translated for operations:
A workflow says here's the sequence of steps to run this process. Not the philosophy behind it. Not the history of why we do it this way. The sequence. Step 1. Step 2. Step 3.
A checkpoint says here's how you know step 2 is actually done before you move to step 3. Not "use your judgment." A specific, observable thing that has to be true.
An exit criterion says here's how you know the whole workflow is done. Not "when it feels right." A specific outcome you can point at.
The difference between these two versions:
"When onboarding a new client, take the time to understand their business deeply. Document everything you learn. Build trust early. Set clear expectations."
vs.
"Step 1: Send the kickoff form (template link). Wait for response. Step 2: Schedule the 60-min discovery call. Use the discovery template (link). Step 3: Within 24 hours of the call, send the proposal doc (template link). Step 4: After signature, schedule the kickoff. Done when: signed contract is in the CRM and kickoff is on the calendar."
The first one reads like wisdom. The second one runs your business.
The other thing worth stealing: anti-rationalization tables
Addy describes a pattern where each AI agent skill includes a table of common excuses an agent might use to skip the workflow, paired with pre-written rebuttals. Examples:
- "This task is too simple to need a spec." → Acceptance criteria still apply. Five lines is fine. Zero lines is not.
- "I'll write tests later." → Later is the load-bearing word. There is no later.
- "Tests pass, ship it." → Passing tests are evidence, not proof.
His insight: AI agents are excellent at rationalization. They produce plausible-sounding paragraphs explaining why this particular task doesn't need the workflow. Anti-rationalization tables are pre-written rebuttals to lies the agent hasn't yet told.
This works for human teams too. Most operational decay isn't anyone choosing to do bad work. It's people accepting plausible-sounding justifications for skipping the parts they don't feel like doing. Some examples in operations work:
- "This client is different, we don't need the kickoff form." → Every client thinks they're different. Send the form.
- "It's just a small invoice, no need to log it in the system." → Five small things you didn't log become tax-time chaos.
- "I'll update the dashboard next week." → Stale dashboards are worse than no dashboards. Update it now or take it down.
Writing these down makes them lose their power. Once the team has explicitly agreed that "this client is different" is not a valid reason to skip the kickoff form, nobody can use it as one without being noticed.
What to do this week
Pick one process in your business that's important and a bit fuzzy. Maybe how you onboard a new client. How you handle a customer complaint. How you close out a job.
Two things on a piece of paper:
- The workflow. Not the philosophy. The actual sequence of steps, with a specific checkpoint at each one and a specific exit criterion at the end.
- The anti-rationalization list. Three to five things people on your team might say to skip a step, paired with a one-line rebuttal.
That document is more useful than 30 pages of "how we approach customer service." It's also dramatically shorter and more likely to actually get read.
Process beats prose. Workflows beat reference. Specific steps beat principles.