Somebody on your team did the thing differently and it worked. Not as well as you'd have done it — differently, and fine.
And you had a reaction. Not a big one. A small internal note that it wasn't quite right, followed by a decision to say something, or a decision not to say something and to check the next one more carefully.
That reaction is worth examining, because most of the time it isn't about quality. It's about unfamiliarity, and the two feel identical from the inside.
The comforting lie
Founders love the comforting lie that only we can do things the right way. It's comforting because it's flattering and because it justifies everything — the review you're still doing, the decision you're still making, the client you still handle personally.
But the right way is really just the way we've always done it. It's ego disguised as responsibility and control dressed up as quality assurance.
The uncomfortable part isn't that the standard is fake. It's that some of it is real, and you can't currently tell which.
Because you genuinely do know things. Some of your standards were paid for expensively — a client lost, a project that went badly, a mistake you'll never repeat. Those are real, they're valuable, and abandoning them would cost the business.
The problem is they're stored in the same place, in the same format, as fourteen preferences you picked up by accident. Both feel like the right way. Neither is written down. So they can't be separated, and the practical consequence is that you have to hold all of them yourself, forever.
The audit
Take the next five corrections you're about to make and run each through three questions.
Would a client notice?
Not would you notice — would the person paying notice, and would it change their experience.
An enormous share of founder corrections fail this immediately. Structure of an internal document. Order of steps that produce the same output. Which tool something was done in. Phrasing in an email that was perfectly clear.
If a client wouldn't notice, the correction is about your comfort. That doesn't make it worthless — you're allowed preferences — but it does mean it isn't a standard, and it shouldn't be enforced as one.
Can I name what went wrong when it was done the other way?
A real standard has a history. Something happened. A client was upset, a deadline slipped, an error got out, and the rule exists to stop it recurring.
If you can name the incident, it's a standard and you should write it down immediately — including the incident, because the reason is what makes it survivable when circumstances change.
If you can't name anything and the answer is it's just better, that's a preference. It might be a well-founded one. It isn't a standard, and it can't be taught.
Would I have accepted this from myself on a busy Thursday?
The sharpest of the three, and the least comfortable.
Compare the work to the version you actually produce under real conditions — not to the version you'd produce with unlimited time and full attention. Founders reliably compare their team's real output to their own idealized output, and that comparison has no honest answer.
Run these on five corrections and expect roughly one to survive. That ratio is normal and it's the point — you're not lowering your standards, you're finding out how many you had.
What the unexamined standard costs
Nothing can be taught. A standard that exists as a feeling can only be transmitted by correction, one instance at a time, forever. Your tenth correction is the same effort as your first, because nothing accumulated. That's not a training problem — it's a specification problem.
People stop trying things. If quality is defined by whether the founder likes it, and the founder's preferences are unpublished, the safest move is to do it the way you did it last time and check before deviating. That's how you get a team that waits for permission, and it isn't a hiring miss.
You can't improve. A process nobody's allowed to vary is a process that can't get better. Every improvement in a business starts as somebody doing it differently — and if all deviation reads as error, you've closed the only channel improvement travels through.
You stay in the loop permanently. The most expensive cost. Work can only be handed over to the extent that good is describable. Everything you can't articulate is work only you can approve, which means it's work that will always route through you.
Your culture is only as high-agency as the systems allow.
Write down the survivors
The output of the audit is a short list — three to seven criteria per deliverable type, and short is doing real work here.
Two properties make them usable.
Binary. Is the writing clear isn't a criterion, it's a taste question wearing a checkbox, and two reviewers will disagree. Every criterion needs an answer two competent people would give identically. Does it include the named sections. Are the figures traceable to a source. Has it been through the check that caught last quarter's error.
Derived from real failures. Go back through the last twenty things that went wrong at a client and ask, for each, what check would have caught it. That produces a list that's short, specific and defensible — and it's why generic quality checklists never get used. They weren't derived from anything anybody remembers.
Then a rule that keeps them honest: criteria have an owner and a review date. A standard that never changes stops reflecting the work, and a quarterly pass asking what got through, and what would have caught it is what keeps the list alive rather than archaeological.
What to do with the preferences
Don't discard them. Just stop enforcing them as standards.
There's a legitimate version of preference in a business — the house style, the way we talk to clients, the shape of our documents. Those are worth having and they're worth being consistent about.
The difference is how they're transmitted. A standard is a criterion you can check. A preference is transmitted through examples: here are twenty things I approved, here's what they have in common, here are three things we never do.
That distinction matters because examples accumulate and corrections don't. Twenty examples teach a preference to everybody who joins for the next five years. Twenty corrections teach one person, once each, and leave nothing behind.
What to do with the corrections you decide not to make
There's an awkward gap after the audit. You've decided that three of the five corrections were preferences, so you're not going to make them — and the work still isn't how you'd have done it.
Two options, and only one of them works.
The one that doesn't: say nothing and let it go. That sounds like the mature choice and it produces a slow accumulation of things you're quietly unhappy about, which eventually surfaces as a general sense that quality is slipping, delivered as vague feedback nobody can act on.
The one that works: say it explicitly as a preference. I'd have done this differently — I'd have put the summary first. That's a preference, not a standard, and I'm not asking you to change it. I'm telling you because over time you'll want to know how I think about this.
That distinction, said out loud, does three things. It gets the observation out of your head so it doesn't accumulate. It teaches the preference through an example rather than through a correction. And it tells the person, unambiguously, which category the feedback is in — which is the single most useful thing you can give somebody who's trying to work out what matters here.
Do that consistently for a quarter and people stop guessing. They know which of your reactions are load-bearing, which is exactly the knowledge that lets them act without checking.
The reframe that makes it possible
The reason this audit is hard isn't intellectual. It's that giving up the right way feels like giving up caring about quality.
It's the opposite. Enablement isn't about trusting people first — it's about trusting your systems enough that people can succeed inside them. A standard living in your head isn't a system, it's a bottleneck with good taste, and it protects quality only as long as you personally look at everything.
Writing it down is what makes the standard survive you being busy, and being busy is the condition under which quality actually gets tested.
The highest form of leadership isn't doing everything yourself. It's creating the conditions that let other people do their best work.
That's what the Enablement pillar means by environment. Not a culture of trust — a set of conditions where somebody can know, in advance, what good means here, and produce it without asking.
Five corrections, this week
Take the next five things you're about to correct. Three questions each. Write down the ones that survive.
You'll find fewer than you expected, and the ones you find will be the most valuable things in your business to have written down — because they're the ones that were paid for.
If the standards are one part of a broader pattern — the decisions, the approvals, the knowledge that only exists in your head — fixing them individually moves the bottleneck rather than removing it. The diagnostic names which constraint is actually binding, in writing.
Get The OPERATE Report →