Issue #21 · Ops & Om · Health of Business series · Episode 4

or listen on Spotify · Apple Podcasts

I moved my personal account over to a team account this month. That's the whole reason I went down this hole.

I had a logistics question; the kind you ask expecting one sentence back so you can get on with your day. I didn't get back to work. I came out having found something wrong with the way my entire operation has been built.

Not a bug. Not a bad file. A structural thing, invisible from where I was standing.

Here's what we'll cover in this issue:

Here's the fork the team account put in front of me. On one side: project folders - a folder for a specific kind of job, with the documentation inside it. On the other: skills - reusable instructions that travel with you instead of living inside one folder.

So which one am I supposed to use?

The answer is one sentence, and it reorganized how I see my business. A project is a place. A skill is a procedure.

A place holds what's true about the client:

That doesn't move. A procedure is how a job gets done anywhere:

Those aren't facts about a client. They're facts about the work. They travel.

My folders were not a mess. That's the part I want you to hear. A rule I gave my team early: never start from a blank chat. So I have fifty-something folders, five or six per client, each with voice templates, sourcing rules, quality checklists. More documentation than most businesses my size have.

Every folder of instructions I wrote felt like maturity - one step further from being the guy who holds the whole business in his head. I was right about the direction and wrong about what I was building.

Because you can sort any line of documentation in about four seconds. One question: is this true about the client, or is this true about the job?

Try this prompt:

Take the simplest rule I own: how we write a subject line.

Every client I write email for has one. The first thing somebody sees is the difference between getting opened and getting deleted, especially now that half your list has an AI clearing their inbox.

The rule isn't complicated. Keep it short. Curiosity gap. A number or a concrete detail. Don't run the same play every time. Five options, tested, and I don't ship anything scoring under 90. It works - our average open rate runs 55–70%, and that includes brands, not just individual practitioners.

Here's the problem. That rule lived in the project folder instructions. Seven clients, at least two places each where subject-line rules show up. Fourteen copies.

So the day I decide the standard is ten options instead of five, I have to find fourteen sections in fourteen folders and change all of them.

And I've done exactly that. Started the sweep, got pulled into something else, told myself I'd finish tomorrow. Tomorrow never came. Months later: why is this client's output worse than the others? Because that's one I never got back to.

This compounds in two directions.

Per client: at two folders it's annoying; at ten, every improvement costs ten edits, so improvements stop and the business freezes at whatever quality it hit when it was small.
Per rule: once you see it in subject lines, you see it in sourcing, QA, onboarding - three deferred migrations at once.

And it isn't a software problem. The tools just made it visible faster. Same thing happens in Notion, in Google Docs, in a three-ring binder.

Try this prompt:

One of my folders went from nine pages to twelve lines. Nothing was deleted. Every rule still applies, it just lives in one place instead of six.

And there's one subject-line rule. When I get better at subject lines, I get better at them everywhere, the same afternoon, without remembering anything. That's the actual win. Not a tidier folder; an improvement that only has to happen once.

Run straight at this and you'll consolidate everything into one beautiful non-repeating set of instructions, and you will break something.

I have one rule I deliberately keep in three places. It's about how a specific person gets described in copy, and getting it wrong has burned us before. Move it behind a pointer and I've invented a new way to miss it: somebody's in the folder, the folder points elsewhere, they don't follow it, and the rule quietly doesn't get applied. For most rules that's an inconvenience. For that one it's a phone call I don't want to make.

So it stays in three places. When it changes, I change it three times, on purpose.

Two questions. I only duplicate when both answers are yes:

If everything's an exception, you've rebuilt the mess with extra steps. If nothing is, you're being tidy at the expense of being right.

One more practical thing. This one cost me a wrong turn. My instinct was to fix it one folder at a time, most important client first. That's wrong: you cannot see duplication one folder at a time. The whole point is spotting the same thing written six ways, and you can't do that looking at one. Go folder by folder and you'll name something in folder three, reach folder thirteen, realize it should have been two things, and now five folders point at the wrong name. That's not migration. That's rework.

So lay them all out first. Mine was a table: every rule a row, every folder a column. The second it was on one screen, the duplication was just visible.

But don't map everything, design the perfect system on paper, and build all of it. Map the whole thing, build exactly one, run real work through it. If the map is wrong, and part of it will be, you lost an afternoon instead of a month.

Try this prompt:

If you look at your setup and think this is way bigger than an afternoon; that's the conversation. I come in, find the work that shouldn't need you sitting in it, and build the thing that takes it off your plate. It starts with twenty minutes and picking the one system worth building first.

Rather do the fifteen-minute version yourself? Open two places where you've documented the same process and read them against each other. Most people find a disagreement in the first five sentences -hit reply and tell me what you found.

P.S. — The whole episode comes down to one question. When you improve how you do something, how many places do you have to go change it? If the answer is more than one, you don't have a documentation problem. You have a copies problem. Watch on YouTube →