When Exceptions Become the System

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

The decision itself was unremarkable. What caught my attention was that I had said almost the same thing about a similar situation not long before. Then I started noticing the phrase everywhere.

“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.“

None of these exceptions was necessarily wrong. What interested me was that the same ones kept returning. I started treating that recurrence as information. As I noticed similar patterns in my own day-to-day work and across clients’ businesses, I found myself coming back to a simple rule:

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

Not because three is magical. By the third occurrence, the more useful question is no longer whether this particular exception is justified. It is why the business keeps producing the same one.

When an Exception Stops Being Exceptional

Businesses are full of rules about how things are supposed to work. Who can approve a discount. Which customers we serve. What gets customized. What the founder still reviews. Which requests the product team accepts. How work moves from one team to another.

Then reality arrives. A large client wants different terms. A salesperson needs a special approval. One account needs a custom report. A decision that was supposedly delegated lands back with the founder.

Sometimes making the exception is exactly the right decision. The problem begins when the organization keeps making the same exception without asking what it means. A repeated exception can point to two very different problems:

1. The first is a discipline problem. The rule still makes sense, but people keep avoiding it.
2. The second is a design problem. The rule no longer describes how the business actually needs to operate.

Confusing the two is expensive.

If a pricing policy is sound but salespeople keep bypassing it, the answer may be stronger enforcement. If the same type of customer repeatedly needs a different commercial structure, the pricing policy itself may need to change. The exception looks similar in both cases. The response should not be.

The Exception Is Rarely the Whole Cost

The easiest thing to see is the exception itself. The harder thing to see is everything that has to exist around it. A custom report is not just a custom report. Someone has to remember it, produce it, check it and explain it when ownership changes. A special commercial arrangement becomes another renewal condition somebody needs to remember six months later. A founder who keeps reviewing only the “important” decisions can quietly recreate the approval layer they thought they had removed.

That is why I have started asking a second question whenever an exception is approved: What else now has to exist because we made this exception? That question catches a lot. The visible exception may take ten minutes. The operating complexity around it may remain for years.

Southwest Airlines faced a much larger version of this after acquiring AirTran. Southwest had built its operation around Boeing 737s. AirTran brought 88 Boeing 717s into the fleet. Southwest eventually arranged to transfer the 717s to Delta and return to an all-737 fleet. The point is not that the 717 was a bad aircraft. It was that supporting another aircraft type meant another layer of training, maintenance, crew planning, scheduling and parts.

The visible deviation was the aircraft. The real cost was the parallel system around it. Small businesses create parallel systems too. They are just harder to see.

The Exception Audit

I now pay attention whenever I hear phrases like:

“Normally we don’t…” “Only for this client…” “We had to do this manually…” “Send this one to me for approval…”

The first occurrence tells me whether the decision itself makes sense. The second tells me it may not be isolated. By the third, I want a decision.

A recurring exception should usually end in one of four places:

1. Enforce the rule. The rule still works. People are simply bypassing it.
2. Rewrite the rule. Reality has changed and the existing process is outdated.
3. Formalize a second path. There are two legitimate cases, but only one has been designed into the system.
4. Accept the exception deliberately. The exception is worth the complexity it creates.

That last one matters. Not every exception should be eliminated. Some customers are worth treating differently. Some approvals genuinely deserve senior attention. Some complexity earns its keep. The important thing is to know that you are choosing it.

The Missing Feedback Loop

Most organizations are reasonably good at handling exceptions. They are much worse at learning from them. Someone asks for approval. Someone says yes. The immediate problem disappears. Everyone moves on. Then it happens again. And again. The exception gets solved each time, but nothing travels back into the system.

That is the part I now try to watch.

Rule → Exception → Pattern → Review → Decision

Once an exception becomes a pattern, the process that produced it should be reconsidered.

Basecamp has described a similar idea in the way it handled feature requests. Instead of treating every request as something that needed immediate action, the team watched what kept resurfacing. Repetition did not automatically mean a feature should be built. It meant the request deserved another look.

That distinction is useful. Repetition should not automatically change the rule. It should automatically trigger a review.

Businesses spend a lot of time documenting how they are supposed to operate. There are SOPs around pricing policies, approval structures, customer definitions, hiring bands, product roadmaps, processes, etc.

I increasingly find the exceptions more interesting. They show where the written version of the company and the real version have started to separate. Sometimes that means people need more discipline. Sometimes the process is wrong. Sometimes the business has changed. Sometimes the exception is worth keeping.

But once the same exception keeps returning, calling it an exception stops being useful. Remember: One exception deserves judgment. Two deserve attention. Three deserve a decision.