Chapter 4
Operating Under Pressure
Chapter 4
Operating Under Pressure
A process behaves differently under pressure. This is not a hypothesis. It is an observable fact that every operational leader who has managed a high-volume environment, a system transition or a crisis has experienced directly. The process that performed reliably at normal volume begins to distort at twice the volume. The decision that took two minutes at steady state takes twenty minutes when the queue is building and the team is stretched. The validation that caught errors consistently begins to miss them when the people running it are fatigued and time-compressed.
Pressure does not change the process design. It changes the conditions under which the process operates and those conditions determine whether the design holds or breaks.
The specific ways pressure changes process behaviour are predictable. Time compresses the time available for each decision decreases while the complexity of the decisions increases. Dependencies become visible, the process steps that were invisible in normal operations because they completed reliably and quickly become bottlenecks when they slow down or fail. Exceptions multiply, the conditions that the process was not designed to handle occur more frequently as the volume and variability of inputs increases.
Understanding how pressure changes process behaviour is the foundation of designing processes that hold under pressure. A process that has only been designed for normal conditions will always be surprised by what happens when conditions change. A process that has been designed with pressure in mind will not be surprised because the designer anticipated what would change and built in the capacity to absorb it.
Key Takeaway:
Processes are not static systems they change behaviour under pressure.
"Pressure doesn’t change the process. It changes how the process behaves."
MarvinPro_|_March_2026
marvinpro.com
Under normal conditions a well-designed process maintains a productive balance between speed and accuracy. Transactions are processed quickly enough to meet demand. Validations are thorough enough to catch errors before they create downstream problems. The balance is sustainable because the volume is manageable and the time available for each decision is sufficient.
Under pressure this balance breaks almost always in the same direction. Speed increases to meet demand. Accuracy decreases because the time available for validation shrinks. The pressure to process more faster creates a systematic bias toward speed at the expense of quality.
The consequences are predictable. Error rates increase as validations are compressed or skipped. Rework grows as errors that were not caught at the point of processing are discovered downstream. Downstream processes are affected because they receive inputs that were processed incorrectly. The cost of the errors in rework, in customer impact, in financial reconciliation accumulates faster than the speed gain justifies.
The design response to this dynamic is not to choose between speed and accuracy. It is to identify which validations are critical, the ones whose failure creates significant downstream cost and protect them explicitly in the process design, even under pressure. To identify which validations are lower risk, the ones whose failure is easily caught and corrected and allow them to be compressed when necessary.
This requires the process designer to think about failure modes, not just about the standard flow. Which errors are most expensive to correct after the fact? Which validations catch those errors before they propagate? How can those validations be designed to remain fast enough to operate under pressure without becoming the bottleneck that slows everything else down?
The process that has been designed with these questions in mind will maintain its accuracy under pressure more reliably than the process that was designed only for normal conditions and hopes for the best when things get difficult.
Key Takeaway:
Speed without control creates errors. Accuracy without speed creates bottlenecks. The process that performs well under pressure has defined where speed is prioritised and where accuracy cannot be compromised — before the pressure arrives.
"Under pressure, speed increases by default. Accuracy must be protected by design."
MarvinPro_|_March_2026
marvinpro.com
Processes rely on structured communication to function correctly. Information must flow from one step to the next. Decisions must be communicated to the people who need to act on them. Status must be visible to the people who need to manage the overall flow. Escalations must reach the people with the authority to resolve them.
Under normal conditions this communication infrastructure is largely invisible because it works. Information flows. Decisions are communicated. Status is visible. Escalations are resolved. The process produces its expected output and nobody thinks much about the communication that made it possible.
Under pressure the communication infrastructure becomes visible because it starts to fail. Information becomes fragmented as the volume of transactions exceeds the capacity of the communication channels to carry it. Updates are delayed as the people responsible for communicating status are too busy processing transactions to provide it. Teams begin operating on different assumptions because they are receiving different or no information about what is happening in other parts of the process. Escalations increase without resolution as the people with authority to resolve them are overwhelmed with escalations from multiple directions simultaneously.
When communication breaks down the process becomes disconnected from reality. The team managing one part of the process does not know what is happening in another part. Decisions are duplicated, two people make the same decision independently because neither knew the other had already made it. Actions are misaligned, one team takes an action that conflicts with an action another team took based on different information. Errors propagate across the process because the people downstream do not know that the upstream output was incorrect.
The design response is to treat communication as infrastructure, not as a support activity that happens around the edges of the process. Communication channels, status visibility, escalation paths and decision communication mechanisms must be explicitly designed into the process. They must be tested under simulated pressure conditions. They must have defined owners. They must be robust enough to function when the people responsible for them are operating at or beyond normal capacity.
Key Takeaway:
When communication breaks down, the process becomes disconnected from reality. Communication is not support, it is infrastructure. It must be designed with the same rigour as the process steps it connects.
"When information fragments, the process fragments."
MarvinPro_|_March_2026
marvinpro.com
In crisis conditions people adapt faster than processes do. This is not a criticism. It is a description of rational human behaviour in a situation where the official process cannot keep pace with the operational reality. When the queue is building and the standard process cannot clear it fast enough, people find faster ways to work. When the system cannot handle a scenario, people find manual workarounds. When the official escalation path is too slow, people call the person they know can resolve the issue directly.
These adaptations keep the operation running. Without them the situation would be worse. The people making them are doing the right thing in the circumstances they are in.
The risk is not in the adaptation itself. It is in what happens when the adaptation continues beyond the crisis. The faster way of working that was appropriate under emergency conditions becomes the standard way of working when the crisis passes, even though it bypasses controls that exist for good reasons. The manual workaround that was necessary when the system could not handle the scenario continues after the system is fixed because nobody went back and removed it. The informal escalation path that worked during the crisis becomes the default escalation path, invisible to anyone who was not present during the crisis and never documented in the official process.
The organisation believes it returned to normal operations after the crisis. In reality it is operating a modified version of its pre-crisis processes, modified by the adaptations made during the crisis, most of which were never reviewed, approved or documented.
Managing this dynamic requires a deliberate post-crisis review, an explicit assessment of what changed during the crisis, which changes should be formalised as process improvements and which should be reversed now that normal conditions have returned. Without this review the crisis leaves a residue of undocumented process changes that accumulate over time and make the next crisis more complex to manage than the last.
Key Takeaway:
In crisis, people adapt faster than processes but without structure, that adaptation creates instability that outlasts the crisis itself. The post-crisis review is not optional. It is the mechanism that prevents crisis adaptations from becoming permanent shadow processes.
"In a crisis, the process is followed less—but its consequences are felt more."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation operating across multiple markets, a queue of thousands of unresolved cases had accumulated over several months. The cause was a period of reduced capacity, new staff could not be onboarded quickly enough to match incoming volume. By the time the situation was addressed, the backlog was significant and growing.
The instinctive response under this kind of pressure is to treat everything as urgent. Prioritise the loudest cases. Work harder. Move faster. The team feels the pressure and responds to it but without structure, faster movement on the wrong cases makes the overall situation worse.
That approach was not taken.
Instead the pressure was treated as a design problem. The queue was not a pile of urgent work. It was a set of cases with different characteristics, different complexity, different resolution time, different cost of further delay. The question was not how to work faster. It was how to work in the right sequence.
The fastest agents were assigned the quickest cases, simple, templated, closeable in minutes. Duplicate cases were identified and merged. The queue shrank visibly and quickly. The more methodical agents were assigned the complex cases that required deep investigation. They moved more slowly but with higher accuracy on work that demanded it.
The manager operated the same way pausing constantly to handle quick decisions immediately, never letting team questions age into a secondary queue, always available despite the pressure.
Within four months the backlog was cleared. Not by working harder. By working in the right sequence, with the right people on the right tasks, and by never letting quick things become slow things through neglect.
The pressure did not change. The structure did.
"Pressure is not a reason to move faster. It is a reason to move in the right sequence."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
Pressure does not create new behaviour. It accelerates existing weaknesses.
The process that is stable under normal conditions but has never been tested under pressure is not a stable process. It is a process whose weaknesses have not yet been revealed. The speed versus accuracy trade-off, the communication breakdown, the crisis adaptations that outlast the crisis, these are not exceptional events. They are the predictable consequences of operating any complex process under conditions of elevated demand.
Designing for pressure means anticipating these dynamics before they occur, building in the accuracy protections, the communication infrastructure and the post-crisis review mechanisms that allow the process to hold when conditions change.
The process that has been designed for pressure will not be surprised by it. It will simply operate.
"Pressure does not create exceptions. It removes the capacity that was absorbing them. The organisation that designed for exceptions before the pressure arrived operates differently from the one that did not."
MarvinPro_|_March_2026
marvinpro.com