When Exceptions Become the System

A few months ago, I noticed myself approving something with a phrase I have probably used hundreds of times in business: “Fine, let’s do it this once.”

There was nothing remarkable about the decision. It was small, justified and probably the right call. What caught my attention was that I had said almost exactly the same thing about a similar situation not long before.

That made me start noticing the phrase elsewhere.

We normally don’t discount, but this account is important.

We normally don’t customize this, but they really need it.

That decision shouldn’t come to me anymore, but send me this one.

The exceptions themselves were rarely unreasonable. What interested me was how often the same exceptions returned.

I have started treating that recurrence as information. The first question is still whether an exception makes sense. But once it starts repeating, a more useful question appears: what is this telling us about the rule, the process or the business underneath it?

That distinction matters because repetition changes how we perceive an exception. What initially attracts attention can, with enough exposure, begin to feel completely ordinary. There is a well-known and unusually stark example of what that process can look like.

When the Exceptions Starts Feeling Normal

Before the Space Shuttle Challenger broke apart 73 seconds after launch in January 1986, NASA and contractor Morton Thiokol had already observed erosion and blow-by in the O-rings used in the shuttle’s solid rocket booster joints. These were not risks discovered only after the accident. They had appeared on earlier flights.

The Presidential Commission investigating Challenger found that NASA and Thiokol had gradually come to accept O-ring erosion and blow-by as an acceptable flight risk because previous missions had succeeded despite them. The Commission described an escalation in accepted risk rooted partly in the logic that they had effectively “got away with it last time.”

NASA’s own reporting processes contributed to the problem. Once recurring O-ring damage was treated as part of previous flight experience, it could stop appearing as a new anomaly demanding fresh attention.

The underlying problem had not disappeared. It had become familiar.

Most business exceptions are obviously nowhere near this consequential. But the mechanism is useful to understand. Something unusual happens, nothing terrible follows, and the next occurrence feels slightly easier to accept. Eventually, the fact that something has happened before starts being used as evidence that it is normal.

There is another, less dramatic reason repeated exceptions deserve attention. Even when the exception itself is harmless, the organization often has to build things around it.

The Exceptions are Rarely the Whole Cost

Southwest Airlines ran into this problem in a very tangible way when it acquired AirTran. Southwest had historically operated an all-Boeing 737 fleet. AirTran brought 88 Boeing 717 aircraft with it.

Southwest could have kept them. Instead, it arranged to transfer all 88 to Delta.

In its filings, Southwest said the 717s added complexity to an operation historically built around one aircraft type. Returning to an all-737 fleet was expected to improve scheduling and operating efficiency.

What I like about the example is that the 717 did not need to be a bad aircraft to create a problem. The cost sat around it. A second aircraft type affects training, maintenance, spare parts, crew planning and scheduling. The aircraft is the visible exception. The surrounding accommodations are much easier to miss.

That idea translates surprisingly well to ordinary business decisions. I have seen a client-specific report begin as a harmless accommodation and then become something somebody has to remember to prepare every month. A special commercial arrangement can survive long after the circumstances that justified it have changed. A founder can delegate a responsibility but continue reviewing the handful of “important” decisions until an unofficial approval layer has quietly reappeared.

None of these decisions has to be wrong. The point is that the cost of an exception is often larger than the exception itself.

So I have started asking a second question alongside “Should we make this exception?”

“What else now has to exist because we made it?”

That catches complexity. But it still leaves another possibility: sometimes the repeated exception is not the thing that needs fixing. Sometimes it is evidence that the original rule no longer fits reality.

That is why I have started auditing them.

The Exception Audit

I have started keeping an exception audit. I do not mean a formal spreadsheet with dozens of columns. I simply pay attention to recurring deviations.

Whenever I hear “normally we don’t,” “only for this client,” “just this once,” “we had to do it manually,” or “send this one to me for approval,” I make a mental or written note of it.

The first occurrence usually tells me very little. The second makes me curious. By the third, I want to know why the same situation keeps returning.

That small habit has changed how I look at operational problems. Instead of starting with whether someone followed the rule, I first ask whether the rule still describes reality.

Repeated exceptions usually point to one of the following:

• The rule is right, but people are avoiding it;
• The rule is outdated;
• There are actually two legitimate cases but only one has been formalized; or
• The exception is worth keeping despite the complexity it creates.

The point of noticing exceptions, then, is not simply to control them but to make sure the information they contain travels somewhere.

The Missing Feedback Loop

This is where I think many organizations lose the value of an exception.

Most exceptions are handled as individual decisions. Someone asks for approval, someone says yes, the immediate problem disappears and everybody moves on. The same thing can then happen five more times without the system itself ever being reconsidered.

Basecamp’s approach to feature requests offers a useful contrast. The company has written about starting with “no” rather than immediately acting on every request. It listens, waits and watches for what continues to return.

At one point, the team tracked major feature requests and added marks when the same request came up again. Eventually they found they barely needed the list because the genuinely important requests kept resurfacing on their own.

The lesson is not that repeated requests should automatically win. Basecamp explicitly notes that even frequently requested features can still be rejected.

The useful part is that repetition triggers reconsideration.

That is the feedback loop I now find useful:

Rule → Exception → Pattern → Review → Decision

Once an exception becomes a pattern, something should happen to the system that produced it.

• The rule may need stronger enforcement;
• The rule may need to change;
• A legitimate second path may need to be formalized; or
• The exception may be worth retaining, with its added complexity consciously accepted.

What should not happen is that the same exception keeps being approved indefinitely while everyone continues calling it unusual.

The One, Two, Three Rule

I have ended up using a simple rule for myself:

One exception deserves judgment. Two deserve attention. Three deserve a decision.

Not because three is a magical number, but because by then the important question is no longer whether the latest exception can be justified. It is why the organization keeps producing the same one.

Businesses spend plenty of time documenting how they are supposed to operate. Pricing policies, approval structures, hiring bands, customer definitions, roadmaps and processes all describe the intended business.

I increasingly find the exceptions more interesting because they show where the written version of the company and the real version have begun to diverge.

Sometimes that means discipline is slipping. Sometimes the process is wrong. Sometimes reality has changed. Sometimes the exception is worth the complexity.

But repeated exceptions are feedback.

The mistake is not making one.

The mistake is making it again and again without learning anything from it.

---