Skip to content
Speed should stop at the exception
|2 min read|By Shawn Pennington

Speed should stop at the exception

Most teams want the same thing from automation: less waiting, fewer manual steps, and more work moving without constant supervision.

That part makes sense. Routine work should move faster when the rules are clear. A system that can handle the obvious cases without dragging people into every step is doing something useful.

The problem starts when speed becomes the goal by itself. Eventually the work hits a case that does not fit the normal path. A policy changed. A required field is off. A customer request falls outside the standard rule. The cost of getting it wrong goes up, and the system has to decide whether to keep going or stop.

A lot of teams build as if stopping is a weakness. They want the workflow to keep moving no matter what, so the system guesses, pushes through, or hides the uncertainty until someone has to clean up the result later.

That is not real efficiency. It just moves the cost downstream.

Good systems are fast on the routine parts and clear at the decision edge. When the case turns into an exception, the workflow should pause cleanly, surface the reason, and hand the decision back to a person who can actually judge it. That is not friction for its own sake. That is control.

The point of automation is not to prove that nothing ever needs judgment. The point is to save judgment for the moments that actually need it. Speed should stop at the exception.