The Pivot to Proximal Cause

“So,” the VP of Engineering says, his voice flat. “Why did the payment gateway go dark for 72 minutes?”

This is the start of the ‘Five Whys.’ Or the ‘Twelve Whys.’ Or whatever number the latest management consultant scrawled on a whiteboard during a $5002 retreat. The theory is elegant: ask ‘why’ enough times, and you’ll peel back the layers of the onion until you reach the root cause. But in this room, we aren’t peeling an onion. We are looking for a neck to put in a noose. The lead developer clears his throat. He’s 32 years old, but in this light, he looks like he’s seen 82 winters. He explains that a configuration script was updated manually. Why? Because the automated deployment tool flagged a false positive. Why? Because the timeout threshold was too tight. Why? Because the engineer on call wanted to ensure the update went live before the midnight rush.

The Bridge Inspector’s View: Load-Bearing Lies

I think about Laura G.H. She’s a bridge inspector I met 12 years ago at a dive bar in Pittsburgh. She used to sit there with a sketchbook, drawing the way rust eats into structural steel. She told me once that when a bridge collapses, the public wants to hear about a bad bolt or a single lazy welder. They want a villain. Yet, Laura G.H. never looked for villains. She looked for load-bearing lies.

She looked at how the salt from 42 winters interacted with a specific grade of steel that was chosen because it saved the city $200002 in the short term. She looked at how the inspection schedule was compressed because of political pressure to keep traffic moving. In Laura’s world, the ‘Why’ wasn’t a person. The ‘Why’ was the tension between the physical reality of the bridge and the delusional expectations of the people who owned it. When we blame an engineer for a typo, we are ignoring the 102 layers of architectural negligence that allowed a single typo to bring down a $12 million-per-hour revenue stream. We are pretending that the fitted sheet is perfectly square, and if we can’t fold it, the problem is our hands, not the chaotic elastic circumference of the fabric itself.

We live in a culture of proximal cause. We stop looking for answers the moment we find someone who can be blamed. It is a psychological survival mechanism. If the failure is ‘human error,’ then the system is still good. If the system is still good, the people at the top don’t have to change anything.

The Deep Dive: Incentives Over Stability

The Five Whys, in their corporate implementation, are often just a path to the nearest exit. Real root cause analysis is uncomfortable. It requires a level of institutional humility that is rare in an era of quarterly earnings reports. It requires us to ask why the system was designed to be so fragile that a single person *could* break it. If a typo can sink the ship, the problem isn’t the person who typed it; the problem is that you’ve built a ship out of tissue paper and sent it into a hurricane.

I remember a specific incident 22 months ago. A database migration went sideways. The initial report blamed a junior DBA. If we had stopped at the second ‘why,’ he would have been fired. But we kept going. We asked why he was running migrations at 2 AM. Because that was the only window allowed by the marketing department. Why was the marketing department dictating technical windows? Because the service level agreements were written by sales reps who didn’t understand latency. Why did the sales reps write the SLAs? Because the executive team incentivized volume over stability.

Now we’re getting somewhere. The root cause wasn’t a junior DBA’s shaky hand. The root cause was a misaligned incentive structure at the C-suite level. But you try telling a CEO that his bonus structure is the reason the database crashed. It’s much easier to tell the DBA to be ‘more careful.’

This is where the concept of the ‘Blameless Post-Mortem’ becomes revolutionary. It’s the recognition that humans are, by definition, error-prone. We are tired. We are distracted. We are trying to fold fitted sheets in the dark. A resilient system is one that accounts for this. It is a system that treats human error as a data point, not a destination. It’s the difference between a bridge that collapses when one bolt snaps and a bridge designed with enough redundancy that 12 bolts could snap and the cars would still keep moving. In the world of high-stakes digital infrastructure, particularly in sectors like finance where a millisecond of downtime translates to millions in lost value, this shift is non-negotiable. You cannot build a modern economy on top of ‘be more careful.’ You build it on top of systems that are inherently defensive. This is the philosophy embraced by firms like ElmoSoft, where the focus moves away from policing individual behavior and toward engineering out the very possibility of catastrophic failure. It is about creating environments where the ‘Five Whys’ actually lead to structural change rather than just another round of finger-pointing.

[The system is only as strong as the truth it is allowed to hear.]

– Underlying Principle

The Paradox of Process Improvement

I’ve spent 42 hours this month in various meetings where we’ve discussed ‘process improvement.’ Most of it is theater. We add another checkbox to a form. We add another layer of approval. We make it 12 times harder to get anything done, thinking that friction equals safety. It doesn’t. Friction just makes people more tired, which leads to more errors, which leads to more checkboxes. It’s a feedback loop of misery.

Laura G.H. once showed me a photograph of a bridge pier that had been reinforced 12 times over 52 years. The reinforcements were so heavy that the pier itself was starting to sink into the riverbed under their own weight. The ‘solutions’ had become the new problem. We do this in software every single day. We build complex hierarchies of oversight to prevent the last mistake, never realizing that the complexity we’ve added is exactly what will cause the next 22 mistakes.

The Arrogance of Perfect Behavior

There is a specific kind of arrogance in thinking we can perfect human behavior. We can’t. We can only design better environments. If you put a human in a stickpit where every button looks the same and the labels are in 2-point font, you don’t blame the pilot when they hit the wrong switch. You fire the industrial designer. But in the corporate world, we love the pilot-blame. It’s cheap. It’s fast. It doesn’t require a 12-month overhaul of the UI.

The Necessary Shift in Inquiry

I went home after that meeting and looked at the closet where I’d shoved the fitted sheet. It was a mess. A lumpy, disorganized failure. I could have blamed my lack of coordination. I could have promised myself to ‘be more careful’ next time. But the truth is, the fitted sheet is a fundamentally flawed piece of technology. It’s a 102-year-old design that hasn’t evolved to meet the needs of people who don’t want to spend their Sunday mornings wrestling with elastic.

We need to stop asking ‘Why did you fail?’ and start asking ‘Why did the system fail you?’

It’s a subtle shift, but it’s the difference between a culture of fear and a culture of resilience. It’s the difference between a bridge that stands for 102 years and one that ends up at the bottom of the river because we were too busy blaming the welder to notice the rust in the design.

Next time you’re in a post-mortem, and someone says ‘human error,’ try to push for the sixth why. And the seventh. And the twelfth. Follow the trail until it leads to something uncomfortable-a budget cut, a rushed deadline, a legacy system that everyone is afraid to touch, or a leadership style that values silence over transparency. That is where the actual ‘Why’ lives. It’s messy, it’s expensive to fix, and it doesn’t fit neatly on a legal pad. But it’s the only answer that matters. Everything else is just folding sheets in the dark, hoping no one notices the lumps.