An exception is information about the process and not a nuisance in it
💎CORE ARGUMENT
When a shipment is late, a document is missing or a driver is at the wrong gate, the instinct is to make the alert go away. Clear it, close it, get back to the plan. I think this instinct throws away the most valuable data a process produces. An exception is the process reporting, accurately, where it does not match the world. The plan is a claim. The exception is the evidence against it.
A production line that stops when something is wrong looks, on the day, less efficient than one that keeps running. Over a year it is the opposite, because every stop was a question asked while the answer could still be found. The container is the other half of the argument. Once nearly everything travels the same way in the same box, whatever does not fit stands out. Standard work is what makes a deviation legible.
This is the claim the Exceptions Inbox is built on, and the pilot tested it on me. A dispatcher at our pilot customer had 214 open exceptions before nine on a Tuesday. Treated as nuisances, that is 214 things to click away. Treated as information it says something else: that most of them are a few causes seen many times, and that no person can read 214 messages and learn anything. The list was honest and useless.
So the design question changed, from how do we show every exception to what is this set of exceptions telling the dispatcher about today.
I first met the idea in 2013, in a spreadsheet of late vans: the interesting thing is always the exception.
Where I might be wrong. Not every exception is a message. Some are plain noise, and a product that treats each one as meaningful rebuilds the alarm fatigue it was meant to remove. I need a rate of how often this happens anyway before I call anything a signal.
And sometimes the plan is right and the world is briefly wrong. A storm is not feedback on the timetable.
🧱BUILT FROM
🌍WHY IT MATTERS
- I read the week's exceptions as a set before I read any one of them.
- A feature that only helps people dismiss alerts faster is, to me, a feature for forgetting.
- In my own week: the task I keep moving is telling me something about the plan, and I try to hear it before the third move.
☑️NEXT STEPS
- Group the pilot's exceptions by cause before counting them
- Write the exception budget into the launch retro notes
- Review which alerts dispatchers dismiss unread
Stopping the line to ask why, and a history of the box in which standardisation is what makes the odd case visible.
💎 Pull beats push when the downstream step knows more is about who should receive the signal. 💎 Reality has more detail than any plan can hold is about why the signals never stop coming.
A process embodies assumptions about the world. An exception occurs exactly where an assumption fails, so it carries more information per event than any routine case. Suppressing it removes the only signal that the assumption is wrong.
To the dispatcher at 08:50 it is a nuisance, and telling her it is information does not shorten her list. A view that is right for the product owner can be insulting to the person doing the work.
The issue a reader in Izmir answered at length, the product itself, and my term for how many exceptions one person can meaningfully handle in a shift.