When Should You Replace a Policy With the Why?
Whenever the decision calls for judgment and a mistake can be put right. There, a short explanation of what you're protecting, with a clear spending limit, lets your team handle cases no rule anticipated. Where an error is permanent or lands on someone outside the company, a written rule should stay in place.
How many of your written rules exist because of one bad Tuesday?
Most policies are scar tissue. Something went wrong once, someone was annoyed, and a rule got written to make sure it couldn't happen again. The rule outlives the incident and eventually outlives everyone who remembers it. What's left is a sentence nobody can explain, which people either obey into a bad outcome or quietly learn to ignore. Ignoring one rule teaches them that rules are optional, and that lesson doesn't stay with the one rule.
My position, which some owners find uncomfortable, is that you should write fewer of them. For any decision that involves judgment, such as how to treat a customer, what to do when the schedule slips, or when to spend a little money to fix something, a paragraph explaining what you're protecting will usually beat a page of conditions. For a smaller set of things, rules are exactly right, and the skill is knowing which is which.
When should you keep a hard rule?
I'd keep hard rules for anything where a mistake can't be undone or where the cost lands outside the business. Safety procedures. Legal and tax obligations. Handling cash and access to accounts. Anything a regulator or insurer will ask about. In those areas you don't want anyone exercising creativity, and you don't want them to need to understand your reasoning in order to comply. A lockout step doesn't need buy-in.
Everything else falls into a gray area, and this is how I sort it:
Can't be undone, or harms someone outside the company
What I'd write: A rule, followed exactly
Why: Judgment is a risk here, not an asset
Small money, reversible, happens often
What I'd write: The reason plus a dollar limit
Why: Volume makes rules impossible to keep complete
Customer tone and how to make things right
What I'd write: The reason plus two or three example cases
Why: The situations are too varied for steps
Brand new hire, first 60 to 90 days
What I'd write: Rules, with a stated plan to loosen them
Why: Judgment needs context that takes time to build
Something that has gone wrong twice the same way
What I'd write: A short checklist
Why: Repeated failure is evidence a rule is earning its place
The fourth case is the one people skip. I'll come back to it, because it's where the "just give people the why" idea breaks if you apply it carelessly.
How did one service company rewrite its complaint policy?
A service company I worked with had a make-it-right policy for customer complaints. It had grown over a few years into eleven lines: refunds over a certain amount needed the owner, redo work needed a manager's sign-off if it exceeded two labor hours, discounts could not be combined, repeat complaints within ninety days went to the owner, and so on. Every line had a story behind it. The practical result was that anyone facing a real complaint messaged the owner anyway, because the policy didn't quite cover the case in front of them, and nobody wanted to guess wrong.
We replaced it with this:
When a customer isn't happy, our goal is that they'd still call us next time. Fix what we got wrong, at our cost, quickly. Don't pay for things that weren't our doing, and don't let one customer's frustration turn into a precedent we can't afford for everyone else. You can spend up to $150 on a fix without asking me. Over that, call me the same day. Write every case in the log with one line on what you decided and why.
Each logged reason makes the next call easier, the way the ruling log does in why your best employee keeps bringing you problems.
The first version of that paragraph didn't have the dollar figure. It said "use good judgment and remember we're a small business," and I thought that was enough.
Three weeks later, a newer team member gave a full redo, a bit over $400 in labor and materials, to a customer whose complaint turned out to be that the paint color looked different in their living room than it had on the sample. She wasn't wrong to want the customer happy. Our paragraph had told her to, and she had no way of knowing that a color preference sat on the other side of the line. That was our failure, not hers.
So the revision added two things the original lacked: a number, and a pair of examples. One was a case where we'd redo the work without a second thought (a seam that failed because of how we installed it). The other was a case where we wouldn't (a change of mind about color after the job was approved), plus what we'd say to the customer instead. People needed to see where the line was before they could reason about where it was.
How do you test whether a why is clear enough?
Before I trust a rewritten policy, I take three situations that nobody has asked about yet and give them to someone who wasn't part of writing it. I ask what they'd do and why. If they land where I'd have landed on two of three, the explanation is good enough to ship. If they land on all three differently from me, the paragraph isn't doing its job, and the fix is nearly always more examples or a missing limit, not more rules.
For the make-it-right policy, the test turned up a gap we hadn't seen. Two people disagreed about a repeat customer who had complained twice in two months, and about whether a complaint made after the warranty window counted as "our doing." The old eleven-line policy had an answer to the first one and none for the second, and after the rewrite we had an answer to neither.
We ended up adding a short "call me first" list with two items on it. It was a partial retreat from the idea, and I think the final version is better for it. Treating a principle as a complete replacement for rules is another way of being rigid.
Should new hires get rules or reasons?
The fourth of those cases deserves a longer look. A new hire has no reference points. You say "protect the customer relationship but watch our margins," and they have no feel for how much margin we can spare or what a relationship is worth to us. A rule gives them somewhere safe to stand while they build that feel.
My approach is to give new people the rules, tell them plainly that the rules are temporary, and say what will change. "For your first two months, anything over $50 comes to me. At the end of it, we'll go through the log together and raise your limit based on what we see." That turns a restriction into a schedule. It also makes the rule a way of teaching, because the log review is where the reasoning gets passed on, and that's the part a manual can't do.
The right time frame probably varies by kind of work. Sixty days has served me well for customer-facing decisions in service businesses, and I'd guess it needs to be longer for work with more technical depth. Pick a date, write it down, and keep to it, or the training wheels never come off.
What does an unexplained rule tell your team?
There's one more reason I lean toward explaining. A rule that hasn't been explained carries a message about trust: I don't believe you'd get this right on your own. Sometimes that's accurate, and sometimes it's the only responsible thing to say. But if the message is broadcast through forty small rules, the good people hear it loudest. The ones who would have made sound calls conclude that sound calls aren't wanted here, and either stop making them or leave.
An explanation says something else: this is how I'd be thinking if I were in your seat. You're sharing context, which is what an owner has more of than anyone and the thing most owners ration.
Where should you start rewriting?
Look at the three rules your team asks about most, or breaks most often. Both are signs that the rule has drifted from the situations it was written for. For each, write the reason it exists in two sentences, decide whether a limit would do the work of the conditions, and add a pair of example cases. Test it on a few situations you haven't discussed, adjust, and put a review date on the page. Sixty days is a reasonable start.
If you do it and the same three questions still come to you, treat that as information. Either the why isn't clear yet, or that decision really does belong to you, and it's worth finding out which.
Keeping those pages in daily use, rather than filed away, is where SOPs vs an operating system picks up.
Frequently asked questions
Who should draft the reason behind a policy?
Whoever knows why the rule exists, often the owner, and then the people who apply it should mark it up. If nobody can say why a rule exists, that is a strong hint it can go. Keep the final version short enough to read aloud at a team meeting without anyone losing the thread.
What if one person keeps landing on the wrong side of the line?
Look at the log before deciding it's a person problem. If several people misread the same case, the page needs another example. If it's one person across many cases, lower their limit for a while and review their entries together, the same way a new hire's limit gets raised over time.
Where should a policy with its reason actually live?
Put it where the decision happens, such as the job board or the complaint log, and keep a copy in the handbook. A reason buried in a handbook nobody opens works about as well as an unexplained rule, because people can only use the reasoning they can see at the moment they decide.
What rule does your team ask about most?
If one rule keeps pulling you back into decisions, a Planning Call can turn it into a reason, a limit and two example cases your team can use.
