You Designed for the Easy Day
You built the process on a Tuesday. Everyone was in. The tickets were light. No one called in sick. You mapped the workflow, set the escalation path, told yourself this is how it works. Then Thursday hit and the whole thing dissolved. I have seen this pattern across billions of dollars in managed operations, and it is always the same shape. The system works until the first exception. The SOP was written by someone who had never been on the other side of the phone at 2pm when the server is down, the key person is on a flight, and the client is asking for an answer in four minutes. You did not design a system. You documented a memory.
The Calm Version Is a Fiction
You think you are being thorough when you write down the steps for a normal day. You are not. You are writing a script for a play that only gets performed once. The real job is the improvisation. It is the 6pm quick question that is actually a scope change. It is the vendor who says they just need a minute and then needs a week. I watched a team at a 200M company rebuild their onboarding process three times in eight months. Not because the business changed. Because they kept designing for a world where every new hire arrives on schedule, with complete documentation, and without a single question in the first 48 hours. That world is not the world.
What the Worst Day Actually Requires
The worst day is not a failure state. It is the operating state. The difference between a system that survives and one that collapses is whether you built it for the Tuesday or the Thursday, and most people cannot tell which day they are on until it is already Thursday. Here is the thing I still sit with. If you design for the worst day, the easy day starts to feel like overkill, and people push back. They call it paranoid. They say that is not how we operate. And they are right. They operate for the easy day. They just do not have a name for it.
