Week 35 Day 6: When to Break Your Own Process

Processes are designed for the 90% case -- the normal operating conditions that occur most of the time. The remaining 10% of situations are exceptions that the process was not designed to handle. If the team has no way to handle exceptions, they either break the process (which erodes trust in it) or follow the process blindly (which produces bad outcomes). A good process includes a defined, sanctioned way to deviate.

Here is how to design a process override mechanism. Principle one -- define the threshold: the override should have a clear trigger. Not 'when someone feels like it' but 'when the situation meets one of these criteria.' For a deployment process, the override criteria might be: 'Skip the staging validation step when a critical security vulnerability must be patched within 1 hour.' The threshold ensures that overrides are reserved for genuine exceptions. Principle two -- require a conscious decision: the override should never be automatic. It requires a specific person to make a specific decision: 'I am overriding the standard process because [stated reason].' This conscious decision creates accountability and a record. Principle three -- document the override: every override is logged with the date, the reason, the person who authorized it, and the outcome. This log serves two purposes -- it provides a record for review, and it creates data for improving the process. If the same override happens repeatedly, the process needs to be updated to handle that scenario natively. Principle four -- review the overrides: during retrospectives, review the override log. Each override is either evidence that the process needs to evolve (the exception is actually common enough to become part of the standard process) or confirmation that the process is correct for the standard case (the exception was genuinely rare). The test for a healthy override mechanism is the override frequency. If overrides happen less than 10% of the time, the process is well-designed and the override mechanism is handling genuine exceptions. If overrides happen 10-30% of the time, the process needs to be updated because the 'exceptions' are actually normal. If overrides happen more than 30% of the time, the process is fundamentally misdesigned for the team's actual working conditions.

The process override mechanism implements what Rasmussen (1997) calls the 'boundaries of acceptable performance' in his framework for risk management in sociotechnical systems. His research demonstrates that every work system has a defined operational boundary (the process) and a set of boundary conditions under which the process may be safely violated. Systems that define these boundary conditions explicitly experience fewer catastrophic failures than systems that either prohibit all deviation (forcing workers to violate unstated rules) or permit unlimited deviation (providing no guidance on when deviation is acceptable). The 10% override threshold is consistent with research by Hollnagel (2009) on 'resilience engineering,' which finds that organizations with approximately 5-10% process variance (deliberate, documented deviation from the standard process) show optimal safety and performance outcomes: too little variance indicates rigidity (the organization cannot adapt to non-standard situations), while too much variance indicates process failure (the standard process does not match actual work). The 'repeated overrides indicate process debt' principle connects to what Worren, Moore, and Cardona (2002) call 'modularity in organizational design' -- the principle that organizational processes should be designed with replaceable components that can be updated independently as operating conditions change, reducing the cost of process evolution from 'redesign the entire process' to 'replace the module that no longer fits.'