Rules

Every organization has rules that technically exist but functionally don't.

Someone tells you a form must be signed in blue ink instead of black. A purchase over a certain dollar amount requires one extra approval, but a purchase one dollar less does not. One door is supposed to remain unlocked during business hours while another must stay locked at all times. New employees quickly learn that questioning these rules often produces the same answer.

"That's just the way we've always done it."

It is tempting to assume the rule is meaningless.

More often than not, it isn't.

The meaning has simply been forgotten.

A surprising number of rules begin with a single event. Someone parked where they shouldn't have parked. Someone forgot to lock the building. Someone approved the wrong invoice, left a valve open, misplaced an important file, or backed a truck into something that looked impossible to hit.

The event happened once.

The rule remained.

Time has a way of separating rules from the stories that created them. The people involved retire, transfer, or move on. Procedures are copied into new manuals. Training materials are updated by people who never witnessed the original incident. Eventually, all that survives is the instruction itself.

The explanation disappears.

The rule does not.

I've experienced this more than once. Someone points to a paragraph in a procedure and explains that "we have to do it this way," but no one in the room can explain why. Ask long enough and eventually someone remembers that the requirement came from an audit years earlier, or a software system that no longer exists, or a problem that disappeared when the organization changed. The rule survived because copying the old procedure into the new one was easier than deciding whether it was still necessary.

This is one of the quiet ways organizations preserve experience.

A single person's mistake becomes everyone else's procedure. Instead of requiring every new participant to repeat the same failure, the organization creates a rule intended to prevent it from happening again. The cost of following the rule is usually much smaller than the cost of relearning the lesson.

At least, that is the hope.

Most of the time it works remarkably well.

Sometimes it creates a different problem.

Rules have an interesting tendency to accumulate. Every incident suggests another safeguard. Every unexpected outcome encourages another approval, another checklist, another required training session, another signature, or another line on another form. Viewed individually, each addition makes sense because each addresses a real event that someone genuinely hopes never happens again.

Very few people ask the opposite question.

Which rule no longer serves a purpose?

As a result, organizations often become museums of old problems. The issue that inspired the rule may have disappeared years ago while the rule itself continues shaping daily behavior. Technology changes. Equipment improves. Software is replaced. Entire departments are reorganized.

The rule survives.

Individuals create personal rules in much the same way.

Someone who once locked their keys in the car automatically pats their pocket before closing the door. A traveler who forgot a phone charger develops the habit of checking the hotel room one final time before leaving. A parent whose child wandered away in a crowded store begins counting heads every few minutes without consciously deciding to do so.

These habits rarely feel like rules.

They feel like common sense.

In reality, they are private procedures written by experience instead of policy.

That distinction matters because rules do more than restrict behavior.

They preserve memory.

Every checklist contains traces of failures someone hoped would not need to be repeated. Every written procedure reflects problems encountered by people who came before us. Every requirement that appears unnecessary today probably seemed painfully obvious to the person who insisted it be added.

That does not mean every rule deserves to exist forever.

Rules can outlive the technology they govern. They can continue solving problems that no longer exist or create enough friction that they become more costly than the issue they were originally designed to prevent. Knowing when to remove a rule requires just as much wisdom as knowing when to create one.

The challenge is that the value of a rule often becomes visible only after it disappears.

People rarely appreciate a backup process until the primary process fails. They seldom notice the importance of a checklist until the one item it would have caught is overlooked. The absence of a safeguard reveals why it existed in the first place.

I've seen that happen as well. A long-standing requirement gets removed because it seems unnecessary, only for everyone to discover a few months later that it had been preventing a problem no one remembered having. The value of the rule wasn't obvious while it was working. It became obvious only after it was gone.

This creates unavoidable tension.

Too few rules invite repeated mistakes.

Too many rules make participation unnecessarily difficult.

Healthy systems spend their lives trying to find a balance between those two extremes, preserving enough experience to prevent yesterday's failures without making tomorrow's work impossible.

Perhaps that is the real purpose of rules.

Not to eliminate judgment or failure. But to preserve enough of the past that every new participant does not have to begin from the same place.

Every rule has a story. Sometimes the story is obvious because it happened yesterday. More often it has been forgotten, carried away by retirements, reorganizations, software upgrades, and the simple passage of time. The rule remains anyway, preserving a lesson no one remembers learning.

Whether that lesson is still worth preserving is a question every healthy system eventually must ask.