Operations is just good habits, written down.
"Understand why our operations handbook exists and what it protects."
Why this exists
Most agencies fail because they cannot repeat what worked, not because they lack talent. Operations makes success boring and predictable instead of heroic and accidental. Without standard operations, every project starts from scratch.
Operational Flow
Client Communication: Talk directly and in writing without using shields.
Project Kickoff: Start projects correctly to avoid fixing them later.
Scoping Work: Estimate realistically so timelines are promises, not wishes.
Retrospectives: Learn from what happened to stop making the same mistakes.
Tooling: Use our standard tools consistently to maintain a shared history.
What good looks like
- A new teammate shadows one project and knows exactly how to run the next one solo without asking.
- Clients describe working with us as unusually calm. Problems still exist, but we surface and resolve them quickly.
- When something breaks down, the post-mortem produces a process change instead of a blame session.
What NOT to do
- Don't read these entries as permission slips. They describe defaults, not ceilings.
- Don't treat consistency as bureaucracy. Find the reason for a step before you skip it.
- Don't memorize the rules and forget the intent. The goal is shipping good work without burning people out.
Operations is the part of the agency nobody talks about at conferences. Nobody posts about their Notion setup going viral. No one gets hired because their retrospective format was excellent. But behind every project that shipped on time, communicated clearly, and left the client wanting more work, there was a process somebody thought through in advance. We wrote ours down because we got burned badly enough, early enough, that the pain made writing feel cheap by comparison.
The entries in this section are not exhaustive. They cover the things we kept getting wrong, or the things we watched other agencies get wrong. Read them as decisions already made. You do not have to relitigate them on every project. Your job is to execute, improve, and flag when something stops working. When you find a case where the handbook gives you bad advice, write a better version.