The Rule Outlived Its Reason and You Are Still Enforcing It

The story goes like this. Five monkeys in a cage, a ladder in the middle, bananas at the top. Every time a monkey climbs, the whole cage gets sprayed with cold water. Soon any monkey that reaches for the ladder gets pulled down by the others. Then the researchers swap the monkeys out one at a time. Each new arrival reaches for the ladder, gets pulled down, learns the rule, and pulls down the next new arrival. In the end no monkey in the cage has ever been sprayed, and all of them enforce the rule.

No lab ran that experiment. The version with the ladder and the hose was assembled in a business book decades after a much smaller 1967 study in which rhesus monkeys learned a fear by watching other monkeys. The fable survives anyway, because every company I have walked into has a rule like that, and the people enforcing it were never sprayed.

A rule that has outlived its reason does not retire itself. People enforce it, and the enforcement gets harder as the memory gets thinner, because a rule you cannot explain can only be defended with force.

The Standard: Every Rule Has a Living Owner Who Can Say Why

Plato, late in his life, in the Laws, describes two kinds of doctor in a Greek city. The slave doctor treats slaves. He hurries from patient to patient, gives orders the way a tyrant gives orders, explains nothing, and moves on. The free doctor treats free citizens. He asks questions, explains the illness, persuades the patient, and only then prescribes, and the patient follows the prescription because they understand it. Plato wanted every law in his city to work the way the free doctor works, so he put a prelude in front of each one: a short passage giving the reason, before the command. A law without its prelude was the slave doctor’s way.

The Greek word nomos means law or custom, the rule that stands and gets handed down. The Greek word logos means the account, the reason you can give when someone asks why. Plato’s point in modern shape is that a rule is nomos with its logos attached. When the logos dies, the nomos keeps running, first on habit and then on force.

A living rule looks like the Linux kernel’s line-length limit. For decades, kernel code was held to 80 characters per line, and the reason was concrete: the terminals of that era showed 80 columns, and a longer line wrapped or vanished. In 2020 Linus Torvalds raised the warning threshold to 100 for kernel 5.7, and the change came with its reason stated: the narrow terminals were gone, and the old limit was now making people break lines in ways that made the code worse. The rule had an owner who knew the reason, saw the reason expire, and retired the rule with a sentence anyone could read.

That is the standard: a reason, an owner, a date, and a condition under which the rule goes. The rule and its reason travel together, so the person who inherits the rule inherits the argument, and can end it when the argument ends. Following a rule on trust is fine under that standard. A new engineer on day three does not need the whole story before obeying the deploy freeze, as long as the trust points at a living owner who can tell the story when asked. It turns into force only when the trust points at nobody.

The Gap: Rules Nobody Left Was Sprayed For

An incident happens. Someone in the room writes a rule to stop it happening again. The rule gets written down, and the reason does not, because the reason is obvious to everyone who lived through the incident. Two years later, the room has turned over. New people learn the rule as a rule, the thing you get pulled down for. They enforce it because they were told to, and they enforce it harder than the original authors did, because the authors knew where the edges were and the inheritors only know that crossing the line is punished.

Python’s style guide caps lines at 79 characters, a number that came out of the same terminals, and there are teams today running a linter that fails the build at column 80 where nobody has ever seen one of those terminals and nobody can say why 79. There is a Friday deploy freeze put in after one bad Friday, whose root cause was fixed the next quarter, still standing three years later and costing a day of shipping every week. There is a two-approver rule on every pull request, added after one bad merge, now applied to a one-line copy change. There is a runbook step that says to restart a server that was decommissioned last year, and the on-call engineer runs the step, watches it fail, and moves to the next line, because the step is in the runbook. Each of these was a fix once. Each is enforced now by someone who was never in the room.

G. K. Chesterton wrote in 1929 about a fence across a road. The first reformer says it serves no purpose, clear it away. The second reformer says go and find out why it is there, and when you can tell me, I may let you clear it. That principle has two halves. The honest half is a warning: do not tear down what you cannot explain. The abused half is the one most rulebooks live on: using the fence as a reason never to go and find out. Chesterton’s instruction was to find out, which the monkeys in the fable never do. Most teams I see are honoring Chesterton’s caution and skipping his assignment. The way to honor both halves is a deadline: an unexplained rule gets a date by which its reason is found and written down, and on that date it is either explained or retired, so “keep it while we look” cannot become the next dead rule.

The daily cost of a dead rule is small, a day a week here, an extra approval there. The larger cost is that a team enforcing what it cannot explain trains itself to stop asking, and a team that has stopped asking why cannot tell a living rule from a dead one. So it cannot defend the living ones either. When a good rule gets challenged, all that team has left is “that is the rule,” which is the sentence the slave doctor uses.

The person being pulled down owes something here too. Obeying a rule for three years without once asking what it protects is a choice, and it is the choice that keeps the chain going. Ask for the reason. If nobody can give it, say so out loud, in the channel, instead of complying in silence and resenting it. The audit in the next section is for whoever owns the rulebook, and the question is for everyone else.

The Path: The Fence Audit

Start with the rules you personally enforce or wrote. That set is inside your control on any team, whether or not the organization ever audits itself, and it is usually bigger than you think.

1. List the rules you enforce. Only rules count here, and values are a different list: review gates, freezes, required approvers, naming conventions, formats, linter settings, the meeting that exists because a rule says it must. Anything someone gets pulled down for is a rule.

2. Write the reason in one sentence, or write “unknown.” A reason is a claim about a harm the rule prevents, specific enough that someone could check it and find it false. “Because a bad merge took down checkout in 2023” is a reason. “Because the director wants it” and “because we always have” are sentences after the word because, and a reason that cannot turn out to be wrong is decoration. If the reason takes a paragraph, you have a policy, and policies need their own audit. “Unknown” is an honest answer, and finding out how many of your rules earn it is the whole point of the exercise.

3. Find the incident. Every rule started somewhere. Git blame on the linter config gives you a date and a name. The ticket that added the freeze links to the outage. The postmortem is in the folder nobody opens. The person who left can still be emailed, and a surprising number of the answers are one message away.

4. Give every surviving rule an owner and a retirement condition. The owner is the person who can say why, today, out loud. The retirement condition is the sentence “this rule goes when X is true.” The line-length rule had its retirement condition written into it by reality: when nobody uses narrow terminals. Write yours on purpose, so the rule does not have to wait for someone to notice that the world changed.

5. Retire the rest with a date, out loud. Say it in the channel: this rule had no reason anyone could find, it goes on the first of the month, and if something breaks we will learn the reason and write it down this time. That path is for rules whose failure is cheap and visible, a linter setting, a second approver on copy changes, a meeting. A rule that guards something you cannot undo, money, customer data, credentials, a production delete, does not get retired blind. For those, the reason gets found before anything changes, however long that takes, because the lesson from a break would cost more than the audit. Chesterton is satisfied on both counts, because you went and looked. The next incident, if there is one, buys you a rule with a logos instead of a rule with a grudge.

The Test: How You Know the Memory Is Alive

A new hire asks why and gets a story with a date in it instead of a shrug. The rulebook shrinks as often as it grows, and the shrinking is announced with the same seriousness as the growing. Someone breaks a rule for a stated reason, and the response is to weigh the reason instead of pulling them off the ladder. “We have always done it this way” gets a laugh, and then a ticket to find out. You can name the owner of every gate in your pipeline without opening a document, and each owner can tell you what would have to be true for their gate to come out.

The Mastery: A Team That Can Be Argued With

Plato’s free patient obeys because they understand, which means they can also object, and the doctor has to answer. That is what a team with living rules looks like. Every rule can be argued with, and the argument is welcome, because the rule has a reason that can win the argument or lose it honestly.

Toyota’s five whys is the daily version of that. Taiichi Ohno’s practice of asking why five times about any problem was built to reach a root cause, and it does a second job when you point it at your rules. A rule that survives five whys has a cause behind it, and one that dies on the second why was a habit, which is fine as long as nobody is being punished for it.

I run agents all day at my desk, and my instructions file is a rulebook. The model follows written rules to the letter. A dead rule that a tired human skipped without telling anyone now gets applied to every task at machine speed, and I have come to see that as a gift, because the rule that stopped mattering shows up in the first hour instead of the third year. The fix is the reason written next to every rule, and the model gets to keep all of them. “Never touch the billing schema, because the March migration corrupted a week of invoices” is a rule the model can weigh against the task in front of it, and a rule a person can retire when the schema changes. “Never touch the billing schema” is a fence, and an agent will enforce a fence on everything. Put the why in the file. Start with the model and let it read the reason.

The same is true of the humans. Three rules beat thirty pages when the three come with their reasons, and thirty pages of rules whose reasons are gone will beat you, because process grows fastest where trust has stopped and nobody can remember what the process was for.

Final Thoughts

The monkeys in the fable are loyal to a rule they were handed by monkeys who were loyal to a rule they were handed, and the loyalty is the whole problem. The chain breaks when one of them asks for the reason and is willing to hear “nobody knows.”

That is the whole job. Every rule you enforce should come with a reason you can say out loud, an owner who can say it, and a condition under which it goes. If you cannot supply those three things for a rule, the hose above the ladder has been dry for years, and you are the one pulling people off it.

If you want to work with people who can tell you why every rule exists, and who retire the ones that cannot answer, MasteryLab is built for that.

FAQ

Is the five monkeys experiment real?

No. The version with five monkeys, a ladder, bananas, and a cold water spray was never run in a laboratory. It was assembled in a business book decades after a much smaller 1967 study by Gordon Stephenson, in which rhesus monkeys learned to avoid an object by watching other monkeys react to it. The fable survives because the pattern it describes is real in organizations: a rule outlives its reason and gets enforced by people who were never told why.

What is Chesterton’s fence?

Chesterton’s fence is G. K. Chesterton’s 1929 principle that you should not remove a fence across a road until you know why it was put there. The honest half of the principle is a warning against tearing down rules you cannot explain. The abused half is using the fence as a reason never to go and find out. Chesterton’s instruction was to find the reason, and then you may clear the fence.

Why do organizations keep rules nobody can explain?

Because the rule gets written down and the reason does not. An incident happens, someone adds a rule, and the reason is obvious to everyone in the room, so nobody records it. The room turns over. New people learn the rule as a rule and enforce it harder than its authors did, because the authors knew where the edges were and the inheritors only know that breaking it gets you in trouble. Enforcement hardens as memory thins.

How do you retire an outdated rule at work without breaking something?

Run a rule audit. List every rule you enforce, write its reason in one sentence or write unknown, and go find the incident that created it through git history, the ticket, the postmortem, or the person who left. Give every rule that survives an owner and a retirement condition. Retire the ones with no reason and no owner on a stated date, out loud, with a promise that if something breaks you will learn the reason and write it down this time. That satisfies Chesterton, because you went and looked.