The Bad Tuesday Test
Most operating systems are designed for the Monday demo. The real test is whether they hold when two people called out and the customer is pissed.
Every team I've worked with has a version of the system that lives in the deck and a version that runs the floor. The deck version is for the board. The floor version is what actually decides whether your customer gets called back today.
The gap between the two is not a culture problem. It's a design problem. When the SOP only works on a good day, your team will quietly invent a worse one — and then defend it, because it's the only thing that holds when things go sideways.
The test
Pick the worst Tuesday you can plausibly imagine for this quarter. Two key people out. Your largest account escalating. A piece of tooling broken. Now walk the process — not the one in the wiki, the one your team will actually run.
- Who makes the call when the named owner is unavailable?
- Where does the work go when the usual queue is jammed?
- What's the explicit rule for when a customer gets a human inside the hour?
- Which three things stop happening, on purpose, so the critical path keeps moving?
If any of those answers come back as 'we'd figure it out' or 'someone would step up,' you don't have an operating system. You have a culture of heroics that will eventually run out of heroes.
What changes
The teams that pass the bad-Tuesday test aren't more disciplined. They've just made fewer of their critical decisions implicit. The owner is named. The fallback is named. The thing that gets dropped is named, in advance, by the people who'd have to drop it.
That's the work. Not motivation. Not all-hands speeches. Just turning the implicit, panicky version of your operating system into a written one your team can actually run when nobody feels like a hero.