Back to blog

The One-Page Business Doc

Most operations documents are a second company.

You start with a handbook. Then someone adds an SOP. Then there’s a process wiki. Then a template library. Then a meeting about whether the templates reflect the current process. Then a retrospective on whether the retrospective format is still working.

This is meta-work. Work about work. And it compounds the same way real work does — quietly, incrementally, until one day you realize the business has two layers and the bottom one is getting less attention.

Why the meta-work layer keeps growing

It accretes because documentation feels responsible.

Creating a process doc feels like diligence. Updating the wiki feels like stewardship. Holding a sync about the sync format feels, somehow, like care. None of it is negligent. But all of it exists in a layer above the actual output — and that layer doesn’t produce anything except the sensation of being organized.

The problem compounds when the layer becomes load-bearing. When you can’t make a decision without referencing the decision framework doc. When new people need to read the onboarding guide before they can read the team handbook before they can read the project brief. When the documentation system has its own documentation.

That’s when meta-work stops being overhead and starts being the actual operation.

What one page actually fixes

The one-page business doc isn’t about minimalism for its own sake. It’s about removing the gap between the work and the record of it.

When that gap exists — real work happening here, a documentation layer tracking it over there — the docs will always drift. Either someone maintains them as a second job, or they go stale. There’s no third option.

One page collapses the gap. The doc becomes part of the work, not a shadow of it. Updating it isn’t a separate task you remember at the end of the week. It’s how you finish the thing.

In practice, that means one place that contains:

  1. What’s actually happening — not what the roadmap said would be happening
  2. Who owns what — in plain language, not a RACI matrix
  3. What’s blocked — owned by a name, with a clear unblocking condition
  4. The last few decisions that changed direction — not a log, just the ones that moved things

That’s the whole operation. If something doesn’t fit on this page, it either doesn’t need to be tracked — or it needs to happen first, so it can be summarized here afterward.

The test

Could someone run this operation if this document didn’t exist?

If yes, the doc is useful scaffolding. You’re fine.

If no — if institutional knowledge has migrated from people into documents, and from documents into documentation systems — you’ve built a second layer that now depends on its own maintenance. The tail is wagging the dog.

The goal is a doc that’s easy enough to keep current that letting it drift feels worse than updating it. When that’s true, you’ve removed the second company. One layer of work, one layer of record — and nothing in between.


The businesses that run cleanly aren’t the ones with the best documentation systems. They’re the ones where the people doing the work and the record of the work are close enough that you can’t really tell them apart.

That’s the bar. Everything else is overhead in a costume.