In 1979, a series of small, individually manageable failures at Three Mile Island combined into something that wasn't manageable at all.
No single error caused the accident. Each decision made sense in isolation. The operators responded rationally to what they could see. What they couldn't see was how the components of the system were interacting beneath the surface.
Charles Perrow spent years studying accidents like this one — in nuclear plants, petrochemical facilities, air traffic control systems. His conclusion, published in Normal Accidents in 1984, was uncomfortable: in complex, tightly coupled systems, serious failures aren't aberrations. They're normal. Not in the sense of being frequent, but in the sense of being the predictable consequence of the architecture itself.
The problem wasn't the people. The problem was the system.
I've been thinking about this a lot recently, particularly, after watching a transaction process scale under pressure.
On paper, governance was there. Clear ownership, structured timelines, defined workstreams. The team was strong. The advisors were experienced. There was no obvious reason for things to get hard.
But as diligence accelerated, something recognizable started to happen.
The banks pushed for speed and responsiveness - rational, given their role. The advisors focused on their specific workstreams - rational, given how they're engaged. The management team tried to keep the business running while responding to a constant and growing volume of external scrutiny - rational, given that the business still had to perform.
None of it was wrong. Each part was optimizing correctly for its own lane.
But the volume of requests scaled faster than the coordination did. Information flows multiplied. Questions overlapped across workstreams. Ownership of specific issues became ambiguous as more parties engaged. And a team that had been controlling the process started to feel like it was reacting to it.
This is what Perrow would recognize immediately. Not failure caused by error. Failure - or the drift toward it - caused by the normal behavior of a complex system under load.
Dekker's contribution to this literature is the temporal dimension. Systems don't fail suddenly. They drift. Each small normalization — a question that goes to the wrong person, an issue that gets resolved informally rather than logged, a decision made by one workstream that creates an assumption in another — is locally acceptable. Cumulatively, they move the system toward a state where something consequential can happen faster than anyone can respond.
In a transaction, that drift has a specific texture. It's the moment the management team stops having a shared view of where things stand. It's the point where the same question is being answered differently by different people because nobody has visibility into what's already been said. It's the quiet erosion of coherence that happens not from negligence but from volume.
Strong teams feel it before they can name it. The process starts to feel like it's running them rather than the other way around.
What I've come to think is that the conventional response - more effort, more organization, more responsiveness - doesn't actually address the problem. It addresses the symptom while the underlying architecture remains unchanged.
The organizations that Perrow and others identified as genuinely reliable in complex environments - what the literature calls high reliability organizations — don't achieve coherence through effort. They achieve it through design. Shared situational awareness. Visible dependencies. A single source of truth that everyone is operating from, updated in something close to real time.
Atul Gawande made a version of this argument about surgical teams: the checklist's value isn't that it helps individuals remember things. It's that it creates a shared state across a team operating under pressure. The benefit is collective, not individual.
The same logic applies to transactions. At a certain level of complexity, coherence doesn't emerge from effort. It has to be designed in - ideally before the pressure arrives, because designing it under pressure is genuinely difficult.
This has changed how I think about what actually drives or derails a process.
The team's capability matters. The quality of the advisors matters. The strength of the underlying business matters enormously.
But underneath all of it, there's a coordination architecture — visible or not, designed or improvised - that determines whether the system holds together as complexity builds.
Perrow's insight was that you can't inspect your way to reliability in a complex system. You have to build it in.
That's as true in a diligence process as it was at Three Mile Island.