I have no idea how I missed this report when it came out. Cockroach Labs published their State of Resilience 2025 back in late 2024, surveying 1,000 senior technology executives across North America, Europe, and Asia-Pacific, and it somehow slipped past me entirely. Better late than never, because there's a lot here worth digging into, at least if you're willing to ignore Part 6, which makes the same mistake almost every vendor resilience report makes: five sections of genuinely useful organizational data followed by a pivot to "and here's how our product fixes it." It's understandable. They sell distributed databases. But it's also disappointing, because their own data argues against the conclusion, and because it reinforces a persistent myth in this industry that you can buy your way to resilience. More on that in a moment.

The data was collected in August-September 2024, so about 18 months old. If anything, that makes the findings more relevant now. Since this survey was fielded, DORA has gone into full effect, NIS2 enforcement is ramping up across EU member states, AI agents are being woven into operational workflows at a pace that would have seemed aggressive even a year ago, and the organizations that told CrowdStrike-shaken researchers they were "significantly improving their planning" have had a full year and a half to either follow through or quietly drift back to the status quo. The structural dynamics this report captures don't resolve themselves in 18 months, they compound. And the rapid adoption of AI in operations is adding new failure modes to systems that were already struggling with the old ones.

The headline numbers first: the average enterprise experiences 86 outages per year, averaging 196 minutes each. Every single company surveyed lost revenue to outages in the past twelve months. For large enterprises, outage-related losses averaged $495K annually.

But the number that made me pause for a second: 95% of executives say they are aware of at least one unresolved operational weakness that puts their organization at risk. 72% say they have multiple. And 48% say their organizations are doing insufficient work to address it. Nearly every leader knows where the cracks are, and almost half say nothing adequate is being done. The prevention paradox, playing out at scale with hard data behind it.

The blockers are familiar too. Other teams' priorities take precedence (38%). Budget constraints (36%). Lack of leadership buy-in (32%). Meanwhile 92% of teams must deprioritize essential work to fight fires, 48% work overtime and weekends to restore operations, and 39% report a growing backlog of post-mortems. The feedback loop I keep coming back to in client work is right there in the numbers: less time for improvement leads to more incidents, which leads to even less time for improvement.

Then there's the human cost that rarely shows up in resilience reports. 82% of leaders said they or their team members fear losing their jobs following a significant outage. Think about what that does to everything else. If you've ever wondered why your blameless post-mortems don't feel blameless, there's your answer. You can design the most thoughtful incident analysis process imaginable, but 82% job-fear will override any process document every single time.

Now, Part 6 and why it's a missed opportunity. Look at the causes of downtime: network issues (38%), software issues (36%), cyberattacks (36%), cloud provider reliability (35%), third-party failures (33%), environmental factors (31%), human error (31%), capacity issues (30%), hardware failures (30%). That distribution is remarkably flat. Nothing really dominates. And the report itself notes it's consistent regardless of company size, sector, or geography.

To me, that flat distribution is the most important finding in the entire report, and the authors barely pause on it.

Here's why it matters so much. The conventional reading is that these are nine independent failure modes, each requiring its own technical solution. Network problems need better network architecture. Software issues need better testing. Capacity problems need better scaling. And each vendor can point to their slice of the chart and say "we fix that part," and they're often right about their slice.

But the flatness itself is in fact the diagnostic clue that something else is going on. Nine unrelated failure categories don't land within eight percentage points of each other by coincidence. They land that way when they're all symptoms of the same underlying condition. Network issues, software bugs, human error, capacity problems: these aren't nine independent diseases. They're nine ways that the same organizational gaps express themselves in production. Poor feedback loops, misaligned incentives, the distance between how leaders imagine work happens and how it actually happens, insufficient learning from failure: these systemic causes don't prefer one failure category over another. They just make all of them more likely, roughly equally.

Think of it like a doctor seeing a patient with fatigue, headaches, joint pain, and skin problems all at similar severity. You could treat each symptom with a different specialist and a different prescription. But the flat distribution across unrelated systems is itself the signal that something systemic is driving all of it. Treating the headaches won't help the joints, because neither is the actual problem.

This is what makes tool-first approaches to resilience so seductive and so ultimately inadequate. If one cause dominated, say network issues at 70% and everything else in single digits, you'd have a clear technical problem with a clear technical solution. But when the failure profile is this even, the slices are the wrong unit of analysis entirely. No single technical investment will meaningfully shift the overall failure rate, because the technical categories are where the problems surface, not where they originate. The only intervention that touches all nine simultaneously is the organization's ability to detect, respond to, and learn from whatever breaks next, regardless of category. That's an organizational capability, not a technology purchase.

This inability to see symptoms as symptoms, to keep treating the surface categories as root causes and reaching for technical fixes to organizational problems, is exactly why I wrote Why We Still Suck at Resilience. And here, in a vendor's own dataset, is the evidence for the entire thesis of the book.

The report also shows that 100% of organizations already do some form of resilience testing, yet 71% do no failover testing, 62% skip regular backup and restoration exercises, and the average outage still takes over three hours to resolve. The tooling exists. The organizational capability to use it effectively does not.

Cockroach Labs collected data that illuminates exactly this, but unfortunately drew a technical conclusion from organizational evidence. Of course, I understand why. But somebody needs to measure the layer they skipped: the feedback loops, the gap between how leaders think work happens and how it actually happens, the tensions that keep organizations stuck even when they know what's broken. That's the data nobody is collecting systematically, and it's where the actual answers live. I’ll get to that in 2026.

Full report here if you want to read it yourself: https://www.cockroachlabs.com/guides/the-state-of-resilience-2025/

//Adrian

A few days ago, AWS announced that the AWS Serverless Agent Plugin is now in the Anthropic plugins marketplace. Install it in Claude Code, Kiro, or Cursor, and your AI agent can analyze your codebase, recommend services, generate infrastructure as code, estimate costs, run security scans, and deploy. In the same two-week window, AWS shipped two more capabilities: one that lets agents initialize SAM projects, wire up event-driven architectures, enforce least-privilege IAM, and instrument observability from the start; and another that guides developers through building checkpointed, durable Lambda workflows that can run for up to a year.

The pitch was "best practices by default." Security, observability, resilience baked into the AI-guided workflow from day one. The agent doesn’t just write the code, it now architects the application.

I want to take that claim seriously and follow it somewhere uncomfortable.

***

For most of my career, architecture was the thing you fought about in design reviews. Microservices or monolith. Event-driven or request-response. Step Functions or roll your own. Saga pattern or two-phase commit. These were consequential decisions because they were hard to reverse, expensive to get wrong, and shaped how your system would fail for years to come. The architect's value was in knowing which tradeoffs to make given the specific constraints of a team, a product, a moment.

But here's the thing. If an agent can scaffold an event-driven architecture with EventBridge, SQS, and DynamoDB Streams in the time it takes me to open a Miro board, and if a different agent can rearchitect that same system next quarter when the requirements shift, then the architecture starts to matter less as a decision and more as a snapshot. It's whatever the system happens to be shaped like right now. It's not the thing you chose. It's the thing the agent chose on your behalf, and it might choose differently tomorrow.

I went looking for people making this argument; that architecture is becoming an implementation detail rather than a design decision. I found two camps.

The first camp says architecture matters more now because AI collapses feedback loops. When you can scaffold an API, generate tests, and wire monitoring in minutes, bad architectural decisions surface immediately. AI doesn't eliminate the need for architecture, it amplifies the cost of getting it wrong. That's true, but I think it's backward-looking because it assumes humans will continue to be the ones making and evaluating those decisions.

The second camp talks about architects moving from "in the loop" to "on the loop" to eventually "out of the loop," shifting from making decisions to designing the system's ability to design itself. That's closer, but it still frames the architect as the essential human in the picture, just at a higher level of abstraction. It imagines a gentle transition rather than a structural shift.

Neither camp follows the logic to its endpoint yet, at least that I'm aware of.

***

Here's where I think this goes.

If agents can architect, deploy, maintain, and rearchitect systems to deliver a given function, then the architecture becomes a runtime variable. Nobody "chooses" it any more than you choose which TCP packets get retransmitted. The agent optimizes and the system runs. That’s it. The patterns shift underneath you based on load, cost, failure conditions, whatever the agent is optimizing for at that time. Architecture stops being the thing you decided in a design review six months ago and becomes something closer to a continuously evolving state that the agent manages.

At that point, the question "what's the architecture?" becomes roughly as interesting as "what's the current state of the routing table?" Technically answerable, practically irrelevant to most of the humans involved.

And if architecture becomes fluid, something that agents can swap to maintain function, then the whole discipline of making architectural decisions starts to look like something temporary. Not because the decisions were wrong, but because the decisions stop needing to be made by humans at all.

I know this sounds like a story about architects losing their jobs, and it is, partly. But it's also a story about something much more delicate.

***

An agent that maintains function "at all cost and at all architecture" is optimizing for one thing: keeping the system running. And chances are that it will eventually be very good at it. It will rearchitect around failures. It will find workarounds for degraded dependencies. It will swap patterns, add retries, reroute traffic, spin up compensating services. From the outside, the system will look healthy. The dashboards will be green. The SLOs will be met.

But "running" and "healthy" are not the same thing.

The agent is unlikely to notice that the system has drifted so far from anyone's mental model that no human can reason about it anymore. It won't flag that the reason it keeps having to rearchitect is that an upstream dependency changed its data contract six months ago and nobody told anyone. Of course, in theory, agents could track contract changes across teams by pulling the latest API spec, reconcile, adapt. And mostly they will. But "mostly" is where the trouble lives. When agents handle 99% of cross-team coordination flawlessly, the 1% they miss becomes invisible precisely because everything else is compensating for it. The system holds together until it doesn't, and when it doesn't, every successful compensation that masked the gap becomes part of the blast radius. It won't recognize that the system is technically meeting its SLOs while slowly becoming incomprehensible.

This is a version of the prevention paradox running at machine speed.

When human operators kept systems running, there was a natural limit: the operators themselves. They got tired. They complained. They filed tickets. They said "this is getting ridiculous" in postmortems. The friction of human maintenance was a signal. It was an ugly, expensive, inefficient signal, but it told you something about the health of the system that no dashboard could capture. The operator's frustration was information about the gap between how the system was supposed to work and how it actually worked.

Agents don't get frustrated. They don't have the felt sense that something is getting ridiculous. They just keep compensating. And every successful compensation is a small act of hiding the true state of the system from the humans who are nominally responsible for it.

In my last newsletter, I wrote about David Woods' observation that AI doesn't solve your problems, it moves them somewhere you can't see. This is the next step in that sequence. AI didn't just move the problems, it actually moved the architecture. And when the architecture is fluid, managed by agents, shifting underneath you to maintain function, the gap between what the system is doing and what you think it's doing doesn't shrink. Instead it grows. Mostly because the agents are papering over it constantly, and every successful paper-over makes the gap a little harder to see.

***

There's a concept from resilience engineering that I keep returning to: the WAI-WAD gap; Work-As-Imagined versus Work-As-Done. In every organization, there's a difference between how people think the system works and how it actually works. The interesting failures happen in that gap.

In a world where architectures are fluid, managed as a runtime variable by agents, the WAI-WAD gap takes on a new dimension. It's no longer just that humans have an outdated mental model of a stable system. It's that the system itself is changing, continuously, underneath a mental model that was never designed to track continuous change. The architecture you reviewed last quarter might bear no resemblance to what's running today. And nobody noticed because the function never degraded.

This is what makes the "best practices by default" pitch from the AWS announcement both true and misleading. The practices are there, security and observability are instrumented, resilience patterns are in place. At time of deployment, the system is well-architected. But architecture is not a point-in-time property anymore. It's an ongoing relationship between a system, its operators, and its environment. And that relationship degrades when nobody can see the system clearly anymore.

***

I don't think the response to this is to resist agents managing architecture. That ship has already sailed. Developers will use them because they're pretty useful and the productivity gains are there.

But I think the response is to recognize that what matters is shifting. The important question was never really "what architecture should we use?" It was always "is this system healthy?" Those two questions used to be tightly coupled because architecture was stable and you could reason about health by reasoning about structure. If the architecture was sound, the system was probably healthy. If the architecture had known weaknesses, you knew where to look.

When architecture becomes fluid, that coupling breaks. You can no longer infer health from structure because the structure keeps changing. Health becomes something you have to measure directly, continuously, and independently of whatever the agents are doing underneath.

That's a different discipline than architecture. It's closer to what I'd call operational awareness. It’s the ability to see the gap between what the system is doing and what you think it's doing, even when (especially when) the metrics say everything is fine. It requires understanding not just the function but the cost of the function, the drift of the function, the comprehensibility of the function.

Agents that architect applications are a real and meaningful capability. But the thing they're automating was never the hard part. The hard part was always understanding whether the system you built was actually doing what you thought it was, in the way you thought it was, at a cost you could sustain. That question just got harder, not easier.

//Adrian

May 17, 2010

AWS had four regions. US East, US West, Europe, and Asia Pacific. That was the whole cloud, more or less. Most companies running serious workloads were still asking whether they could trust it at all.

That morning, Jeff Barr published a blog post. It was short, technical, conversational in the way Jeff always was. He was announcing that RDS now had a “High Availability” option. He called it Multi-AZ. One parameter, set to true, and Amazon would spin up a hot standby in a second availability zone, synchronously replicate every write, and fail over automatically in about three minutes if the primary went down. Your application wouldn't even need to know it happened.

In 2010, high availability for a managed database meant your DBA had a plan and a phone number to call at 2am. It meant runbooks, manual failover scripts, and potentially someone driving to a data center. The notion that a piece of infrastructure could sense its own failure and reconstitute itself, invisibly, while your application kept serving traffic, was new to most of the people reading that post.

Jeff wrote that availability zones had "independent power, cooling, and network connectivity." Fourteen words that would quietly become load-bearing assumptions for an entire industry.

For the next fifteen years, those fourteen words held. Until they didn't.

***

For about sixteen years, I believed in multi-AZ the way you believe in gravity.

Every architecture review I sat in, every Well-Architected assessment, every "is this prod-ready?" Operational Readiness Review pointed to the same thing: spread your workload across availability zones and you've handled the big one. I never really questioned it, neither did the people I worked with. At some point it stopped feeling like a design decision and started feeling almost like a law of nature.

Then a single event took down two Asian regions simultaneously. And the assumption didn't bend. It shattered.

Around the same time, a different assumption cracked. Not in one dramatic moment, but across a series of events that added up to the same thing. Trump sanctioned the International Criminal Court, and Microsoft implemented those sanctions, locking the ICC's chief prosecutor out of his Outlook email. A Microsoft executive then told a French Senate committee, under oath, that the company cannot guarantee European customer data will never be handed to US authorities because the CLOUD Act requires US companies to comply with US government requests regardless of where the data physically sits. European data stored in European data centers, operated by a US company, is still subject to US law.

Two load-bearing assumptions, gone inside a few months.

***

There's a pattern here that I keep coming back to, and I think it sits at the intersection of psychology, probability, and how organizations actually work.

When an assumption holds long enough, it stops being an assumption. It becomes furniture. You stop seeing it because it was always there. And crucially, every day it holds true feels like evidence that it was always correct. The confidence compounds and the scrutiny fades.

That's a measurement error. We're tracking frequency, not fragility. The assumption isn't getting stronger with each passing day. The exposure is just accumulating quietly, out of sight.

This is what makes the prevention paradox so insidious. The longer nothing goes wrong, the more confident you feel. The more confident you feel, the less you invest in questioning the foundations. And so the fragility grows precisely because things have been going so well.

Scientists have a name for the thing that prevents this trap: falsifiability. A good scientific hypothesis is one that can, in principle, be proven wrong. You hold it provisionally. You actively look for the counterexample. The absence of failure doesn't confirm the hypothesis; it just hasn't been refuted yet.

Organizations are terrible at this because falsifiability is uncomfortable. Treating your foundational assumptions as provisional feels destabilizing. It requires admitting that what you built on might not hold. Most organizational cultures punish that kind of questioning, or at least fail to reward it.

So we get this strange situation: some of the most technically sophisticated organizations in the world run on assumptions they've never seriously stress-tested; Multi-AZ as physics, cloud providers as neutral infrastructure, and government as a stable, predictable background condition.

***

Taleb's black swan is often misread as a story about rare events but I think it's more a story about accumulated fragility. Everything that was quietly wrong beforehand, the untested assumptions, the confidence that compounded without scrutiny, the floor that was never as solid as it felt. The event just ends the period of not knowing. What follows is disorienting precisely because the ground shifted under something we stopped questioning years ago.

I think this is worth sitting with, because the reflex after a shattered assumption is usually to over-react, replace it with a new one, and move on. We update the architecture, patch the policy, and add multi-region to the checklist. And then, gradually, the new assumption starts to calcify too.

The harder question you should ask yourself now is: what are we still treating as physics that isn't?

I don't have a clean answer. But I think the practice, the actual resilience practice, is to hold your foundational assumptions more loosely. To ask periodically: if this turns out to be wrong, what breaks? To make the questioning normal rather than exceptional. To treat "hasn't failed yet" as exactly what it is: a run of confirming evidence, not proof.

That's uncomfortable and it requires a kind of epistemic humility that organizations tend to select against. But the alternative is waiting for the next black swan to do the work for you.

//Adrian

Estimated read time: 9 minutes

There's a seductive story about AI in operations that goes something like this: we have problems, let's deploy AI, it will fix them. Incidents will resolve faster, anomalies will get caught earlier, postmortems will draft themselves in minutes instead of hours, metrics will improve. I've been hearing this story recently and I don't doubt the promise, but improved metrics and solved problems are not the same thing. The problems don't go away when the metrics get better; they go somewhere else, take new forms, and show up in places nobody thought to look. The question is where they go, and what they look like once they get there.

I've been circling this question for a while. About a year ago I wrote about AI meta-operators and system responsibility, trying to work through what happens when AI agents start making operational decisions that used to require human judgment. More recently I wrote about chaos engineering for AI-generated code, arguing that the velocity and opacity of AI-assisted development demands systematic stress-testing because human review alone can't keep pace. In both cases I could feel the problems but I couldn't connect them, couldn't see why the same kinds of trouble kept showing up in different forms. In my book I argue that a common vocabulary is one of the most underrated tools in resilience work, because once you can name something you can discuss it, and once you can discuss it you can start to act on it. What I was missing was exactly that: a vocabulary for what AI does to the mess rather than just the mess itself.

***

David Woods has been mapping exactly that. He has been developing a heuristic he calls the Messy 9, which he recently premiered on the Fine Pod podcast and discussed on in the Resilience in Software Foundation Slack channel. It's designed to bridge the science of how complex systems actually work and the practical need to do something about it. The setup is what Woods calls GCA: patterns over cycles of Growth, Complexification, and Adaptation. When new technological capabilities affect ongoing worlds of practice, processes of growth, complexification, and adaptation play out in lawful patterns, and stories of technology change should capture or envision the new forms of messiness that arise when apparent benefits get hijacked. The core message is that the messiness of the real world is conserved over attempts to improve systems, conserved in the formal sense described by the No Free Lunch and Robust Yet Fragile theorems: you don't eliminate messes, you move them.

Woods organises the recurring forms into nine patterns, grouped in threes: (1) congestion, cascades, and conflict; (2) saturation, lag, and friction; (3) tempos, surprises, and tangles. He describes them as a small set of generic keys you can use to unlock any episode of change to see how messes reappear, with much of the action living in the cross-connects and overlaps between them. Each points to processes that play out over time as systems grow, and each takes on unfamiliar forms when AI enters the picture.

Congestion, in Woods' framing, is what happens when a bunch of things are going on simultaneously and you have to deal with them all in the time available. Cascades are disturbances propagating across lines of interdependency, where one failure dumps load onto adjacent functions and the effects spread. Conflict is the question of who loses, who sacrifices, what gets prioritised when there's overload, what gets sacrificed first and what gets sacrificed later. These three are the most visible forms of messiness, and in traditional distributed systems we've built tooling to handle them: circuit breakers, bulkheads, load shedding, runbooks. But when AI is the operator, these patterns migrate into territory that existing tooling can't see.

Consider what cascading failure looks like when one model's output feeds another model's judgment, which triggers a third model's action. The failure propagates through reasoning rather than network calls and retry logic. A subtly wrong interpretation becomes a confident decision becomes an automated action, and the whole chain looks healthy from the outside because every component is performing exactly as designed. The cascade is there, running through inference rather than infrastructure, and it remains invisible until the consequences arrive in a form nobody anticipated.

Saturation, in Woods' framework, is what happens when a system approaches the boundary where it runs out of capacity to deal with challenges, where different subsystems start dumping more overload onto other places and the saturation spreads. In traditional systems this means hitting a resource limit you can see, measure, and plan for. AI introduces a different kind: decision saturation, where AI handles enough operational decisions that the humans nominally overseeing it lose the ability to meaningfully evaluate what it's doing, simply because the volume and speed of AI-driven decisions exceed what human attention can track. The oversight saturates while the system hums along, and nobody notices because the dashboards still look green.

Lag is what Woods describes as the pattern where organisations cut the resources they need to integrate new capabilities before they have actually integrated them, anticipating productivity gains and reducing experience, expertise, and people before the ostensible benefits have materialised. This is playing out everywhere right now: teams are being restructured around AI productivity assumptions while the actual work of figuring out where AI fits, where it doesn't, and what new failure modes it introduces is still in its earliest stages. The resources being cut are the very resources needed to discover whether the new capability actually works as advertised.

Friction undergoes an equally counterintuitive transformation. Woods frames friction as a necessary feature of bringing capabilities into practice, the offsetting costs and workload that arise when something new meets the complexity of the real world, and warns that if you underplay it, the things you try to deploy turn out not to work as well as you would like. The old friction in operations was obvious: manual processes, handoffs between teams, slow approval chains. AI removes it, which feels like progress, but friction served a function. It slowed things down enough for people to notice when something was off, created natural pause points where someone might say "wait, does this actually make sense?" Removing the friction removes the speed bumps that gave humans a chance to catch problems before they compounded, making the system faster and smoother while also making it more brittle in ways that only surface when speed and smoothness were exactly the wrong thing.

Tempos, the seventh pattern, describe what happens when different rates of change collide. In DevOps this is already familiar: the tempo of development influences operations, operations constrains development, and incident response introduces its own urgency that overrides both. AI adds new tempos that don't match existing ones: the speed at which models make decisions versus the speed at which humans can review them, the rate at which AI-driven changes accumulate versus the rate at which organisations can absorb their implications. These tempo mismatches create their own congestion as decisions pile up faster than the capacity to evaluate them.

Surprises, the eighth pattern, are not about rare events at the tail of a distribution. Woods insists that the dragons of surprise don't get weaker and more infrequent as systems improve; instead, systems generate new categories of surprise as they change. AI is particularly good at producing novel categories because it fails differently from humans. When a human operator makes a mistake, other humans can usually reconstruct the reasoning and see how someone under pressure with incomplete information made a wrong call. When AI makes a mistake the reasoning is opaque, nobody can explain why, which means nobody can confidently say it won't happen again in a different form, which means the organisation can't learn from it in the way it has always learned from human error.

The tangles might be the most troubling of all. Woods describes tangles as circular dependencies and strange loops, the kind of thing he first encountered in nuclear power plants where a critical function depended on an instantiation of itself. When multiple AI systems operate with overlapping domains, one monitoring infrastructure, another triaging incidents, a third managing capacity, they develop implicit dependencies that exist nowhere in any architecture diagram, learning to compensate for each other's behaviour in ways their operators never specified. These tangles are invisible during normal operations and surface during failure, when one system's unexpected behaviour cascades through compensation patterns that nobody knew existed, creating a debugging problem that is qualitatively different from anything human operators have encountered before. Woods gives a vivid example from the current AI gold rush itself: we need critical infrastructure to support AI computations, AI is being deployed to reduce the people who operate that infrastructure, and the AI doing the operating depends on the infrastructure it's supposed to be operating. The circular dependency is already there.

All of this converges on what Woods identifies as the key constraint: extra adaptive capacity is most needed when least affordable. AI adoption is a period of significant system change that demands more adaptive capacity, more ability to recognise and respond to novel situations, precisely because the system is in flux and the new failure modes haven't been mapped yet. AI adoption also consumes adaptive capacity, because organisations use it as a reason to reduce the human expertise that provides it. The need goes up while the supply goes down, and that gap is where the real risk lives, in a place that improved operational metrics will never show you.

None of this means AI is bad for operations; the improvements are real and sometimes substantial. The story that AI is going to solve your problems is almost certainly incomplete, because as Woods puts it, the Messy 9 exists to counter the tendency we all have to see whatever we develop as solving something instead of moving things and shifting processes. AI solves the problems you are measuring while generating new ones you haven't learned to see yet, and the messes migrate to places that your current instrumentation and your current organisational structure are not designed to detect. If you're deploying AI into your operations and your metrics are getting better, the question worth asking is where the mess went, because messiness is conserved over cycles of change. It takes new forms and it operates at new scales, and that puts a higher premium on exactly the experience, skill, and expertise to figure out how the system is working when it's not working the way you thought it was.

//Adrian

The last few months have been pretty quiet in here, and the reason is the same reason this piece exists. I wrote a book. It is called "Why We Still Suck at Resilience," and you can get it here.

If you have been following me for any length of time, you will recognise the argument even if the packaging is new. Organizations confuse performing resilience with actually being resilient, and the five practices that are supposed to manage that gap (chaos engineering, load testing, GameDays, incident analysis, operational readiness reviews) have drifted so far from their original purpose that they often make the problem worse. The book is an attempt to say clearly what I have been circling around in LinkedIn posts and on my blog, that the gap between how we imagine our systems work and how they actually work is growing, and most of what we are doing about it is theater.

The idea started during my time at AWS, where I helped build the Fault Injection Service and spent a decade working with some of the world's largest organizations on how they practice resilience at scale. I saw teams running chaos experiments that confirmed what they already believed rather than discovering what they did not know, load tests scoped to pass rather than to learn, incident reviews that produced action items nobody followed up on because the organizational incentives pointed elsewhere. The patterns were consistent enough across companies, industries, and team sizes that I became convinced the problem was not individual teams failing to execute. Something structural was going wrong, something about the way organizations relate to learning under pressure, and I wanted to understand what it was.

Writing the book took longer than I expected, partly because I kept discovering that the problem was deeper than I had initially framed it. What started as a practitioner's guide to doing these five practices well became something more like an investigation into why organizations systematically undermine their own capacity to learn from failure. The research pulled me into safety science, into Bainbridge and Rasmussen and Woods, into the gap between Work-as-Imagined and Work-as-Done, and into the uncomfortable recognition that I had been part of the problem myself. I built tooling that optimised for individual practice metrics while ignoring the learning system those practices were supposed to form. The value of resilience work lives in the connections between practices, in how an incident finding becomes a chaos experiment becomes a readiness review question, and nothing we had built supported those connections.

The final chapter turned out to be the one that mattered most, both for the book and for where my thinking is already going. It is about AI, but not in the way you might expect. Every observability vendor now offers AI-powered anomaly detection, every incident platform promises AI-drafted postmortems, and the marketing suggests these tools will finally eliminate the gap between how we imagine our systems work and how they actually work.

Just this week, Norberto Lopes at incident.io posted about their AI-generated postmortem capability, calling it a mind-blowing moment, celebrating that the write-up was accurate, well-contextualised, and took zero time to draft. Around the same time, Ozan Unlu published a piece describing what he calls Observability 3.0, a vision in which AI agents handle incident triage, root cause analysis, and postmortems autonomously, with humans elevated to "creativity and innovation" while machines do the interpretive work. I do not doubt that either of these tools produces excellent output. What worries me is that the productive struggle of writing a postmortem, or correlating signals during an incident, or reasoning through why a system behaved the way it did, is where most of the actual learning occurs. The document was never really the point; the thinking that produced it was. The interpretation was never the bottleneck; it was the training ground. When you skip the thinking and get a better document, or remove humans from the sensemaking and call it empowerment, you have made a trade that is easy to celebrate and difficult to measure the cost of until much later, when something breaks and the organization discovers it no longer has the understanding it assumed it was building all along.

Bainbridge identified this dynamic in 1983: automation designed to remove humans from a system paradoxically makes the human role both more critical and more difficult, because it removes the routine experience that builds expertise. AI is a higher form of the same problem, one that does not just automate tasks but automates the judgment and reasoning that create the deepest understanding.

I believed that argument completely while writing it, and the speed at which I have started questioning it has caught me off guard. Over the past few weeks, there has been a growing conversation among engineers and researchers ( here for example) about a noticeable leap forward in the latest generation of models, not just in raw capability but in the quality of reasoning. For the first time, my experience starts to mirror what others are describing.

I have been using Anthropic's Claude, both the Opus 4.6 model and its extended thinking variant, and what unsettled me was the texture of how it worked through problems. On coding tasks that required sound architectural judgment, the kind where there is no clean answer and the trade-offs depend on context that has to be reasoned about rather than looked up, the model was both producing correct outputs and thinking through the problem in ways that felt uncomfortably close to how a senior engineer thinks through it. It would express uncertainty about its own choices, flag trade-offs I had not raised, change direction mid-reasoning when it encountered something that complicated its initial approach.

Doubt, revision, context-sensitivity; these are what learning looks like. They are, in cognitive science and education research, the established preconditions for understanding: cognitive conflict that exposes mismatches between a mental model and reality, willingness to reorganise prior knowledge rather than just accumulate new information, and attention to context as the thing that determines whether knowledge transfers or stays brittle. The assumption that has underpinned my thinking, that when automation fails it will be humans who catch the fall, rests on the belief that machines cannot do the interpretive work. If that belief is wrong, or even if it is only wrong for long enough that organizations stop maintaining human capability in the meantime, then the question of who fixes what when things break becomes genuinely open in a way it has never been before.

I do not say that to be dramatic, and I do not have a clean resolution. The book makes a case I still think is largely right: that organizations need to protect the productive struggle, the learning that comes from humans wrestling with ambiguous problems, because that struggle is where durable understanding forms. What I am less sure about is whether the time horizon for that argument is decades or years, and the difference between those two answers changes everything about how I think about the work ahead.

Which brings me to what is next. In my consulting work at Resilium Labs, AI in operations has slowly become a recurring topic in nearly every engagement. Clients who originally brought me in to diagnose their chaos engineering, load testing, operational readiness, and incident review process are now asking questions about what AI is doing to their teams' ability to understand their own systems. The conversations are shifting because the problem is shifting, and the methodology I have always used (embedded observation, stakeholder interviews, tracing the gap between how people imagine work happens and how it actually happens) turns out to apply directly to organizations trying to figure out whether their AI adoption is building genuine capability or creating new blind spots they have not learned to see yet. The work is evolving because the organizations I work with are evolving, and the questions they need answered are no longer only about resilience practices in the traditional sense.

There will be more writing here in the weeks ahead, pieces that work through these questions. If anything in the book resonates, or if it does not, I would like to hear about it.

//Adrian

“La flamme de la résistance française ne doit pas s’éteindre et ne s’éteindra pas” - Charles de Gaulle, appel du 18 juin 1940

When I was a kid growing up near Grenoble in France, veterans of the Second World War came to our school to talk about the resistance. The region around Grenoble was a hotspot for the French Resistance, and many of the surrounding villages lost generations of men in the war. The veterans were old by then, and they knew they didn't have many visits left.

I remember very clearly what one of them said:

"My biggest worry is that once we are all gone, no one will be there to tell the story, and people will make the same mistakes again."

I thought about him this week while reading Ray Dalio's latest piece, "It's Official: The World Order Has Broken Down". At the Munich Security Conference, multiple world leaders said the same thing: the post-1945 order no longer exists. German Chancellor Merz: "The world order as it has stood for decades no longer exists." Macron: Europe must prepare for war. Rubio: we are in a "new geopolitics era" because the "old world" is gone.

The veterans are gone now. And here we are.

Dalio frames this through his "Big Cycle," a pattern that repeats across centuries. A dominant power wins a conflict, builds institutions and rules, and establishes an order that works. Over time, the stability that was produced by all that investment starts to look like it was always there. Investment in maintaining it declines. The institutions hollow out. Then a crisis arrives and everyone discovers the order was already gone long before the crisis hit.

I kept reading, and I kept seeing the prevention paradox.

Effective prevention creates doubt about its necessity

In my book and this blog post, I describe a pattern that plays out with painful regularity inside technology organizations. A serious incident creates the political will to invest in resilience. A strong coalition builds institutions: incident review processes, chaos engineering programs, operational readiness reviews, feedback loops that institutionalize resilience thinking. It works. Stability becomes normal. And then the stability that was produced by the investment starts looking like the natural state of things rather than something that requires active maintenance.

Then a newly appointed leader asks:

"What exactly does your team do? I see a lot of salary costs, but what are the deliverables?"

The team scrambles to explain their value but doesn't have the data to back up their claims. "We prevented failures" doesn't translate well to budget spreadsheets. The practices get cut. The degradation that follows gets attributed to other causes. The cycle repeats.

The post-1945 world order followed the same arc. The catastrophe of two world wars created the political will to invest in international institutions: the United Nations, NATO, the Bretton Woods system, trade agreements, alliances. A strong coalition (led by the US) built and maintained them. They worked. Decades of relative peace and prosperity followed.

And then the stability that those institutions produced started looking like it was always there.

The better you prevent problems, the fewer problems exist to justify preventing them

This is the core of the prevention paradox. Our brains struggle to value non-events. The availability heuristic means we judge importance by how easily examples come to mind. Dramatic incidents are memorable. Non-events leave no trace. There's no story to tell about the war that didn't happen.

Hindsight bias compounds the problem. Once we know the benign outcome, we reconstruct the past as if failure was never very likely. After decades of relative peace, people conclude "clearly the threat was overstated" rather than recognizing "nothing happened because we took appropriate precautions."

At the organizational level, I've watched this play out with chaos engineering programs, incident review processes, and operational readiness reviews. The more effective they are, the more unnecessary they appear. At the geopolitical level, the same dynamic hollowed out commitment to the institutions that prevented great power conflict for 80 years.

The costs of maintaining the order were always visible: military spending, diplomatic effort, economic concessions, compromises on sovereignty. The benefits were counterfactual: wars that didn't happen, conflicts that got resolved before they escalated, trade disputes that didn't become economic wars. When decisions require weighing visible costs against hypothetical benefits, visible costs carry more weight.

New leaders who never experienced the crisis

In the chapter, I describe how the leaders who question resilience investment often aren't people who forgot what the work does. They're people who never experienced what the work prevents. They joined during the stable period that effective resilience created, and from their vantage point the stability looks like the natural state of things.

The VP who asked "what exactly does your team do?" wasn't ignoring history. He had no history to ignore. He inherited a system that worked and saw a team whose purpose he couldn't connect to any problem he'd experienced.

At Munich, we're watching the geopolitical version. An entire generation of leaders grew up inside the stability the post-war order produced. They inherited institutions that worked and saw costs they couldn't connect to any catastrophe they'd lived through. The people who built the post-war order, the people who remembered the destruction that justified it, are gone. Their memory of why it mattered left with them.

That veteran in my school saw this coming forty years ago.

Dalio points out that the leaders now declaring the old order dead are in fact acknowledging something that's been happening for years, through eroding commitments, hollowed-out alliances, and institutional decay that went mostly unnoticed while the surface structures remained in place.

Stage 6 creeps in

One of Dalio's most useful observations is that the breakdown doesn't start with the shooting war. It starts years earlier with economic wars, technology wars, capital wars, and geopolitical maneuvering. By the time the shooting starts, the underlying order has been gone for a long time.

I describe the same pattern at the organizational level. Practices continue but without the depth. Chaos experiments drift toward safe scenarios. Incident reviews stay at surface-level fixes. GameDays become scripted performances. The practices become theater while appearing unchanged. The degradation is invisible because the surface activities continue, even as the learning capacity underneath erodes.

The international institutions didn't collapse overnight either. The UN still meets. NATO still exists. Trade agreements are still on paper. But the commitment behind them has been eroding for years. The practices became theater while appearing unchanged.

By the time a significant incident occurs, the causation is thoroughly obscured. Months or years have passed between the reduction in investment and the consequences. The delay prevents connecting the cuts to the outcomes. Each generation of leadership learns through fresh pain.

The cycle isn't inevitable

Dalio ends his chapter with something that I think is worth holding onto. He says the cycle doesn't have to end in catastrophe, if countries "stay productive, earn more than they spend, make the system work well for most of their populations, and figure out ways of creating and sustaining win-win relationships."

In my book, I argue the same: the pattern is predictable, but it can be navigated. It requires treating stability as an output that needs continuous input, not a resting state. It requires building institutional memory that survives the people who experienced the original crisis. It requires celebrating prevention rather than only celebrating heroic response. And it requires leadership that remembers why the institutions were built in the first place, even when everything looks fine.

Whether we're talking about an engineering organization or the world order, the prevention paradox operates through the same mechanism. Success erases its own evidence. The world order didn't break down last week in Munich. It broke down gradually, over years, as the commitment to maintaining it eroded while everyone assumed it would just persist on its own.

One of the commenters on Dalio's piece, Mike Wagner, put it nicely: "A lot of what we built assumed stability was just there in the background, and that assumption is gone."

That's the prevention paradox, at every scale.

//Adrian

You've done everything right.

You ran the hypothesis conversation. Your team discovered they had different mental models of how database failover works. You investigated the gaps. You fixed the connection pool configuration and the health check logic. You added monitoring for connection pool state.

Then you ran the experiment. Database fails over, circuit breaker trips, traffic routes to the replica, recovery completes in 30 seconds. Everything worked exactly as expected.

Three months later, the database fails during peak traffic. The system enters a death spiral. Circuit breakers trip and reset in rapid cycles. Connection pools exhaust. The replica becomes overloaded. Health checks start failing on healthy instances. Retries amplify the load. Recovery takes 23 minutes of manual intervention.

You tested this exact scenario. It worked perfectly. What happened?

You tested at the wrong load.

During your experiment, you ran with minimal traffic. Maybe some synthetic requests, maybe just manual testing. Production was handling 800 requests per second when the database failed.

That difference activated completely different system dynamics.

Why load changes everything

Systems with spare capacity behave as if they were deterministic. The same inputs produce the same outputs. Failures are reproducible. You can reason about what will happen and predict outcomes.

When systems run near their limits, they become non-deterministic. The Universal Scalability Law predicts this: contention and coherency costs cause non-linear performance collapse beyond critical load thresholds. Several mechanisms combine to create this shift.

Bimodal components. A cache either hits or misses. A circuit breaker is either closed or open. A connection pool either has available connections or is exhausted. A health check either passes or fails. Each is a binary state change that delivers radically different behavior

At low load, mode transitions don't matter much. A cache miss? The database has spare capacity. A circuit breaker opens? Other instances absorb the traffic. You have operational margin to absorb these transitions.

At high load, the same transitions cascade. A cache miss means the database is already near its limit, so the additional query causes queueing, which slows all queries, which triggers timeouts and retries. A circuit breaker opening means remaining instances are already near capacity, so redirected traffic pushes them over, causing their circuits to open.

Queueing effects. At low load, a cache miss adds one query to a queue of 10, and the impact is marginal. At high load, a cache miss adds one query to a queue of 10,000. The queue is already near capacity, and that additional query pushes it deeper into the non-linear region where waiting time explodes. This affects all subsequent requests, not just the one that missed.

Concurrency races. At low load, if two instances' circuit breakers both approach their trip thresholds, they trip at different times because request patterns vary enough. The first trips, load redistributes, the system absorbs it.

At high load, many instances approach thresholds simultaneously. One trips, load redistributes, and the redistribution pushes others over. They all trip within seconds of each other, and you get synchronized state transitions across your entire fleet rather than gradual failover.

Resource cascades. At low load, one slow request holds a thread a bit longer, but other threads are available and nothing cascades. At high load, one slow request holds a thread when no other threads are available. Incoming requests queue, the backup causes timeouts, timeouts trigger retries, and retries push thread pools deeper into exhaustion. Circuit breakers watching these timeouts approach their thresholds and trip. Three systems have now changed state because one request was slow at the wrong moment.

Timing variations. Which request becomes slow depends on factors you can't control. A database query lands on a disk performing compaction. A network packet gets delayed by congestion. A GC pause happens at an unfortunate moment. Under low load, these variations don't matter. Under high load, whichever request is slow can trigger a cascade.

Run the same chaos experiment five times at low load and you get consistent results. Run it five times at high load and you get five different outcomes. You're not seeing randomness. You're seeing emergent behavior from multiple interacting mechanisms whose states you can't precisely control.

Metastability: when resilience mechanisms prevent recovery

This pattern has a name: metastability. Researchers studying large-scale system failures identified this pattern and gave it a precise definition: failure states sustained by the system's own behavior, not by any ongoing external problem.

The trigger is gone. The database is back. The network is healthy. Every component passes health checks. But the system serves almost no useful work because the resilience mechanisms you built now create more load than the system can handle.

The cache can't rewarm because database load is too high. The circuit breaker can't close because retry load prevents downstream recovery. The connection pool can't replenish because failures happen faster than connections establish. The health checks can't pass because load redistribution keeps instances above the timeout threshold.

Your system occupies one of three states:

This diagram shows the relationship between load and goodput, with the three distinct system states.

Inspired by: https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf

The green curve shows the stable state. Goodput scales with load. The system has spare capacity, so it can absorb triggers and self-recover. This is where your chaos experiments typically run.

The blue line shows the vulnerable state. The system operates efficiently near its limits. Goodput stays high, but there's little margin. A trigger (the fire icon) can push the system off this line.

The red dashed line shows metastability. Goodput collapses to near zero even though load remains high. The system has fallen off the curve entirely. Positive feedback loops prevent recovery.

The dotted arrows show what happens: a trigger pushes the system from vulnerable down into metastable failure, and it takes intervention (and reducing load significantly) to get back up to stable.

The state diagram in the corner shows the transitions. Stable can drift into vulnerable. Vulnerable can fall into metastable failure when a trigger activates sustaining effects. Metastable requires intervention to escape. You can't just remove the trigger and wait for recovery.

Two practices that should be one

Most organizations run load testing and chaos engineering as separate activities. The load testing team validates capacity. The chaos engineering team validates failure degradation. The two rarely meet.

Load testing without failure injection shows you how the system performs when nothing goes wrong. Chaos engineering without realistic load shows you how the system handles failures when it has spare capacity to absorb them. Neither tells you what happens when failures occur under production load.

That combination is exactly what production delivers. And that vulnerable region is exactly where you need to run your experiments to find the triggers that will collapse your system into metastability.

Finding those triggers before production does is what chaos engineering and load testing are for. But you can only find them by testing in the vulnerable region where production operates.

What this means for your experiments

The hypothesis conversation reveals gaps in your team's mental models. Investigation and fixing address the knowable problems. But there's a third category we didn't fully explore: emergent behavior that only appears under load.

When you design experiments for uncertainty gaps, the ones where behavior emerges from component interactions, you need to test under realistic load. Not "some" load. Production-equivalent load.

Your experiment design from the last newsletter asked: "We want to know how our application's retry logic interacts with database failover under realistic traffic load."

Realistic traffic load is the key phrase. If you test at 50 requests per second and production runs at 800, you're testing a different system. The stable regime behaves deterministically. The vulnerable regime behaves non-deterministically because queueing effects amplify, concurrency races synchronize, resource cascades chain, and timing variations that didn't matter suddenly determine outcomes.

Same code. Same architecture. Same failure injection. Completely different outcomes.

Try this

Take one of the uncertainty gaps you identified in your hypothesis conversation. Design the experiment as we discussed, with specific predictions about timing, behavior, and recovery.

Then ask yourself what load level does production actually experience during peak hours? Can you run your experiment at that load level?

If you can't, you're testing in the stable region. Your results will give you false confidence about triggers that only activate in the vulnerable region where production operates.

You want to find those fire icons in the diagram before production finds them for you. That requires chaos engineering and load testing together.

Until then,

Adrian

Last time, I walked you through the hypothesis conversation, how to discover that your team has completely different mental models of how your system behaves, all before running any chaos experiment.

Several of you replied with stories. One team discovered that nobody knew whether their cache actually had an eviction policy. Another found out their "automatic" failover required some manual steps. A third learned that their monitoring would completely miss the failure mode they were worried about.

Good. That's exactly what should happen.

Now comes the harder question: what do you actually do with all these gaps you just discovered?

Most teams make one of two mistakes here. Either they panic and try to fix everything immediately, or they shrug and run the experiment anyway "just to see what happens."

Both are wrong. Let me show you a better path.

Three types of gaps

When you run a hypothesis conversation, you uncover three distinct types of gaps. Each requires a different response.

Type 1: Knowledge gaps

These are gaps in understanding where the answer exists somewhere. You just need to find it.

"Does the circuit breaker have a timeout?" "What's our connection pool size?" Someone knows. It's in the code or configuration. You just need to look it up.

What to do: Investigate before experimenting.

Don't run a chaos experiment to answer questions you can answer by reading code, checking configuration, or talking to the team that built the thing. That's using a sledgehammer when you need a magnifying glass.

Spend an hour investigating:

• Read the relevant code

• Check configuration files

• Look at past incidents where this failed

• Talk to the team that owns the component

• Review any existing documentation

Update your mental models based on what you find. Then reconvene and share what you learned.

Half the time, this investigation reveals more gaps. "Oh, I thought Steve configured that, but he left six months ago and nobody knows if it's still set up that way."

Perfect. Now you know what you don't know.

Type 2: Uncertainty gaps

These are gaps where nobody knows the answer because the behavior emerges from interactions between components.

You can understand every component separately and still have no idea what happens when they all run together under specific conditions.

You checked the code. The connection pool has reconnection logic. The database has failover logic. The load balancer has health check logic. The application has retry logic. Each piece makes sense. The implementations look correct.

But when database failover happens during peak traffic while the cache is cold, what actually happens? Do the retry storms from 50 application instances create a thundering herd that prevents the database from recovering? Does the load balancer pull instances out of rotation before they stop retrying, or after? Do the health checks start passing before the connection pool is actually ready, sending traffic to instances that will just error?

Nobody knows for certain and it is hard to reason about. You can't know from reading the code because the answer depends on timing, load, and how these different components interact under load.

That's emergence. The behavior comes from the interaction, not from the individual components.

What to do: Design experiments specifically to explore these interactions.

This is what chaos engineering is actually good for. Testing things where behavior emerges from complexity, where understanding the parts doesn't tell you how the whole system behaves.

Before you design the experiment, get specific about what interaction you're uncertain about:

"We're uncertain how our retry logic interacts with database failover during high traffic. Each component looks correct in isolation, but we've never validated whether they work together without creating cascading problems. We need to know because retry storms could turn a 30-second database blip into a 90-minute outage."

Now you can design an experiment:

• Inject database unavailability with realistic load

• Watch how retry behavior scales across all instances

• Monitor whether health checks and retries synchronize badly

• Track whether the database can actually accept connections when it comes back

• Observe the recovery timeline end-to-end

The experiment has a clear learning goal. You're testing how components interact under specific conditions, not whether individual components work.

You'll probably need to run this experiment under multiple conditions. Behavior that emerges from interaction often depends on load, timing, system state. What happens at 2 AM with low traffic might be completely different from what happens during peak hours.

Type 3: Design gaps

These are gaps where you discover something is missing or wrong in your system design.

"Wait, we don't have a circuit breaker at all? I thought we did."

"Our health check doesn't actually validate database connectivity, it just returns 200 OK?"

"There's no monitoring for connection pool state?"

These are real problems you just discovered. These aren't knowledge gaps. These aren't uncertainties.

What to do: Fix them before experimenting.

Don't run a chaos experiment to confirm that something you know is missing or broken is actually missing or broken. That's not learning, that's theater.

If you discover your health check is shallow when it should be deep, fix the health check. If you find out you're missing critical monitoring, add it. If the circuit breaker doesn't exist, decide whether you need one.

Some teams resist this. "But we want to see how bad it is!"

No. You don't learn from deliberately breaking things you know are broken. You just create risk and waste limited resources. And your system will anyway behave differently once to address the missing or broken components.

Fix the known problems first. Then experiment to find the unknown problems.

The investigation phase

Let's say you ran your hypothesis conversation and discovered 15 different gaps. Don't immediately schedule 15 chaos experiments.

Instead, spend time investigating. Create a gaps document. List everything you discovered. Sort the list into these three buckets. Knowledge gaps we need to investigate. Uncertainties we need to experiment on. And design problems we need to fix.

Assign investigation work. Split the knowledge gaps among team members. Give people a week to investigate their assigned areas. This is building shared understanding before you create any risk.

Gather again. Have each person share what they learned. You'll find that investigating knowledge gaps often reveals more uncertainties or design problems. That's good. You're getting more precise about what you actually don't know.

Update your gaps document based on the investigation.

Prioritizing what to test.

You've investigated the knowledge gaps. You've fixed the obvious design problems. Now you're left with genuine uncertainties about how components interact.

You probably can't test all of them immediately and because resources are limited. So prioritize.

Priority 1: High-impact, high-uncertainty

These are failure modes that would cause significant customer impact if they happened, and the behavior emerges from complex interactions you can't predict.

High stakes. Real uncertainty from emergence. Test this first.

Priority 2: High-impact, low-uncertainty

These are scary scenarios where you think you know how components interact, but the stakes are high enough that validation is worth it.

You probably won't learn too much. But confirming that critical interactions work as expected has confidence value.

Priority 3: Low-impact, high-uncertainty

These are things you're uncertain about but wouldn't cause major problems if the interactions failed.

"We're not sure how cache warming and background jobs interact during deployment, but worst case some requests are slower."

Interesting to know. Not urgent to test.

Priority 4: Low-impact, low-uncertainty

Don't test these at all. You're confident about how components interact and the impact is minimal.

Save your time and energy for experiments that actually teach you something important.

Designing your first experiment

Let's say you've prioritized and you're ready to design your first experiment. You've picked: "Test how retry logic and database failover interact during realistic load."

Here's how to design it:

Start with your learning goal

Be explicit: "We want to know how our application's retry logic interacts with database failover under realistic traffic load. Specifically, whether retries from multiple instances create problems for database recovery, and how long the system actually takes to return to normal."

Document the hypothesis clearly (before you start)

Start with your system properties:

"Each application instance maintains a connection pool of 20 connections. Connection timeout is set to 5 seconds. Under normal load, instances handle 50 requests/second. When a connection attempt fails, the pool marks that slot as failed and retries. Applications implement retry logic with 100ms base delay and 2x exponential backoff for a maximum of 4 retries (100ms, 200ms, 400ms, 800ms)."

Now you can make predictions:

"When the database becomes unavailable, each instance will experience connection failures at 5-second intervals. At 50 requests/second with 20 available connections, the pool will exhaust in approximately 0.4 seconds (20 connections / 50 requests/second). Applications will begin returning errors immediately. The retry sequence will complete in 1.5 seconds per request (100 + 200 + 400 + 800). After 4 failed retries, requests will return 500 errors to clients."

"When the database becomes available again, connection pools will attempt reconnection on the next incoming request. With staggered health checks running every 10 seconds across 12 instances, we expect the fleet to detect database availability within 10 seconds. Each instance will establish 20 new connections, taking approximately 100ms per connection (2 seconds total per instance). We expect 90% of traffic to succeed within 15 seconds of database recovery.”

This gives you specific measurements. You know what to instrument (pool exhaustion rate, retry timing, connection establishment time, error rates). You know what success looks like (90% traffic succeeding within 15 seconds). You can validate each number independently.

Specific. Measurable. Testable.

Plan what you'll observe

List all the specific things you want to watch. Be specific. If you can't observe these things, stop. Add the missing observability first. Don't run experiments you can't interpret.

Start small and safe

Do your first run in the development environment, limited blast radius, low traffic, manual injection.

Don't overcomplicate things. Dont’ start with production. Don't start with peak traffic. Don't start with automated injection. Build confidence progressively.

Run it and observe

Actually run the experiment. Watch what happens. Take notes. Don't try to fix things during the experiment. Just observe and learn.

Compare hypothesis to reality. What matched your expectations? What surprised you?

Write a detailed summary of the experiment. Ideally using the same process as your real incidents.

"The connection pool exhausted in 0.6 seconds, roughly matching the 0.4-second prediction. Applications returned 500 errors immediately. The retry sequence timing matched our implementation exactly: 1.5 seconds per request before final failure.

When the database came back online, the first instance detected it in 4 seconds through health checks. It started establishing connections. At 18 connections established, the instance crashed. Out of memory error.

We had overlooked connection cleanup. When the database went down, failed connections stayed in the pool marked as dead but not garbage collected. When the instance tried to establish 20 new connections, it actually had 20 dead connections plus 20 new ones. Memory usage spiked. The JVM killed the process.

The crash triggered our orchestration system to start a replacement instance. That instance came up, detected the healthy database, tried to establish connections, and crashed for the same reason. This happened to 8 instances before we caught it.

The remaining 4 instances stayed alive because they had been restarted recently for unrelated reasons. Their connection pools were clean. They successfully connected and started handling all traffic. Four instances serving the entire load meant each was now processing 150 requests/second instead of 50. Response times jumped to 800ms. Error rates climbed to 12% due to request timeouts.

We had to disable automatic instance replacement and manually restart each instance with connection pool cleanup logic added. Recovery took 23 minutes. The hypothesis predicted connection establishment time correctly. We never considered connection lifecycle management or the interaction between pool state and instance stability."

That's learning. The individual components worked correctly but the interaction between them, at scale, under realistic conditions, created new behavior hard to predict.

Now you know and have choices.

Option 1: Add explicit pool cleanup to your health check logic.

When the health check detects database unavailability, call pool.close() to force cleanup of all connections, then reinitialize the pool. This guarantees a clean state before attempting reconnection. The downside is a brief period where the instance can't serve requests during pool recreation, maybe 200-300ms. You need to ensure your load balancer can handle instances briefly going unhealthy.

Option 2: Configure connection max lifetime in the pool settings.

Set maxLifetime to something like 30 minutes. The pool will automatically evict and replace connections that exceed this age, regardless of their state. This prevents accumulation of dead connections over time. The tradeoff is ongoing connection churn during normal operation, which adds latency (probably 5-10ms per replaced connection). You also need to tune the lifetime value. Too short and you create unnecessary overhead. Too long and you don't solve the problem.

Option 3: Implement connection validation on checkout.

Configure the pool to test connections before handing them to the application (testOnBorrow or equivalent). Dead connections get removed when the application requests them. This distributes cleanup across request processing rather than concentrating it at recovery time. The cost is added latency on every request, typically 1-5ms depending on your validation query. During the outage, you still accumulate dead connections, but they get cleaned up gradually as traffic arrives rather than all at once during reconnection.

You'll probably want to test this again after selecting the option for the fix. Emergent behavior depends on conditions, so you validate solutions under the conditions that matter.

What's next

Last time I showed you how hypothesis conversations reveal what your team actually believes about your system. This time you learned what to do with those gaps: investigate the knowable, fix the broken, experiment on the emergent.

Most teams skip straight to breaking things. You now know better. The learning happens in the conversation, the investigation, and the careful observation of how components interact under real conditions. The chaos experiment is just one tool in that process.

Try this with your team. Start with the hypothesis conversation from last newsletter. Work through the investigation phase. Pick one uncertainty about emergent behavior and design an experiment around it.

Then tell me what you discovered.

Until then,

Adrian

Dr. David Woods, one of the pioneers of resilience engineering, said something a few of us have been repeating and it captures the essence of why chaos engineering is valuable:

"Just planning to inject a fault usually reveals that the system works differently than you thought."

Most teams skip straight to running chaos experiments. They pick a tool, design a failure scenario, inject the fault, observe what happens. They think the learning happens during the experiment.

They're wrong. The deepest learning often happens before you break anything at all.

Here's what I mean.

The meeting you've probably been in

You're discussing what happens when X fails. Someone says "obviously the circuit breaker kicks in." Everyone nods. The conversation moves on. Meeting ends.

Three months later, X actually fails in production. The circuit breaker doesn't work the way anyone thought. Or it doesn't exist at all. Or it exists but was disabled during a migration last quarter and nobody remembered to re-enable it.

The problem is that everyone had different mental models of how the system works. Nobody discovered this until real failure exposed it.

This happens constantly. Teams operate under the illusion of shared understanding. Everyone uses the same words. Everyone nods at the same moments.

Then something breaks, and you discover nobody actually agreed about how anything worked.

The hypothesis conversation

Here's what to do instead. Before running any chaos experiment, gather your team and have what I call the hypothesis conversation.

Step 1: Pick a specific failure scenario

Don't start with "what if the database goes down?" It’s too vague.

Instead start with something like: "What happens when our primary PostgreSQL instance becomes unavailable during peak traffic?"

The specificity matters. Vague scenarios produce vague answers. Specific scenarios force people to articulate their actual mental models.

Step 2: Silent writing first

This is the critical step most teams skip.

Before any discussion, have everyone write down:

• What they expect to happen

• How long they expect recovery to take

• What customer impact they expect

• What monitoring and alerts they expect to see

Give people 5 minutes of silence to write.

Why silent writing? Because it prevents groupthink. In open discussion, the loudest person always speaks first. Suddenly everyone's nodding along. The quieter team members, who might have spotted something nobody else considered, stay silent. You've just lost the diversity of perspective that makes this valuable.

Silent writing forces everyone to commit to their understanding before social dynamics kick in.

Step 3: Share and compare

Go around the room. Have each person read what they wrote.

No judgment. No critique. Just listen.

This is where it gets interesting. You'll discover:

Someone assumes automatic failover that doesn't exist. Another person thinks there's queuing that isn't implemented. The new engineer admits they have no idea what happens. That’s valuable honesty the rest of the team needs to hear. The senior engineer describes behavior from the old architecture, before the migration two quarters ago. Nobody agrees on expected recovery time.

Your team has been working together for months or years. You thought you understood how the system works. You're discovering right now that you don't share the same understanding at all.

Step 4: Investigate the gaps

Don't just note the disagreements and move on. Dig into them:

"Why did you think queuing was implemented?"

"When was the last time we actually tested failover?"

"Where is that behavior documented?"

"Who would know the answer to this?"

Often you'll discover that nobody knows for certain. The system evolved. Documentation didn't keep up. People made assumptions based on how they thought things worked. Those assumptions never got validated.

Step 5: Decide what to do

Now you have options:

Run the chaos experiment to find out what actually happens. Check the code or configuration to verify behavior. Talk to the team that owns that component. Update documentation based on what you learned. Fix the gap you just discovered.

You might decide the experiment is still valuable. But you've already learned something critical: your team doesn't share the same mental model of how your system behaves. That's worth knowing regardless of what you do next.

Real example

I watched this play out at a company planning their first database failover experiment few years ago.

The team gathered to discuss expectations. Everyone seemed aligned. "Database fails over to replica, maybe 30 seconds of elevated errors, everything recovers." Heads nodded. The consensus felt solid.

Then they did silent writing.

When everyone shared, the room got quiet.

It turns out the DBA expected 10-15 seconds of failover time based on the configuration settings. Application engineers expected 30-60 seconds based on what they'd seen in past incidents. The SRE thought the connection pool would need manual restart because that's how it worked in the old system. A junior engineer thought reads would continue but writes would fail. That was actually a reasonable assumption given the architecture. The architect assumed the application would automatically reconnect after failover. Nobody was sure if the health check would detect the failover or keep routing traffic to the failed instance.

Six people. Six different mental models of the same system behavior.

They spent the next 30 minutes investigating:

Checked the database configuration. Failover timeout was actually 30 seconds, but nobody had tested it recently. They looked at application code. Connection pool settings were wrong, they'd never refresh connections after a failover. Reviewed health check logic. It would completely miss the failover and keep sending traffic to the dead instance. Found monitoring gaps. No visibility into connection pool state, so they wouldn't see the problem during the experiment.

They fixed three critical issues before running any experiment:

• Updated connection pool configuration to handle failover

• Fixed the health check logic

• Added monitoring for connection pool state

When they finally ran the experiment two weeks later, they knew what to expect and what to watch for. The failover worked. More importantly, they'd built shared understanding of how their system actually behaves.

Return on investment

The hypothesis conversation took 45 minutes. In that time, they discovered:

• Critical gaps in monitoring

• Incorrect connection pool configuration that would have caused extended downtime

• Missing health check logic that would have routed traffic to a dead instance

• Misaligned team understanding of basic system behavior

All before creating any risk, touching any systems, or needing any special tools.

Compare this to what usually happens: run the experiment, something unexpected occurs, scramble to understand what went wrong, argue about whether the system is working correctly or the experiment is flawed, end up more confused than when you started.

The hypothesis conversation is chaos engineering!

You're systematically exploring how your system behaves under failure. Sometimes that exploration happens through conversation. Sometimes through code review. Sometimes through documentation analysis. Sometimes through actual experiments.

But the learning doesn't wait for the experiment. It starts the moment you begin asking the right questions.

Start tomorrow

Here's your homework for this week:

Pick your scenario

Choose something specific that your team worries about. "What happens when [specific service] becomes unavailable during [specific condition]?"

Don't pick the scariest scenario. Pick something bounded and concrete. You're learning the practice, not stress-testing your team.

Get the right people in the room

You need diversity of perspective. Developers who wrote the code. Operators who run it in production. New team members who haven't absorbed all the assumptions yet. The architect who designed it. The SRE who monitors it. Include product managers too.

Six to eight people is ideal. Enough for diverse perspectives, small enough for real conversation.

Set the context

Before you start, frame it clearly:

"We're not testing anyone's knowledge. We're discovering where our mental models differ. There are no wrong answers. The goal is to find gaps in our shared understanding before they surprise us in production."

This framing matters. People need to feel safe admitting uncertainty.

Do the silent writing

Give people 5 minutes. Remind them to be specific. What exactly do you expect to happen? Not "it'll probably be fine" but "the circuit breaker will trip after three failed requests, fallback logic will return cached data, customers will see stale information for 30-60 seconds."

The specificity reveals the mental model.

Share without judgment

Go around the room. Have each person read what they wrote.

Don't critique. Don't correct. Don't debate yet. Just listen and note where understanding differs.

Resist the urge to immediately resolve disagreements. First, just hear all the perspectives.

Investigate together

Pick the biggest gaps. The places where mental models differ most.

Dig into them as a group. Check the code. Look at configuration. Review documentation. Talk to other teams.

Find out what actually happens. Update your understanding together.

You'll learn more in 30 minutes than most chaos experiments reveal.

What's next

Try this with your team this week. Then hit reply and tell me:

What gaps did you discover? Were you surprised by anything? Did you fix something before running any experiment? What happened when you tried to investigate the gaps?

I read every reply. Your experiences help me understand what actually works in practice, not just in theory.

Next newsletter: "What to do after the hypothesis conversation". How to design experiments that actually test what you're uncertain about, not just what you already know.

Until then,

Adrian

AI-generated code has moved from curiosity to almost standard practice with breathtaking speed. Teams use AI to build entire features and even applications. Code generation tools translate requirements directly into pull requests. What took a developer days now takes minutes and a carefully crafted prompt. When done right, the AI productivity gains are real. Teams shipping AI-assisted code go faster.

The question facing engineering organizations today isn't whether to adopt these tools—developers already have—but how to understand and operate systems built with them safely.

The Acceleration of an Old Problem

Let’s be honest, code opacity didn't start with AI. Every engineering organization battles the same demons: developers leave, context evaporates, documentation rots, deadline pressure produces shortcuts. Six months after launch, someone gets paged at 3 AM to fix a system they didn't write and barely understand. This story is older than version control.

AI-generated code didn’t create this problem but it accelerates it to speeds we've never seen before.

A developer writing code makes choices—explicit or implicit—about tradeoffs, edge cases, and failure modes. They might not always document these choices well, but they existed as conscious thoughts, at least momentarily. You can pull them into a meeting room and ask: "Why did you implement it this way?" They might not remember perfectly, but there's a conversation to have, a human memory to question.

AI-generated code compresses this process into statistical inference. The model chose an implementation based on patterns in its training data, optimizing for likelihood rather than your specific domain constraints. Three months later, when that code fails under unexpected load, there's no developer to ask. The model that generated it no longer exists in the same form—weights have shifted, training has evolved, the context window that held your requirements has long since evaporated. You're maintaining systems written by "intelligences" that can't yet fully be recalled for questioning.

The velocity compounds everything. When one developer writes problematic code, that's one problem to debug. When AI helps fifty developers write code twice as fast, you've potentially scaled both the productivity and the technical debt by orders of magnitude. The same old problems happens at unprecedented speed and volume.

Humans Are Still in the Loop

Let's be clear about what actually happens: AI doesn't drop code directly into production. A developer prompts the AI, reviews what it generates, modifies the output, integrates it with existing systems, AI writes tests, and shepherds it through code review. Humans remain deeply involved.

The challenge emerges from volume and velocity. When you're reviewing thirty AI-generated pull requests weekly instead of ten human-written ones, can you maintain the same focus and scrutiny? When the code looks correct—follows conventions, passes linters, handles obvious failure cases—how often do you catch the subtle problems that only emerge under production conditions the AI never considered?

Human review remains essential, but it faces scaling limits. We need systematic methods for stress-testing AI-generated code that complement human judgment. This is where chaos engineering can help.

Why Chaos Engineering Fits This Moment

Traditional code review asks: "Does this code do what it claims?" Chaos engineering asks: "What does this code do when everything goes wrong?" That second question becomes critical when you're shipping code whose internal logic you inherited rather than invented.

Run a chaos experiment that injects latency into downstream services. Watch which components start failing in ways nobody predicted. Maybe the AI-generated service client retries aggressively without backoff, turning a minor slowdown into a cascading failure. Code review might have caught this if the reviewer specifically looked for retry logic and thought to question its implementation. Chaos engineering catches it by creating the conditions where the problem reveals itself.

The difference becomes clearer over time. You discover patterns: this model's code tends to assume infinite memory; that model's error handling releases resources inconsistently. These insights feed directly into how you prompt AI going forward, what you hunt for in code review, and where you concentrate your testing.

How Chaos Engineering Must Evolve

Traditional chaos engineering assumed code written by humans. Humans you could ask questions to. That assumption breaks down when substantial portions of your codebase emerge from statistical models.

Automated Knowledge Capture

Every chaos experiment that reveals unexpected behavior should generate structured documentation automatically. When an experiment discovers that an AI-generated service degrades catastrophically under certain conditions, the experiment should produce:

- Structured description of the failure mode(s)

- Metrics thresholds indicating the problem emerging

- Potential mitigation steps based on observed and learned behavior

- Links to specific code exhibiting the issue

Engineers review and refine these auto-generated artifacts rather than writing them from scratch. This automation matters because AI code generation produces more components faster than humans can document manually. The documentation gap will become a problem without systematic capture.

Feedback Loops into Code Generation

Here's where things get interesting. Your chaos experiments discover that AI-generated clients consistently lack good retry logic. This gap appears across multiple services. You document it, but more importantly, you can now update your prompts to account for this shortfall: "Implement retry logic with exponential backoff and jitter pattern with these specific thresholds […]"

AI-generated code improves because chaos engineering taught you what to demand. You can feed experiments findings directly into prompt libraries—an identified gap becomes a constraint in every subsequent request.

With such feedback loops, you can continuously update your prompts based on chaos experiments findings, shortening the critical learning cycle.

Pattern Detection at Scale

AI code generation creates an unusual opportunity: many components share similar origins. They emerged from similar models, responding to similar prompts, applying similar patterns from training data. Studies about code generation errors often identify recurring patterns or clusters of failures specific to certain models.

Chaos engineering tools can exploit this and systematically search for patterns common to specific AI models.

When you find these patterns once, hunt for them everywhere across all AI-generated components simultaneously, discovering not just that Service A has a problem, but that twelve services share variants of the same flaw because they were all generated using similar models.

Continuous Experimentation

AI enables shipping dozens of features weekly, each containing substantial generated code. Chaos experiments need to keep pace. However, embedding chaos experiments directly into CI/CD pipelines creates significant problems—the non-deterministic nature of chaos experiments conflicts with the deterministic requirements of deployment pipelines, experiments require production-like load and extended runtime. The solution is a separate, dedicated chaos pipeline running parallel to your CI/CD pipeline, allowing experiments to operate on their own schedule without blocking deployments while still feeding findings back into development practices.

Note: For teams seeking deterministic validation in their CI/CD pipelines, deterministic simulators offer a middle ground. Tools like Antithesis model distributed system behavior deterministically, allowing exploration of failure scenarios with reproducible results. While they require significant investment to build and maintain, and can't capture all real-world complexities, they provide faster feedback than full chaos experiments while being more comprehensive than mocked tests. They work well in pipelines but should complement, not replace, chaos experiments against production-like environments.

The AI Testing AI Question

Could we use AI to design chaos experiments for AI-generated code? The idea is indeed seductive: provide an AI with code it generated previously plus observability data, then ask it to design experiments that would catch emerging issues.

This approach shows promise in my own experiments. With the right prompt, AI-designed chaos experiments sometimes target edge cases humans overlook, precisely because the AI recognizes patterns in generated code that humans don't consciously notice.

But we should still remain skeptical and in the loop. Both AIs operate from similar statistical foundations. They share similar blind spots—the AI experiment designer often misses the same edge cases the code generator misses, for exactly the same reasons. An AI trained primarily on historical data still struggles to imagine creative, realistic failure scenarios that don't appear commonly in training data.

Like for other AI generated artifacts, the key seems to use AI to generate candidate experiments, but require human engineers to review, refine, and prioritize them. AI handles the breadth—proposing dozens of scenarios quickly. Humans handle the depth—identifying which scenarios matter most for your specific systems and constraints.

We're learning by doing, and the lessons keep changing.

Final Thoughts

You just simply can't afford to opt out of the race while competitors embrace AI-assisted development. The productivity gains is just too substantial. Teams using these tools effectively ship features faster. Like with most innovations, organizations that hesitate eventually lose ground against competitors who've figured out how to capture the upside while managing the downside.

The choice facing engineering leaders isn't "AI-generated code: yes or no?" Market forces already made that decision. The real choice is: "How do we operate systems built with AI assistance safely and sustainably?"

Chaos engineering offers a practical answer. By systematically exploring how systems fail, you build the operational understanding that rapid AI-assisted development threatens to erode. You discover hidden dependencies before they cause outages. You document failure modes before customers encounter them. You create feedback loops that improve both your code generation practices and your operational capabilities.

The machines write the code. Chaos engineering helps us understand what we've built and guides what we build next.

After a decade of helping organizations improve their resilience practices, I keep seeing the same puzzle. Companies invest heavily in operational readiness reviews, well-architected reviews, incident reviews, chaos engineering, alerting, monitoring, etc. They have leadership buy-in, dedicated teams, and sophisticated tooling. Yet despite having all the right pieces, many still struggle to build genuine resilience.

The more I observe this pattern across industries, the more convinced I become that we're dealing with something fundamental about human psychology, and how our natural responses to uncertainty systematically undermine the very resilience we're trying to build.

The Evolutionary Trap

The human brain evolved to treat uncertainty as potential danger. When we don't know what's coming next, our amygdala activates, triggering stress and the urgent need to regain control. This served our ancestors well when uncertainty meant immediate physical threats, but it creates problems in complex organizational systems.

We're pattern-seeking creatures who prefer clear cause-and-effect relationships. When faced with ambiguity, we instinctively impose structure with rules, procedures, and approval gates that provide the illusion of predictability, even when they can't actually remove the underlying uncertainty.

Think about what happens after an outage. Teams naturally default to adding more approval gates, extending checklists, requiring additional sign-offs. Each control feels rational in isolation and provides psychological relief by making us feel we're "doing something" about the problem.

But together, these controls create systems so constrained that engineers can't respond effectively when something truly unexpected happens. The very mechanisms designed to prevent problems end up preventing the adaptive response that could have avoided a bigger failure.

Research reveals exactly why this backfires. Organizations that handle crises well are those that can flexibly navigate different responses during real emergencies, rather than simply following rigid procedures. Yet our natural response to past failures is to create more rigid procedures.

When outcomes are uncertain, our decision-making shifts from calculation to heuristics and mental shortcuts. We fall back on availability bias (overweighting recent incidents) and confirmation bias (seeking information that supports our existing beliefs about what went wrong). This leads to controls that address the specific failure we just experienced while missing the broader patterns that create system brittleness.

The desire for predictability is so strong that we often choose the feeling of control over the reality of safety. This explains why organizations continue tracking metrics like MTTR even when teams understand it's mathematically meaningless, or why they maintain cumbersome approval processes that become rubber stamps but create friction during emergencies.

Controls vs Guardrails

The key to understanding and solving this problem is recognizing that most organizations blur a crucial line between two fundamentally different approaches to safety: controls and guardrails.

Controls dictate how work gets done. They're prescriptive, active during normal operations, and create friction for everyone, regardless of whether there's any actual danger. Like tollbooths on a highway, they slow down every single person, every single time, even when there's no safety issue.

I've seen many organizations create elaborate chaos engineering processes with good intentions. They want to prevent teams from causing unintended damage. But these weeks-long coordination requirements create cognitive overload that makes teams avoid learning activities entirely. That's a control masquerading as a safety practice.

The most telling sign that controls have gone too far is when engineers stop raising concerns because "the process doesn't allow for that" or "nobody would listen anyway." That's adaptive capacity disappearing in real time.

Guardrails, on the other hand, define safe operating boundaries while preserving flexibility within those bounds. Like highway guardrails, they activate only when you're approaching real danger, not during normal operations. They make the safe path also the easy path.

Think of it like ziplining in a forest. The controls approach says "Ziplining is dangerous, so we'll require permits, 6 weeks of training, and supervised access only on Tuesdays." Result? Nobody ziplines, or people sneak in and zipline without any safety equipment because the official process is too cumbersome.

The guardrails approach says "Ziplining is dangerous, so here's a harness, safety line, and helmet." The safety equipment enables the risky activity rather than preventing it. People zipline frequently and safely because the gear only constrains them when there's real danger such as weight limits exceeded, equipment failure, or bad weather.

A guardrail approach to chaos engineering might provide lightweight frameworks with ready-made integrations, but allow teams to adapt scope, timing, and focus based on what they're trying to learn about their specific systems. The safety comes from built-in blast radius limits, automatic rollback procedures, and environment isolation, not from bureaucratic overhead.

This distinction shows up everywhere once you know to look for it. I've seen incident reports describing production access processes as "cumbersome," creating friction during the exact moments when adaptive capacity matters most. The irony is that these access controls often become rubber stamps. When so many people need production access for legitimate work, approval processes default to "yes" without real scrutiny.

Meanwhile, guardrails like automated safety checks, environment-specific tooling, and default read-only permissions would actually prevent dangerous actions without slowing down normal troubleshooting.

The pattern is often exacerbated during incident reviews. Organizations naturally gravitate toward quick fixes after outages. The urgency to "do something" drives teams to immediately jump to finding root causes and generating action items. But as John Allspaw observes in his excellent talk Incident Analysis: How *Learning* is Different Than *Fixing*, when "your goal is to fix, you're gonna fix something whether or not it was the right thing to fix," and "once teams find a plausible fix, time and production pressure cause them to stop exploring other options."

Incident Analysis: How *Learning* is Different Than *Fixing* - John Allspaw

Here's the trap I see many organization fall into: when incident reviews become focused on quick fixing rather than deep understanding, they systematically generate more controls. Each incident generates new approval processes, additional checkpoints, and longer procedures. Every. Single. Time. The very mechanism meant to build resilience ends up eroding it through control accumulation.

A guardrails approach to incident learning resists the temptation for quick fixes. Instead, it focuses on understanding "what was difficult for people to understand during the incident, what was surprising for people about the incident.” Answering these difficult questions helps design better guardrails.

The difference is critical: quick incident reviews create controls and bureaucracy, while deep understanding-focused reviews help create good guardrails and in turn build adaptability.

But wait, what happens when engineers take shortcuts that bring down critical systems?

This question becomes crucial when we consider why people work around safety measures. In my experience, there are two distinct patterns:

Systematic workarounds where multiple people consistently bypass the same controls reveal design problems. When everyone ignores a safety measure because it conflicts with getting work done effectively, that's feedback that the control isn't designed for the reality of the work environment.

Individual violations where someone consciously ignores a safety protocol despite understanding the risks represent accountability issues requiring different responses such as training, supervision, or removal from roles.

The key difference is in the data pattern. One person removing a safety device represents an individual problem. Everyone consistently working around the same procedure indicates a system design problem requiring guardrail redesign, not more enforcement. When operational staff or engineers consistently bypass safety measures, it's usually because those measures force them to choose between being safe and being effective. That's a design problem, not a people problem.

For the small percentage who truly are bad actors, attempting to prevent malicious behavior through process controls is futile. If someone really wants to cause trouble, they'll find a way around controls. This is where foundational security principles become essential: comprehensive auditing that records every action, immutable infrastructure that can't be tampered with, and "detect, isolate, replace" strategies. These work as guardrails. They don't prevent every possible action through approvals, but they make malicious changes visible and automatically containable.

You can't control your way out of determined bad actors, but you can architect systems that make their actions obvious and limited in scope.

Breaking the Cycle

The human tendency toward adding controls against uncertainty is so deeply wired that even organizations with excellent resilience instinct and intentions fall into this trap. After incidents, the cultural pressure to "do something" combined with our psychological need for control creates an almost irresistible urge to add approval gates, extend procedures, and create more detailed documentation.

The path forward requires consciously auditing our practices through a controls vs guardrails lens. Where are we creating friction during normal operations when we should be creating safety boundaries? Where are we demanding compliance when we should be enabling adaptation?

The goal isn't eliminating all structure, it's not! Instead it’s ensuring our structure enables the adaptive capacity that makes systems genuinely resilient rather than just compliant.

Here's the important bit: resilience comes from systems that can learn and adapt, not from preventing all possible changes. When we build tollbooths instead of guardrails, we optimize for the feeling of control rather than the reality of safety.

Smart guardrails enable adaptation by making the safe path also the effective path. Rigid controls kill adaptation by forcing people to choose between following procedures and solving problems.

To really improve resilience, organizations need to understand this distinction and design safety mechanisms that activate when needed but don't interfere with normal operations. They need to measure outcomes that matter rather than compliance metrics that feel good. They need to create psychological safety that enables people to surface problems early rather than hide them to avoid bureaucratic friction.

Most importantly, they need to recognize that our instinctive response to uncertainty—adding more controls—is often the enemy of the adaptive capacity that creates real resilience.

You don't make dangerous activities safe by preventing access. You make them safe by giving people the right safety equipment and boundaries.

Addendum: Intent and Context Matter

A recent discussion with Fred Hebert made me realize I had left out something important: the controls vs. guardrails framework isn't just about technical implementation, it's also about human psychology, organizational context, and the often-unconscious biases that shape how we respond to uncertainty.

Whether something functions as a control or guardrail often depends on intent and context, not just implementation. Consider peer code review:

• As a Control: Management mandate for compliance, or engineers implementing it because they don't trust each other

• As a Guardrail: Engineers wanting shared awareness and collective understanding

The same technical mechanism serves different purposes and creates different psychological effects based on who decided and why.

This reveals something important. Many controls start as well-intentioned guardrails but drift toward control thinking over time, especially when designed by people detached from the actual work. I frequently see well-intentioned engineers create elaborate controls for things they won't use directly, such as runbooks, reviews, checklists, and templates. This "work-as-imagined" vs. "work-as-done" gap leads to controls that feel logical in theory but create friction in practice.

This tendency is amplified by our engineering training itself. As Fred noted in our conversation, "our whole engineering discipline is often founded on breaking things down analytically, creating the right abstractions to constrain variability, and moving on!" We're taught to reduce complexity by controlling it, which works well for technical systems but can backfire when applied to human systems.

The challenge is that controls themselves become part of the environment and increase potential for unexpected interactions. When we try to limit environmental complexity through rigid procedures, we often create new complexities in how people work around those procedures.

Here's a simple math problem that breaks many organizations.

You have 10 incidents. 9 resolve in 5 minutes each. 1 takes 6 hours (360 minutes).

Your MTTR says 40.5 minutes.

Do you think it tells a good story?

Most of the incidents were short, but your MTTR suggests everything takes 40+ minutes.

The message is simple: Stop using MTTR as your north star metric. The math just doesn't add up and almost never makes any sense.

Similar to the prevention paradox I recently wrote about, where successful resilience work can make itself appear unnecessary, MTTR creates its own illusion while hiding the real story of your system's health.

The Demoralization Effect

A few months ago, I spoke with a platform engineering team that had spent over two years dramatically improving their systems. They'd implemented comprehensive monitoring, automated recovery procedures, and streamlined their incident response. The team was proud of their work, and rightfully so.

But their MTTR dashboard told a different story. Despite all their improvements, the number stubbornly hovered around 85 minutes. Some months it even went up.

The team was demoralized because leadership questioned their efforts. "If you're really improving things, why isn't MTTR going down?"

When we dug deeper, the true story came to light. The team had become really good at detecting small issues early, problems that would previously have cascaded into major outages. They were catching these issues in minutes and resolving them quickly. But they were also tackling increasingly complex infrastructure problems that genuinely took hours to solve properly.

Their stubborn MTTR was actually masking significant progress: minimal customer-impacting outages in 18 months, a 90% reduction in alert fatigue, and a team that had transformed from a reactive firefighting approach to proactive system improvement.

MTTR not only failed to reflect their success, but it actually actively undermined it.

The Math Simply Doesn't Work

MTTR has become the default way organizations measure incident response. Teams dutifully display their MTTR dashboards, track improvements over time, and use these numbers to justify investments, performing operational excellence for leadership rather than actually achieving it.

But there's a fundamental problem. Incident duration data follows a power-law distribution. Most incidents are resolved quickly: a container restart here, a cache flush there. But occasionally, you get the big ones: database corruptions, complex cascading failures, or novel security breaches that can take hours or days to resolve.

When you average that 5-minute container restart with a 6-hour database recovery, you get a number that represents neither reality.

As discussed in the VOID Report, incident duration data follows a positively-skewed distribution where "measures of central tendency like the mean, aren't a good representation of positively-skewed data, in which most values are clustered around the left side of the distribution while the right tail of the distribution is longer and contains fewer values."

The mean gets pulled toward the outliers, creating a metric that doesn't reflect the typical experience of either your users or your incident response teams. In essence, you're using a statistic designed for normal distributions on data that's anything but normal.

This is exactly why teams see their MTTR stay flat or even increase despite genuine improvements. As teams become better at detecting problems early, they catch more small issues that can be resolved quickly.

But as systems continue to evolve, they also tackle more complex problems that naturally take longer to solve properly. The occasional 6-hour incident will dominate the average, making months of 5-minute fixes invisible.

Time Doesn't Equal Impact

But the statistical issues are just the beginning. MTTR misses the actual point.

A 30-minute incident affecting 100,000 users is fundamentally different from a 2-hour incident affecting 5 users. MTTR treats them identically.

Consider these real-world scenarios:

Live streaming platform: Video playback fails for 10 minutes during the final quarter of a playoff game. 50,000 concurrent viewers lose service at the most critical moment. Social media explodes with complaints. Potential subscription cancellations. Customer support is overwhelmed.

Versus: "My watchlist" feature breaks for 2 hours during off-peak. A few dozen users noticed. Minimal business impact, easily communicated via banner notification.

E-commerce site: Your checkout process crashes for 15 minutes during a Black Friday flash sale. Direct revenue loss of an estimated $500K. Abandoned carts. Frustrated customers are switching to competitors. Marketing spend wasted.

Versus: The "recommended items" widget fails for 3 hours on a Tuesday morning. Slight decrease in discovery metrics. No immediate revenue impact. Most users don't even notice.

In both cases, MTTR would suggest the longer incidents were "worse" than the shorter ones.

But which ones actually damaged the business?

Losing a non-critical service for 5 hours isn't the same as losing your most critical one for 10 minutes. MTTR can't distinguish between these scenarios.

The Human Reality

There is an even more fundamental challenge beyond the statistical issues: incidents are inherently human processes, and MTTR completely ignores human and organizational factors.

Real incident response involves complex dynamics that just can't be captured in a simple time measurement.

First, complex incidents often require multiple teams from different organizations, e.g., database specialists, network engineers, security experts, and product managers. Each handoff introduces delays, communication gaps, and potential misalignment that MTTR treats as "inefficiency" rather than important and necessary collaborative work.

Additionally, during high-stress incidents, engineers frequently face new failure modes and must diagnose novel problems, often with incomplete information. The time spent carefully analyzing symptoms to avoid making things worse isn't captured meaningfully by MTTR.

Shift changes, escalation procedures, approval processes, and dependencies on third-party vendors all introduce delays that have nothing to do with technical competence but significantly impact resolution time.

Finally, thorough incident response often involves deliberately slowing down to understand the real problems, verify fixes, and prevent recurrence or cascading effects, especially for large-scale events. MTTR incentivizes speed over precaution and learning, potentially making systems less resilient in the long term.

These human factors introduce variability that makes MTTR practically misleading, while missing the very aspects of incident response that distinguish operational excellence.

When Good Metrics Go Bad

MTTR actively drives counterproductive behaviors when used as a performance metric. When teams are measured by average resolution time, they will often end up optimizing for the metric rather than actual resilience (a process called surrogation), prioritizing quick fixes over understanding the contributing factors (root causes) and rushing to close tickets rather than implementing lasting solutions. This pressure fosters a culture where teams prioritize finding someone responsible rather than addressing systemic issues, while also promoting superficial verification by skipping thorough post-incident testing to close tickets faster. Teams may even game the numbers by avoiding declaring incidents or manipulating start and stop times to improve their averages. These behaviors make organizations less resilient, not more, and ultimately create a culture focused on looking good on dashboards rather than building genuinely resilient systems.

The "Better Metric" Trap

I often see teams recognize MTTR's limitations and try alternatives, such as MTTM (Mean Time to Mitigate) or MTTD (Mean Time to Detect). The thinking goes: "If we measure time to mitigation instead of full resolution, we'll better capture when customer pain stops."

But this also misses the actual issue.

MTTM has exactly the same statistical problem as MTTR. You're still averaging highly skewed data. Whether you measure "time to resolve" or "time to mitigate," the math doesn't change. That same 6-hour outlier will dominate your MTTM just like it dominated MTTR.

The real issue is using averages at all on this type of messy data, not where we draw the finish line.

What to Track Instead

So, what should you measure instead? Great question! And like much of computer science, it depends!

It depends on what you're trying to achieve, but here are better alternatives:

The Dashboard That Actually Tells Your Story

Picture this: You're in a quarterly review. Instead of staring at an MTTR dashboard showing 45 minutes (making your team look bad), you pull up a different set of metrics:

• "99.97% login success rate, only 12 users affected by incidents this quarter."

• "Zero revenue-impacting outages in the last 6 months."

• "95% of incidents resolved in under 8 minutes."

Suddenly, the conversation shifts from "why is your MTTR so high?" to "how did you achieve such results?"

A big part of our work on resilience is about telling the story our work actually deserves.

Metrics shape the story about your team's work. And that story determines everything, from budget approvals to whether leadership views resilience investments as beneficial or not. So get it right!

MTTR often tells a story of mediocrity and failure. Impact metrics and percentiles tell the story of excellence, learning, and genuine improvement. Your choice of metrics shapes the narrative about your team's work, and that narrative in turn influences everything from budget decisions to career advancement.

You must tell the resilience stories in a way that leadership can understand and appreciate.

Focus on Customer Experience

Use Service Level Objectives (SLOs) that measure availability, latency, and error rates from the customer's point of view. Instead of asking "How long did it take to fix?" ask "What percentage of user requests succeeded?"

I worked with a team whose MTTR was consistently "terrible" at 95 minutes. Leadership was frustrated. However, when we looked at their SLOs, it told us a different story: 99.95% uptime, with the vast majority of their "incidents" being minor maintenance work that users never even noticed.

The team had been solving the right problems and preventing customer impact, but the MTTR made them look like they were failing.

Start with user-facing metrics, such as "login requests succeed 99.9% of the time." Focus on what users actually experience, not what your infrastructure is doing.

Impact-Focused Metrics

Impact-focused metrics measure the actual effect of incidents on users, business operations, and system performance:

• Number of users affected

• Duration of user impact

• Revenue loss or business disruption

• Service Level Objective (SLO) violations

• Error rates and availability percentages

• Customer satisfaction scores during and after incidents

Here's a real example: An e-commerce team had two incidents in the same week. Their MTTR dashboard showed:

• Incident A: 3 hours to resolve

• Incident B: 20 minutes to resolve

Leadership asked why the team seemed more concerned about Incident B. But the impact metrics told the real story:

• Incident A: Affected 5 internal users, $0 revenue impact

• Incident B: Affected 50,000 customers during peak hours, estimated $200K revenue loss

MTTR suggested Incident A was "9x worse." Impact metrics revealed the truth. Again, stories matter!

Categorize incidents by business impact—Critical (revenue-affecting, customer-facing), High (internal productivity loss), Medium (degraded experience), Low (no user impact). Track the count and duration of each category separately.

Impact-focused metrics prioritize what matters most by measuring how many users are impacted and for how long, ensuring teams focus on reducing real-world pain rather than just closing tickets quickly. This approach aligns engineering work with actual business risk and value. They expose hidden risks by highlighting that two incidents with the same MTTR can have vastly different impacts, revealing which incidents truly impact the business and require deeper attention while uncovering chronic issues or fragile components that consistently cause high user impact.

Unlike MTTR, which incentivizes quick fixes, impact metrics encourage healthy behaviors by encouraging teams to address underlying causes and prevent recurrence, thereby improving long-term resilience.

Use Percentiles, Not Averages

Use percentiles (P95, P99) instead of averages to understand your real incident distribution. These metrics are less influenced by outliers and give you a clearer picture of what’s actually happening.

Let's return to our original 10 incidents example to see how percentiles tell a completely different story than MTTR: 9 incidents at 5 minutes, 1 incident at 360 minutes (6 hours)

• P50 (median): 5 minutes - This tells you that half of your incidents resolve in 5 minutes or less

• P90: 5 minutes - This tells you that 90% of your incidents resolve in 5 minutes or less

• P95: 5 minutes - This tells you that 95% of your incidents resolve in 5 minutes or less

• P99: 360 minutes - This tells you about your worst-case scenario, the 1% of incidents that take much longer

• MTTR (mean): 40.5 minutes - This tells you... what exactly?

What does that tell us?

The percentiles tell you that your incident response is actually excellent for the vast majority of cases. 95% of your incidents resolve in just 5 minutes! The P99 shows you have an occasional complex incident that takes 6 hours, which is important to know and address separately.

MTTR, however, suggests that a "typical" incident takes over 40 minutes, which is completely false. No incident in your dataset actually took 40 minutes. It's a mathematical artifact that doesn't represent anyone's actual experience.

Why this matters for decision-making:

• P50 and P90 help you understand your standard operational capability

• P95 and P99 help you identify outliers that need special attention

• Trends in percentiles show whether you're improving typical performance (P50/P90) or getting better at handling complex incidents (P95/P99)

P99 resolution time tells you what your most challenging incidents look like. P50 tells you about your typical response. Both are more useful than a skewed average that represents nobody's actual experience.

When you track percentiles over time, you might see improvements in both your standard incident response (lower P50/P90) and your complex incident handling (lower P95/P99), insights that MTTR completely obscures.

Noticed the "might"?

Here's the thing: even percentiles won't give you a simple, linear story of improvement. Modern systems are complex, distributed, and constantly evolving. Features are deployed continuously, infrastructure updates are regular, and teams are constantly changing.

Expecting any single metric to capture this complexity and show steady improvement is like wrapping yourself in a warm blanket during a snowstorm; it feels comforting, but it doesn't actually change the weather outside.

Here's the practical advantage of percentiles: they're a relatively good transitional metric if your organization is currently committed to MTTR. Because percentiles tell such a dramatically different and more accurate story than MTTR, leadership is unlikely to reject them. When you show that P50 is 5 minutes while MTTR claims 40+ minutes, the mathematical issues becomes obvious. But more importantly, percentiles don't threaten existing processes because they are fairly similar to MTTR. This makes them perfect for organizations that want to wrap themselves in a warm blanket but also tell a better story.

To further improve percentiles, consider categorizing your incidents into multiple classes, including deployment issues, bugs, regressions, testing issues, infrastructure failures, operational issues, security incidents, and third-party failures.

Each category has different root causes, recovery patterns, and prevention strategies. Averaging them together hides the specific improvements needed for each type.

What the Numbers Can't Tell You

Remember that platform engineering team from the beginning? The one with the stubborn 85-minute MTTR despite two years of improvements? When we dug deeper into their incidents, we discovered something very interesting.

Their "worst" incident, a 6-hour database corruption that dominated their MTTR, had actually taught them more about system resilience than dozens of quick fixes combined. The team had to coordinate across five different groups, improvise solutions when their runbooks failed, and ultimately redesign their backup strategy. Six months later, they prevented three similar issues from happening at all.

But their MTTR dashboard captured none of this. It just recorded "6 hours" and moved on.

This is what resilience engineering teaches us: the most valuable insights from incidents aren't about metrics, they're about adaptation and learning.

Here are some of the important and useful lessons that they actually learned:

1. Their mental model of how database replication worked was completely wrong. The incident revealed assumptions they'd held for years about their architecture that turned out to be false.

2. That team discovered that their monitoring was blind to a specific type of database issue they didn't even know existed.

3. When their standard recovery procedures failed, the team had to improvise. The database specialist was on vacation, the network team was handling a separate issue, and the junior engineer on-call had limited experience. Despite all that, they succeeded. This taught them something crucial: their runbooks were incomplete, their staffing assumptions were wrong, and their "junior" engineers were more capable than anyone realized.

4. The incident required five teams, seven approval processes, and coordination across three time zones.. It showed them exactly where their architecture was too tightly coupled and where their processes created unnecessary bottlenecks.

Each of these stories contains insights that make the organization more resilient. But MTTR reduces all of this richness to a single number that obscures the very learning that prevents future incidents.

What Resilient Organizations Actually Measure

Organizations that really care about resilience don't obsess over incident duration. They track how well they learn from each incident and how psychologically safe teams feel when reporting problems:

• Do we detect similar problems faster each time?

• Are teams getting better at improvising when standard procedures fail?

• What surprises us about our systems, and how do we turn those surprises into knowledge?

• Are we reducing coordination overhead through better architecture and clearer ownership?

• Which recovery strategies actually work under pressure?

• How quickly do insights from one incident improve our response to future ones?

Going back to that original team: when leadership asked "If you're really improving things, why isn't MTTR going down?" they were asking the wrong question.

The right question was: "Are you building systems that learn, adapt, and get stronger after each failure?"

The answer, hidden beneath that stubborn MTTR, was absolutely yes.

Their 90% reduction in alert fatigue meant they could focus on real problems. Their early detection systems meant small issues stayed small. Their systematic approach to complex incidents meant they were building institutional knowledge that would prevent future outages.

None of this showed up in MTTR. All of it showed up in their actual resilience.

The goal isn't to reduce incident response to an elusive average resolution time. The goal is to build systems and teams that learn from every incident, adapt when plans fail, and turn today's surprises into tomorrow's preventive measures.

That's the story great engineering teams should be telling. And it's the story that MTTR will never capture.

References

I'm not the first to question the usefulness of MTTR. People have been highlighting these problems for years:

John Allspaw argued in 2018 that shallow incident data like MTTR "generates very little insight" because incidents are "dynamic events with people making decisions under time pressure" that can't be captured in simple averages.

The VOID Report confirmed these concerns empirically, finding that "measures of central tendency like the mean aren't a good representation of positively-skewed data."

Štěpán Davidovič's "Incident Metrics in SRE: Critically Evaluating MTTR and Friends" used Monte Carlo simulations to show that reliable calculations of incident duration improvements aren't possible with MTTR.

Lorin Hochstein has demonstrated through statistical analysis that when incident durations follow power-law distributions, "observed MTTR trends convey no useful information at all." His work with power-law-distributed data shows how sample means become unreliable indicators of system performance.

What I hope to contribute here is a practical guide for the many engineering teams still using MTTR today, helping them understand not just why these metrics are misleading, but what they can implement instead to actually improve their resilience.

Allspaw, J. (2018). "Moving Past Shallow Incident Data." Adaptive Capacity Labs.

Nash, C. et al. (2021-24). "The VOID Report."

Davidovič, Š. (2021). "Incident Metrics in SRE: Critically Evaluating MTTR and Friends."

Hochstein, L. (2024). "MTTR: When sample means and power laws combine, trouble follows." Surfing Complexity.

I recently spoke with a Staff Engineer whose team was being "rightsized" (I'm keeping details vague to protect their privacy.) Five years earlier, after a catastrophic Black Friday outage, leadership had given them carte blanche to build world-class resilience. They hired the best engineers money could buy, put a comprehensive incident learning process in place, implemented operational readiness reviews, automated and gradual deployments with continuous testing, built a chaos engineering program, and created feedback loops that institutionalized resilience thinking across the engineering organization. Name it, they either were doing it or planned to have it.

No major outages in almost 2 years. Some smaller ones of course, but nothing catastrophic. Customer satisfaction was high. Resilience that made many envious. More importantly, the organization was healthy. No blaming culture. Eagerness to learn, and do what it could to limit the number of customer-facing failures.

It worked great. Everyone seemed happy. They even talked publicly and published about their practices in their own engineering blog.

Then came a quarterly business review.

"What exactly does your team do? I see a lot of salary costs, but what are the deliverables? Can you quantify the ROI?" asked the newly appointed VP of Engineering.

The team had spent the better part of the past 5 years preventing disasters and building operational and organizational resilience capabilities, not gathering proofs or preparing PowerPoints. They scrambled to explain their value, and didn’t have the data to back up their claims. If you are not prepared to answer the questions from the VP, "We prevented failures" and "we learned a lot" doesn't cut it. It simply doesn’t translate well to budget spreadsheets.

"Nothing's breaking right now. We need to refocus resources on features that drive revenue. We can revisit this stuff later if we need to," said the VP.

Six months later, they were down to only two engineers, and just a few months after that, the bigger and longer outages started again. Finger-pointing started again. People focused on themselves, saving their own jobs, and trying to show the VP how cost-efficient they were. The organization was already losing its operational resilience culture.

This is the prevention paradox, and it has played out countless times throughout history. The Y2K bug offers perhaps the most famous example. After years of preparation and billions in investments to address the Y2K bug, January 1, 2000, passed without major incidents. And rather than celebrating this success, many dismissed Y2K concerns as overblown hysteria precisely because the preventive measures worked as intended. The very absence of catastrophe made it difficult to justify the resources that had been spent on prevention.

Why is this happening?

The prevention paradox cycle happens because our brains struggle to value "non-events", things that didn't happen. We're wired to respond to and remember actual events and visible outcomes. When a disaster is prevented, there's no dramatic story to hold onto or share, so no one hears about it.

After a non-event, people conclude:

"See? Nothing happened, so clearly it wasn't a real problem."

Rather than recognizing:

"Nothing happened because we took appropriate precautions."

Paradoxically, the more successful the resilience efforts, the more that effort appears unnecessary in retrospect.

Organizations tend to focus on systems that are currently working while ignoring the preventive work that keeps them working. A database that hasn't failed in two years seems "naturally reliable" rather than "well-maintained."

When systems work well, we often attribute it to good initial design or "stable technology." When they fail, we blame the incident on bad luck or external factors.

The immediate cost of prevention work is visible and concrete. The future cost of potential failures is abstract and uncertain.

And leadership isn’t immune to it. They experience the same cognitive bias as everyone else: if nothing bad is happening, maybe nothing bad was going to happen anyway. They see the salary of the chaos engineering team; they don't see the 2M € outage that never happened.

The prevention paradox is the most common, predictable, yet devastating cycle I see in software organizations, and it impacts even the most “advanced” organizations out there. Literally NO ONE is immune of it.

The Resilience Amnesia Cycle

Here's how the prevention paradox typically sets in an organization:

1. The Crisis

A major outage hits. Revenue lost. Customers angry. Executives embarrassed. "This can never happen again!"

2. The Investment

Leadership opens the checkbook. "Hire the best SREs and engineers. Build comprehensive incident learning processes. Implement operational excellence. Make it resilient. Whatever it takes!"

3. The Success

The team delivers. They build robust technical systems, adopt chaos engineering, and develop advanced observability. They establish incident response processes to learn from every incident. They implement Operational Readiness Reviews (ORR) and Continuous Integration and Continuous Deployment (CI/CD) practices that catch issues before deployment. They create feedback loops between development and operations that institutionalize resilience thinking across the entire engineering organization.

Systems become resilient. Large outages become rare. Customer satisfaction improves. The organization develops the capability to anticipate problems and adapt quickly to changing conditions.

4. The Return-On-Investment (ROI) Questions

New Leadership. New budget cycle. Different priorities. "What does the team actually do? Can we quantify their impact? Are we over-invested here?"

5. The Cuts

"Nothing's broken, so clearly we don't need this level of investment. Let's move some people to features. We can always scale back up if needed."

6. The Return

Outages start happening again. The organization has lost its learning capabilities. Teams make the same mistakes repeatedly. "How did we get here? We need to invest in resilience!"

And the cycle repeats.

The team that prevented the crisis gets disbanded. The team that responds to the new crisis gets celebrated as heroes.

This is what I call the Resilience Amnesia Cycle. It is a predictable pattern where organizations systematically forget why they invested in prevention, precisely because that prevention worked.

The Resilience Amnesia Cycle

Why Teams Struggle to Justify Their Existence

The truth is that most (resilience) teams (including reliability, SREs, Ops, etc.) are totally unprepared for budget scrutiny because they were never asked to justify themselves initially. They were hired in crisis mode with a simple mandate: "Fix this."

They optimized for technical and organizational excellence, not business justification.

When the inevitable budget questions come, they face several challenges:

1. Success Is Invisible

"We prevented X number of potential outages" and "we improved organizational learning velocity" doesn't hit the same as "We shipped 12 new features." Prevention work creates an absence of problems and improved adaptive capacity, which are inherently hard to measure and communicate.

2. No Business Metrics Framework

Teams might track technical metrics, but rarely translate these to business impact. They can show improved velocity and some preparation through the different incidents and operational reviews, but they can't answer "What's the ROI?" because they never built the framework to calculate it or collected the data to even begin to consider it.

3. Different Languages

Engineers speak in availability percentages, bug fixes, number of deployments and rollbacks, and learning cycles from incidents. Finance speaks in revenue impact and cost per outcome. Neither group is fluent in the other's language.

4. Temporal Mismatch

Prevention work pays off over long time horizons. Budget cycles demand quarterly justification. The engineer who spent six months building chaos engineering experiments and learning from incident processes that will prevent next year's outage struggles to show this quarter's value.

5. Attribution Challenges

When systems are resilient, is it because of good initial architecture? Tested dependencies? Or the daily work of the teams building organizational resilience? It's genuinely hard to know, and teams rarely build systems to prove their contribution.

The Leadership Perspective

To be fair to leadership, their questions aren't completely unreasonable. They're managing competing priorities with limited resources. From their perspective:

• The resilience team was expensive to build and maintain

• Current systems appear stable without obvious ongoing issues

• Feature development has clear, measurable business impact

• Market pressure demands shipping new capabilities

• The "We can always rebuild the team if we need it" is an appealing justification

The problem isn't that leadership doesn't value resilience; in my experience, they always do. It's that, unfortunately, successful resilience work makes itself appear unnecessary.

The Real Cost of Resilience Decay

What leadership (and, to some extent, everyone in an organization) typically underestimates is the lag time and the compound nature of resilience degradation. The decay follows a predictable pattern that happens slowly until it’s already too late to realize what happened.

In the first few months after cuts, everything appears fine. Systems continue running on the momentum of previous investments while technical debt accumulates slowly in the background. Incident response processes start being skipped, reviews become optional, but there's no immediate pain to signal the danger. Small issues begin appearing around month six, individual incidents that seem unrelated, response times that gradually increase with no single smoking gun to point to. More critically, the organization stops learning from incidents effectively, losing the institutional knowledge that once made it resilient.

The degradation accelerates dramatically as problems compound. What used to be small contained failures start cascading across systems. Teams spend more time firefighting and less time building features, and fingers start pointing at people rather than examining systemic issues. The organization makes the same mistakes repeatedly because institutional learning has degraded, the very capability that once prevented these failures.

By 18-24 months, major outages return with a vengeance. Leadership now faces the same crisis that triggered their original resilience investment, but with 18 months of accumulated technical debt and lost organizational learning capability stacked on top.

Finally comes the frantic rebuilding phase, but now they're rebuilding resilience capabilities while simultaneously managing active fires, a much harder and exponentially more expensive proposition than simply maintaining prevention capabilities would have been.

Read our blog post—“The Quiet Erosion”—for more details about the slow process of how an organization drifts into failure.

Disclaimer: The degradation timeline is based on my experience working in the software industry, where I've observed this pattern repeatedly across different company sizes and industries. While I don’t have the data to quantify this timeline accurately, industry practitioners consistently report similar degradation patterns. The timeline varies based on factors like system complexity, organizational size, and the depth of original resilience investments. Still, the general pattern of slow-then-sudden degradation is a common experience across the software industry. Organizations with more mature practices may see slower degradation, while those with less institutional knowledge may experience faster decline.

The Cost of Resilience Cuts: How organizational resilience degrades over time after prevention investments are cut

Breaking The Cycle: Making Prevention Visible

The key to limiting the Resilience Amnesia Cycle is making invisible work visible and translating technical prevention into business value. This requires both concrete measurement frameworks and deep cultural change—tactical metrics without culture change won't stick, and culture change without metrics won't convince leadership.

Measurement Frameworks

1. Calculate Downtime Cost and ROI

In 2024, the Information Technology Intelligence Consulting (ITIC) estimated that 90 percent of enterprises face costs exceeding $300,000 per hour of downtime, with 41 percent exceeding $1‒5 million per hour.

Downtime costs for smaller businesses range from approximately $137 to $427 per minute, and for larger enterprises, they can reach $16,000 per minute.

The industry average cost of downtime is estimated at about $9,000 per minute.

Downtime costs can be approximated using the formula:

Downtime Cost = Minutes of Downtime x Cost per Minute

Start with that equation. It is simple and straightforward.

You can, of course, develop models that better estimate the ROI of resilience work.

Prevention ROI = (Potential Failure Cost × Probability × Prevention Success Rate) / Prevention Investment Cost

Even imperfect models are better than no models, and you can always improve them iteratively.

The key is to start putting a price on prevention.

2. Quantify Prevented Failures

Document the "alternate reality" and use simulations to show what could have happened without prevention.

Track and document near-misses with their potential business impact and share these with leadership:

• "ORR process caught database scaling issue that could have caused a 4-hour outage during Black Friday, saving $1.2M in potential revenue loss."

• "Incident review process from previous incident prevented similar failure pattern across three other teams, saving $500K in potential revenue loss."

• "Chaos experiment identified memory leak that would have led to failure during product launch, saving $300K in potential revenue loss."

3. Create Prevention Dashboards

Build visibility into prevention work with business-relevant metrics:

• Issues caught before customer impact

• System resilience improvements over time

• Technical debt prevented vs. remediated

• Learning from incidents and reviews

• Time to detect, time to respond, time to recover trends

• Track On-call confidence index

4. Build Compelling Narratives

Document how prevention work creates measurable business value:

• Share "near miss" stories and highlight specific instances where measures prevented failures

• Before/after resilience work comparisons

• Customer satisfaction correlations with resilience investments

• Developer productivity gains from improved systems

• Innovation velocity enabled by confidence in system resilience

• Learn from others' mistakes and point to organizations that failed to prepare

• Break prevention into measurable achievements

5. Establish Prevention SLAs

Just as you have uptime SLAs, consider creating accountability for prevention work:

• Complete ORR for 100% of new major feature deployments

• Conduct post-incident reviews for 100% of Sev-1 and Sev-2 incidents

• Allocate at least 20% of the time to addressing technical debt

• Execute a minimum of two chaos experiments quarterly for all our critical dependencies

• Maintain test coverage above 85% across all services

• Conduct a full-scale simulation (GameDay) once a month to validate our incident response capabilities

• Review, verify, and exercise at least one Runbook weekly.

• 100% of Runbooks’ last-verification-date should not exceed 6 months.

6. Build Institutional Memory

Document the reasoning behind protective measures and continuously educate stakeholders about:

• Why specific resilience investments were made

• What disasters they're designed to prevent

• How past incidents shaped current practices

• The compound value of organizational learning capabilities

• Regularly help stakeholders understand the value of resilience

Cultural Transformation

Even with perfect measurement frameworks, organizations will resist investing in prevention due to what are called "organizational antibodies"—the people and processes that extinguish new ideas as soon as they begin to course through the organization. Overcoming the Resilience Amnesia Cycle requires deep cultural change:

1. Leadership Modeling

Executives must visibly value and celebrate prevention work. When an ORR catches a critical issue or a chaos engineering process prevents repeat failures, that should be as celebrated as shipping a major feature.

2. Career Path Recognition

Create senior career paths for prevention specialists. Principal SREs and Distinguished Engineers in reliability and resilience should be as valued as their counterparts in product development.

3. Shared Context

Regularly share the cost and impact of outages across the organization. When teams understand that a 4-hour outage costs $800K, they better appreciate the team that prevents them.

4. Prevention Storytelling

Develop and share organizational narratives around prevention heroes, not just feature development or incident response heroes. The engineer who prevents a disaster through thoughtful ORR or systematic chaos engineering should get the same recognition as the one who fixes it.

Moving forward

As systems become more complex and customer expectations continue rising, the impacts of the prevention paradox become even more important to understand. Organizations that can't maintain prevention investments will find themselves in a continuous cycle of failure and reactive investment.

The most successful organizations I work with treat prevention work as a strategic capability, not a cost center. They understand that in a world where software is eating everything, resilience is a competitive advantage.

More importantly, they recognize that organizational learning and adaptation capabilities are what separate resilient organizations from fragile ones. The ability to anticipate problems, learn from incidents, and continuously improve is what enables sustainable success in uncertain environments.

If you recognize the prevention paradox in your organization, here's how to start addressing it today:

1. Audit your current prevention work - What's already happening that leadership doesn't see?

2. Calculate your prevention ROI - What failures have been avoided and what would they have cost?

3. Document near-misses - Start building a catalog of prevented failures and lessons learned.

4. Create visibility dashboards - Make prevention work as visible as feature delivery.

5. Build business-impact narratives - Connect technical prevention to business outcomes.

6. Measure learning velocity - Show how quickly the organization adapts and improves.

Don’t wait before it is too late. The prevention paradox isn't inevitable. Organizations that recognize and actively counter it build more reliable systems, retain better engineers, create stronger learning capabilities, and develop sustainable competitive advantages.

However, it requires conscious effort to value invisible work and resist the cognitive biases that make successful prevention appear unnecessary.

The best failure is the one that never happens. The challenge is proving it.

Photo by Raul Ling

The Slack notification arrived at 3:17 AM on a Tuesday: "Payment system down. All hands."

Six hours later, as the team sat exhausted around the incident room table, the CTO asked the question we hear after every major outage:

"How did we get here?"

The post-mortem timeline showed no single catastrophic decision. Instead, it revealed dozens of small compromises, each one reasonable at the time:

"We only reduced test coverage for non-critical features."

"We temporarily bypassed code review for this urgent fix."

"We'll address that performance issue next sprint."

Every decision made perfect sense in isolation. Yet somehow, these incremental changes had accumulated into a system operating at the edge of failure, where one memory leak during peak traffic brought down their entire payment infrastructure.

This is the story of organizational drift, one of the most dangerous and least understood risks facing software teams because drift happens slowly, quietly, through rational adaptations to competitive pressure and operational realities.

What makes drift particularly challenging is recognizing that it is happening before it's too late.

To illustrate how drift happens, I've created the story of TrendCart, a fictional e-commerce platform that experiences this exact pattern. While the company and characters are entirely fictional, the problems they experience are real. They are based on my own experiences and observations.

Disclaimer: TrendCart and all characters in this story are fictional. Any resemblance to real companies, people, or events is purely coincidental. This narrative is created solely to illustrate common organizational patterns and does not reference any actual organization.

The Story of TrendCart's Gradual Decline

Maya joined TrendCart as Lead Developer when the e-commerce platform was still celebrating its Series A funding. With 50,000 monthly active users and a reputation for reliability, TrendCart had carved out a niche for independent fashion designers.

"Our philosophy is simple," explained Raj, the CTO, during the onboarding process. "We deploy twice monthly, after full testing. Every commit gets two code reviews, unit and integration tests, and a security review. We take our customers' trust seriously." Maya was impressed by the clear and disciplined development process. Thorough yet not bureaucratic, with clear guidelines that developers consistently followed.

The Pressure Mounts

The first cracks appeared during a routine customer advisory call. Designer after designer asked about features that TrendCart didn't have, features that their competitor, CompeteCart, had already launched.

"When will you have social login?"

"Why can't I bulk upload products?"

"CompeteCart's analytics show me exactly which products are trending in real-time."

Maya watched the sales team's faces during these calls. Each missing feature represented lost revenue. By week's end, they were maintaining a "feature gap spreadsheet" that grew longer daily.

The emergency board meeting happened on a Friday. Maya wasn't invited, but the tension was palpable when leadership came out of the room.

"Eighteen months," the CEO announced to the engineering team. "We have eighteen months of runway. If we don't close the feature gap and accelerate growth, there won't be a TrendCart to run."

It was about survival.

The Reasonable Compromise

Raj called an all-hands engineering meeting. "We need to move faster without breaking what works," he began. "I'm proposing we shift to weekly deployments by streamlining our processes."

The plan seemed logical: Keep thorough testing for payment processing and user data. Reduce the scope of testing for "non-critical" features. Maintain code review, but expedite for urgent fixes. And automate security checks where possible.

Maya raised her hand. "What is 'non-critical'?"

"Features that don't directly impact transactions or user data," Raj replied. "UI elements, analytics dashboards, recommendation engines, all important, but not customer-facing if they break."

Weekly deployments meant faster iteration, quicker feature delivery, and better competitive positioning. The compromise felt reasonable. Maintain safety for core functions while accelerating everything else.

The leadership team and developers were happy with the faster pace, and for a while, everything seemed to be going fine.

For three months, it worked great.

Early Warning Signs Most Teams Miss

Six months later, Maya noticed troubling patterns. Deployment rollbacks had increased from once every few months to twice in the last month. The on-call rotation was getting paged more frequently for "minor" issues that developers would fix with quick patches rather than proper investigations.

Test coverage showed 71%, but Maya knew the number lied. Developers had learned to game the metrics: tests that verified mocks instead of actual functionality, integration tests marked as "flaky" and skipped in continuous integration (CI), and business logic validated only through happy-path scenarios.

"Look at this payment processing change," Maya showed her teammate Alex during a code review. "The tests pass, but they're mocking the actual payment gateway. We're testing that our mocks work, not that payments work."

During the monthly retrospective, Maya presented her concerns. "Yesterday's deploy broke user avatars for three hours. We only discovered it because a customer tweeted a screenshot. We're accumulating technical debt and we're getting comfortable with it.

"These issues aren't critical individually," she continued, "but they're creating systematic brittleness."

The product manager's response was fast: "Every platform has technical debt. Our KPIs look excellent. Look, cart abandonment is down 15%, and transaction volume is up 23% this quarter. Let's not slow momentum over edge cases."

The team moved on.

The First Incident

Black Friday weekend. Traffic peaked at 3x normal levels. At 2:47 PM, the entire platform went down.

Thirty-seven minutes of complete outage during the busiest shopping period of the year.

$127,000 in lost revenue, nearly 3% of their yearly revenue, plus 3,000 abandoned carts and 12 customer complaints. The numbers didn’t look good.

But Maya knew the real cost was likely higher.

The investigation revealed a memory leak that had been flagged during sprint planning three months earlier. Categorized as "performance optimization," it lived in the ever-growing backlog of "technical debt to address later." Under normal load, it was invisible. During peak traffic, it consumed all the available memory, causing the application servers to crash.

The post-mortem focused on immediate fixes, including memory monitoring alerts, load balancing improvements, and automated restart procedures.

"We'll review the performance backlog next quarter," Raj concluded.

Within two weeks, the performance issues were again labeled "not customer-impacting" and deprioritized for feature work.

Maya started noticing a pattern in the incident reports. Each one ended with "this specific issue has been resolved," rather than addressing the category of problems that made this possible.

The Normalization of Deviance Pattern

A month later, a more serious incident happened. A privacy incident. Customer addresses were visible, and the bug had actually merged customer profiles, so orders from one customer appeared in another's account history. It took six hours to fully identify the scope because logging wasn't detailed enough to trace which accounts had been affected.

The investigation revealed a cascade of small failures: A developer had pushed directly to main to "quickly fix" a merge conflict. The automated tests passed because they didn't test cross-user data isolation. The staging environment didn't have enough data volume to reproduce the issue. The code review was marked as "approved," but clearly it hadn’t been thorough, since none of the comments had been addressed. Instead, it was merged with the message “Added a few comments, but approving to make the feature release date. Cutting a ticket to the backlog”

Maya expected this to be a wake-up call. Instead, in the next incident, she heard familiar patterns: "The root cause was the direct push to main, again. We'll fix that by preventing that altogether." The conversation never addressed why the developer felt pressure to bypass the process.

How Small Compromises Compound

Maya, feeling things were getting out of control, started mapping their journey. Using incident reports, deployment metrics, and her own observations, she created a timeline showing TrendCart's drift from disciplined engineering to normalized risk-taking.

She highlighted each small decision that, while logical in isolation, had collectively eroded their safeguards.

When the fourth incident occurred, a billing bug that undercharged customers for three weeks, Maya presented her diagram to the executive team.

"We didn't make a single decision to be unsafe," she explained. "We made hundreds of small trade-offs, each seeming reasonable at the time. But look where we've ended up."

She traced their path across the boundaries. "Here's where we first reduced the testing scope. Here's where we started accepting pull requests with failing tests if they weren't in 'critical paths.' Here's where we stopped requiring security reviews for changes to the user data models."

Recognizing Drift Before It's Too Late

Maya's presentation to executives didn't immediately change everything. The team asked good questions, but the first response was predictable: "We need better tooling to prevent these specific issues."

Then Maya showed them data from their own customer support tickets. The volume of "weird bugs" had tripled over the past six months. Customers were reporting issues that individually seemed minor but collectively painted a picture of a platform becoming unreliable.

"Our Net Promoter Score has dropped eight points," the customer success manager added. "Customers are saying we 'used to be reliable' but now they're not sure they can trust us with their business."

"When did we leave the safe zone?" the CEO asked.

"About seven months ago," Maya replied. "When we started treating the tests as a suggestion rather than a requirement."

"And the red zone?"

"We've been operating in the danger zone since we decided that certain types of bugs were 'acceptable business risks' rather than issues to be fixed. That normalizing of problems is what concerns me most."

The Recognition

The executive team finally understood they weren't looking at isolated incidents requiring specific fixes. They were seeing symptoms of systematic drift from engineering discipline toward normalized risk-taking.

What had felt like necessary adaptations to competitive pressure had gradually transformed into dangerous corner-cutting. Speed and agility had become excuses for compromising foundational practices.

But Maya proposed a solution that surprised them.

"We don't need to slow down or revert to monthly deployments," she explained. "We need to make drift visible and intentional rather than invisible and accidental."

The changes that followed weren't dramatic. They didn't slow down development or return to monthly deployments. Instead, they implemented what Maya called "intentional friction,” small barriers designed to make unsafe shortcuts visible and require conscious decisions, rather than letting things drift.

They established "guardrail reviews", quarterly assessments specifically designed to call-out drift in their development practices. They created clear, non-negotiable boundaries for security, testing, and code quality.

Timeline showing TrendCart's organizational drift from safe practices through warning signs to major incidents and recovery

The Adaptation Awareness Framework

Most importantly, they created a framework that distinguished between two types of changes:

• Reactive adaptation: Responding to immediate pressures (what led to drift)

• Proactive adaptation: Anticipating systemic risks (what Maya demonstrated)

The framework didn't restrict adaptation. Instead, it encouraged more Maya-style adaptation while making pressure-driven adaptations visible for organizational learning.

Maya had demonstrated exactly the adaptive capacity every organization needs: the ability to sense emerging risks, connect patterns across incidents, and proactively adjust the system's safety boundaries.

The goal was to cultivate more people who could adapt like Maya, not prevent adaptation.

The framework included:

Pattern Recognition: Regular analysis of when, why, and how teams adapted standard processes
Systemic Learning: Understanding what adaptations reveal about underlying system pressures
Adaptive Capacity Building: Strengthening the organization's ability to handle unexpected situations safely
Continuous Sense-Making: Using adaptations as data to improve the system rather than just controlling behavior

The Recovery

The transformation wasn't immediate, but it was measurable. Within a few months, they had restored test coverage to a healthy 83% through systematic debt reduction. They also reduced deployment rollbacks by 60% through improved quality gates and practically eliminated “hot fixes” pushes to production. They also started to see improvements in customer tickets and on-call operations.

"The key insight," Maya explained during an all-hands meeting, "wasn't choosing between speed and safety. It really was choosing between intentional trade-offs and invisible drift."

Epilogue

A few months later, TrendCart's main competitor suffered a major data breach that affected all of its customer records. The incident, caused by accumulated security compromises, forced the company to rebuild its platform. The incident resulted in severe fines and extensive negative publicity.

Designers who had initially left TrendCart for CompeteCart's faster feature delivery began returning. They cited reliability and trust as primary factors.

It was a very expensive incident, to the point that CompeteCart ultimately ended its service.

"The irony," Maya reflected during a conference presentation about their journey, "is that we thought we were making necessary trade-offs to remain competitive. But by recognizing and managing our drift, we ended up with both speed and safety, which turned out to be the real competitive advantage all along."

Maya had adapted, too. When she first noticed the test quality issues, she could have focused solely on her own code and remained quiet. Instead, she adapted from individual contributor to system advocate.

That's what resilient organizations need: people who adapt their perspective from local optimization to system health. By encouraging this kind of positive adaptation, organizations actually become more adaptable as a whole.

A few months later, Maya was promoted to principal engineer.

The Cost of Invisible Drift

Why am I telling this story? Organizational failure rarely announces itself with dramatic warning signs. Instead, it accumulates through thousands of small compromises, each reasonable in isolation, collectively lethal in combination.

The timeline illustrated above shows what most post-mortems forget to mention. The "root cause" is rarely directly related to the final incident itself, but rather the slow erosion of safety boundaries that made that incident inevitable. The memory leak, the privacy breach, and the billing bug weren't separate problems requiring separate solutions. They were symptoms of a system that had gradually drifted from good engineering practices toward normalized risk-taking.

The most insidious aspect of drift is how it makes teams complicit in their own degradation. When test coverage drops over time, no single day feels dangerous. When minor incidents become routine, each one seems manageable. When shortcuts become standard practice, organizations believe they're adapting to business realities rather than compromising their foundation.

Why Traditional Approaches Fail

Most organizations fail to detect drift because they focus on symptoms rather than causes. They detect problems after drift has already occurred, rather than preventing drift from accumulating in the first place.

Drift happens in the space between formal processes and daily reality.

It's the accumulation of small adaptations that individually seem reasonable but collectively undermine system safety.

Intentional Trade-offs

Every organization needs people who can adapt the way Maya did: sensing patterns, surfacing concerns, and strengthening the system's capacity to handle surprises.

Speed and safety aren't mutually exclusive, but they require constant vigilance to maintain together. The goal isn't to eliminate all risk or prevent all adaptations. Instead, it's making risk visible and consciously managed while building the organization's capacity to adapt safely.

To successfully balance speed and safety, you need to:

• Track leading indicators of drift, not just incident outcomes

• Treat process adaptations as valuable learning data, not violations to prevent

• Celebrate teams that surface systemic issues early, not just those that respond to incidents quickly

• Build adaptive capacity—the ability to handle unexpected situations safely

The Tale of Two Adaptations

This story reveals something important that I almost overlooked when writing this blog post. TrendCart has experienced two completely different types of adaptation.

Drift-Inducing Adaptations (what the team did):

• Individual responses to immediate pressure

• Invisible to the broader organization

• Focused on local optimization

• Accumulated without systemic awareness

Resilience-Building Adaptations (what Maya demonstrated):

• Proactive pattern recognition across the system

• Made concerns visible to leadership

• Focused on long-term system health

• Enhanced organizational learning capacity

Next Steps

The next time someone asks, "How did we get here?" after a major incident, remember that the answer probably isn't in the immediate timeline. It's in the months or years of small compromises that made that moment inevitable.

Ask yourself:

• What processes has your team adapted or "streamlined" in the past year?

• How many of your quality metrics could be gamed without affecting actual quality?

• When did you last review the cumulative impact of individual process adaptations?

• What would your customers say about your reliability compared to six months ago?

Then take action:

1. This week: Implement basic drift tracking for your most critical processes

2. This month: Conduct a retrospective focused on accumulated technical debt and process adaptations

3. This quarter: Establish guardrail reviews and leading indicator monitoring

4. This year: Build systematic adaptation awareness into your organizational culture

Note: See Annexes for a more comprehensive set of actions

Transformation is available to every team willing to choose conscious trade-offs over invisible drift.

The question isn't whether your organization is making compromises; every organization does. The question is whether you're making them intentionally, with full awareness of their cumulative effect, or allowing them to accumulate invisibly until the next major incident.

Choose intentional drift detection. Choose systematic quality practices. Choose competitive advantage through reliability.

Your customers, your team, and your future self will thank you.

Implementation Toolkit

Note: This toolkit represents my current practices, informed by research and field experience; however, organizational resilience is deeply contextual. I welcome suggestions, corrections, and additional strategies based on your own experiences. Please reach out with improvements or examples of what has worked (or hasn't worked) in your organization.

The Anatomy of Organizational Drift

There are typically four drift phases that an organization experiences:

Phase 1: The “Reasonable” Compromise

• External pressure creates the need for adaptation

• Leadership proposes logical process changes

• Team maintains core safety practices while "optimizing" peripheral ones

• Early metrics show positive results

• Gap emerges between work-as-imagined (official processes) and work-as-done (actual practice)

Warning Signs:

• Increased deployment frequency without proportional quality investment

• Redefinition of "critical" vs "non-critical" systems

• Process adaptations that become regular patterns

Phase 2: Metric Gaming

• Teams adapt to new incentives by optimizing numbers rather than outcomes

• Quality indicators lose correlation with actual quality

• Small issues accumulate but remain below the visibility threshold

• Teams engage in "satisficing" behavior, doing just enough to meet targets rather than achieve actual quality

Warning Signs:

• Test coverage maintains while actual test quality deteriorates

• Increased incidents that get “quick-fixed” rather than properly investigated

• Growing backlog of "technical debt to address later"

Phase 3: Normalization

• Incidents become less exceptional

• Each problem gets treated in isolation rather than as part of a pattern

• Team culture shifts from "how do we prevent this?" to "how do we fix that fast?"

• Organization loses "chronic unease", the healthy skepticism about system safety that prevents complacency

Warning Signs:

• Post-mortems focus on specific fixes rather than systemic improvements

• Increasing acceptance of "edge cases" and "known issues"

• Customer complaints about reliability start appearing

Phase 4: Crisis or Recovery

• Accumulated risk manifests as a major incident or competitive threat

• Organization either recognizes the pattern and implements systematic changes

• Or continues drift until catastrophic failure forces dramatic restructuring

• Important note: Even successful recovery requires ongoing vigilance, as drift is a continuous process that can restart at any time

This framework draws from Sidney Dekker's concepts of "drift into failure" and "work-as-imagined vs work-as-done," Diane Vaughan's "normalization of deviance," and supporting research in organizational safety by James Reason, Charles Perrow, and Karl Weick.

Building Drift-Aware Organizations

Here are strategies for making drift visible before it becomes dangerous:

Leading Indicators to Monitor

Quality Metrics

• Test coverage trends, not just absolute numbers

• Test execution time and flakiness rates

• Code review rejection rates and bypass frequency

• Deployment rollback frequency and time-to-restore

• Work-as-done vs work-as-imagined gaps (actual vs documented processes)

Process Health

• Pattern analysis of process adaptations and their justifications

• Time between incident detection and customer notification

• Percentage of incidents that are repeat issues

• Cross-team dependency failure rates

• Weak signal detection rate (near-misses identified and reported)

Cultural Indicators

• Employee survey responses about process confidence

• Voluntary overtime trends during deployment periods

• Knowledge transfer effectiveness between team members

• Incident response stress levels and team satisfaction

• "Chronic unease" levels (healthy skepticism about system safety)

• Psychological safety scores for reporting problems and concerns

Systematic Drift Detection

Guardrail Reviews

1. Map all process adaptations from the previous quarter

2. Understand why teams felt adaptations were necessary

3. Assess the cumulative impact of individual compromises

4. Identify patterns that indicate systematic drift

5. Review and update boundaries based on emerging risks and system changes

Adaptation Awareness Implementation

1. Regular pattern analysis of when, why, and how teams adapt processes

2. Focus on understanding systemic pressures that drive adaptations

3. Use adaptations as learning opportunities rather than compliance violations

4. Build organizational capacity to adapt safely rather than just limiting adaptations

5. Create psychological safety for discussing process pressures without blame

Pattern Recognition Training

1. Train incident responders to identify systemic issues

2. Implement post-mortem that surface contributing factors

3. Maintain cross-incident trend analysis

4. Regular review of themes across multiple incidents

5. Focus on "how the system normally succeeds," not just how it fails (Safety-II approach)

Recovery Strategies

For organizations already experiencing drift:

Stabilization

1. Implement automated quality gates that cannot be bypassed

2. Establish emergency change review process

3. Create visible dashboard of leading indicators

4. Begin systematic documentation of current state

5. Restore "chronic unease" through leadership modeling of safety-conscious behavior

Assessment

1. Conduct an audit of current practices vs. stated policies

2. Map all informal processes and shortcuts currently in use

3. Identify the highest-risk areas where drift has progressed furthest

4. Create a prioritized remediation plan

5. Interview frontline workers to understand work-as-done vs work-as-imagined gaps

Recovery

1. Implement changes gradually to avoid disrupting operations

2. Provide training and support for teams returning to disciplined practices

3. Establish positive incentives for quality behaviors

4. Measure and communicate progress regularly

5. Build adaptive capacity—ability to respond to unexpected situations

Reinforcement

1. Celebrate examples of teams surfacing systemic issues early

2. Share stories of how quality practices prevented incidents

3. Make adaptation awareness a regular part of team retrospectives

4. Maintain executive visibility into adaptation metrics

5. Institutionalize "productive failure"—learning from near-misses and small failures

6. Create psychological safety for reporting concerns without blame

Maintaining Vigilance

• Continuous monitoring: Drift detection is ongoing, not a one-time fix

• Boundary management: Regularly review and update safety boundaries as systems evolve

• Learning orientation: Treat drift detection as organizational learning, not compliance checking

• Leadership commitment: Executive teams must model and reinforce drift-resistant behaviors

• Adaptive capacity building: Strengthen the organization's ability to handle unexpected situations safely

Further Reading

Sidney Dekker - "Drift into Failure: From Hunting Broken Components to Understanding Complex Systems" (2011)

Dekker's work provides the conceptual framework and vocabulary for understanding how complex systems gradually move toward failure boundaries through small adaptations.

Diane Vaughan - "The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA" (1996)

Vaughan's research introduced the concept of "normalization of deviance" - how organizations systematically lower their standards for what constitutes acceptable risk.

Charles Perrow - "Normal Accidents: Living with High-Risk Technologies" (Updated Edition, 1999)

Perrow argues that multiple and unexpected failures are built into society's complex and tightly coupled systems, and that accidents are unavoidable and cannot be designed around. His concept of "normal accidents" explains why some failures are inevitable in complex systems, regardless of safety measures.

Erik Hollnagel, David Woods & Nancy Leveson (Eds.) - "Resilience Engineering: Concepts and Precepts" (2006)

This book charts the efforts being made by researchers, practitioners and safety managers to enhance resilience by looking for ways to understand the changing vulnerabilities and pathways to failure.

James Reason - "Human Error" (1990) and "Managing the Risks of Organizational Accidents" (1997)

Reason introduces the Swiss cheese model, a conceptual framework for the description of accidents based on the notion that accidents will happen only if multiple barriers fail.

James Reason - "The Human Contribution: Unsafe Acts, Accidents and Heroic Recoveries" (2008)

Reason's later work that explores both the positive and negative aspects of human performance in complex systems.

Karl Weick - "Sensemaking in Organizations" (1995)

Karl E. Weick's book highlights how the "sensemaking" process — the creation of reality as an ongoing accomplishment that takes form when people make retrospective sense of the situations in which they find themselves — shapes organizational structure and behavior.

Karl Weick & Kathleen Sutcliffe - "Managing the Unexpected: Sustained Performance in a Complex World" (3rd Edition, 2015)

Essential reading on high-reliability organizations and how some organizations maintain safety despite operating in hazardous environments.

Nancy Leveson - "Engineering a Safer World: Systems Thinking Applied to Safety" (2011)**

STAMP provides a paradigm for system safety engineering and has been increasing in usage across the transportation industry.

Sidney Dekker - "Safety Differently: Human Factors for a New Era" (2014)

Dekker's evolution from traditional safety thinking toward a more nuanced understanding of how safety is created in practice.

Erik Hollnagel - "Safety-I and Safety-II: The Past and Future of Safety Management" (2014)

The traditional safety concept, known as Safety-I, and its associated methods and models have significantly contributed to enhancing the safety of industrial systems. However, they have proven insufficient for application to complex socio-technical systems. From reactive to proactive safety thinking.

In a recent interview with Iluminr, I was asked the following question:

"Which framework do you think needs to be retired or radically rethought?"

My answer was clear: the traditional "root cause analysis" and "5 whys" frameworks.

This is the director’s cut version of that answer.

However, I should first confess: I once believed deeply in the 5 Whys method. It's featured in numerous books and endorsed by industry leaders. As a young engineer, questioning these established practices wasn't my first instinct. I not only used it for years but also passionately shared it with colleagues and taught it to others.

Who could blame me? The framework is intuitive, easy to explain, and simple to implement. It makes perfect sense …. on the surface. Keep asking "why" until you find the ultimate cause. Doing that will prevent the incident from recurring.

The Turning Point

As I grew in seniority and gained more experience with complex systems, I became increasingly uncomfortable with the limitations I was seeing. The implicit accusatory tone of "why" questions started to bother me. Team members would become defensive rather than reflective during post-mortems.

Something seemed wrong.

More importantly, I noticed that our "solutions" weren't preventing similar incidents from occurring. We'd fix the specific issue we identified, only to have a different manifestation of the same systemic problem appear again, and again.

Once I understood that the goal of incident investigation was learning, everything changed.

And once you see the benefits of a more nuanced approach, there's no going back.

The Fundamental Problem

These traditional approaches are based on outdated, linear thinking that assumes failures have single, identifiable causes that can be eliminated. But the truth is that's not how complex systems work.

Complex systems never have one single root cause. Instead, they have multiple contributing factors that combine to create failures. And it is the accumulation of these contributing factors that eventually break down over time.

And these failures are non-deterministic, meaning that repeating the same conditions would likely lead to different outcomes. That's because systems operate in completely dynamic environments where conditions and context continuously change.

Why These Frameworks Persist

Yet despite these obvious limitations, these frameworks persist in organizations worldwide. They're comforting in their simplicity. They give us the illusion of control. You can find the root cause, fix it, and the problem is solved.

Organizations also like them because they often lead to solutions that appear straightforward and actionable. "Retrain the engineer" or "Add another approval step to the process" are easier actions to document than "Our system has fundamental design flaws that interact in unpredictable ways."

Real-World Examples: When 5 Whys Lead to Wrong Conclusions

In the interview, I shared an example where a company had experienced a 2-hour database outage. Their initial 5 Whys analysis went something like this:

1. Why did the database go down? Because it ran out of storage space.

2. Why did it run out of storage space? Because the log files grew too large.

3. Why did the log files grow too large? Because log rotation wasn't functioning properly.

4. Why wasn't log rotation functioning properly? Because the engineer who set it up used incorrect settings.

5. Why did the engineer use incorrect settings? Because they weren't properly trained in database configuration.

Conclusion: “We need better training for engineers on database configuration.”

And that seems OK. It makes sense, right?

But if you really think about it, this analysis almost purposely created a linear story ending with "insufficient training." It implicitly blamed the engineer and missed systemic issues.

Complex Systems Demand Different Thinking

Instead of accepting that conclusion, we added some different questions alongside their existing framework.

The instruction was to be curious about the context and to explore different dimensions: culture, processes, and tools.

After a few iterations, we eventually ended up with something like that:

1. How did you first become aware of the issue? I noticed alerts showing unusual disk usage patterns an hour before the crash, but they weren't critical alerts, so I was finishing another urgent task first.

2. How did the system appear to be functioning at that time? It seemed normal except for the disk usage. We've had similar warnings before that resolved themselves, so I wasn't immediately concerned.

3. What were you focusing on when making decisions about priorities? I was trying to balance multiple alerts. Since we typically prioritize customer-facing issues, I was working on a payment processing issue first.

4. How was the log rotation system originally set up? It was configured during our migration six months ago. We copied settings from our test environment, which had different usage patterns. The rotation was set for weekly rather than daily because test data volumes were much smaller.

5. How do changes to these systems typically get reviewed? We usually have a checklist for infrastructure changes, but during the migration period, we moved quickly to meet deadlines, and some review steps were abbreviated.

This new approach led the team to different conclusions. Same incident, different ending. They ended up Implementing several improvements instead of just pushing for “more training”:

• Revising alert classification to distinguish critical issues better

• Establishing dedicated maintenance periods

• Enhancing the infrastructure change review process

• Creating more accurate test environments

• Addressing workload prioritization issues

The key difference wasn't just in asking better questions. The approach fundamentally recognized that incidents emerge from complex interactions between people, technology, and organizational factors, rather than from a single cause or person's mistake.

Here is another one where a critical service went down during a deployment:

1. Why did the service fail? Because an invalid configuration was deployed.

2. Why was an invalid configuration deployed? Because it wasn't properly tested.

3. Why wasn't it tested? Because the engineer was rushing to meet a deadline.

4. Why was there a rush? Because the project was running behind schedule.

5. Why was it behind schedule? Because the estimate was too optimistic.

Conclusion: “We need to improve the estimation process."

Instead, the new approach revealed:

• The deployment tools made it too easy to accidentally include unrelated changes

• The monitoring system didn't catch the issue because it was designed to detect hard failures, not degraded performance

• An engineer had been doing manual system checks that caught several issues early, but this wasn't a formal practice

• The system degraded gradually rather than failing immediately, making cause-and-effect relationships harder to establish

This, too, led to multiple improvements, including better deployment tooling, enhanced monitoring, formalized morning system checks, and a deeper understanding of how our services degrade under specific conditions.

The Trojan Horse Approach: Implementing Change Without Resistance

After years of trying to improve how teams analyze incidents, I've learned that announcing "your approach is wrong!" rarely works. Instead, I've developed what I call the "Trojan Horse" approach to changing incident analysis practices.

Rather than launching a frontal assault on established methodologies, I've found it more effective to introduce new thinking from within existing frameworks. Just like that old wooden horse, this approach appears harmless but carries within it ideas that can transform how organizations understand incidents.

Here's how I typically introduce it:

1. Start with the familiar format of a post-incident review that leadership expects

2. Gradually introduce open-ended "what" and "how" questions alongside the traditional "why" questions.

3. Be curious about the context and explore its various dimensions, including culture, processes, and tools.

4. Highlight the richer insights and context these alternative questions produce

5. Expand the scope beyond finding a single root cause to mapping the system interactions and dynamics

Over time, organizations eventually shift from simplistic root cause thinking to a more nuanced understanding of complex systems, without the resistance that often comes with rejecting established methods outright.

Practical Questions That Transform Incident Analysis

What I've found most effective is introducing subtle but powerful questions into existing processes:

• "What surprised you during this incident?"

• "Where did your understanding of the system prove incorrect?"

• "How did this make sense to everyone involved at the time?"

• "What pressures and constraints shaped the environment in which decisions were made?"

• "Who knew things that others didn't?"‘

• “What were we afraid to talk about before this problem happened?”

These questions don't disrupt the familiar framework but gently expand thinking beyond simplistic cause-and-effect reasoning.

Language Evolution: Shifting From "Root Cause" to "Contributing Factors"

Similarly, I've found you can transform how teams conceptualize incidents by gradually shifting terminology:

• From "root cause" to "contributing factors"

• From "human error" to "systemic conditions"

• From "failure" to "unexpected behavior" or “surprise”

• From "preventing" to "learning"

• From "cause" to "influence"

Most people won't even notice these subtle shifts happening in conversations and documentation, but over time, they profoundly change how incidents are understood.

Building Sustainable Improvement in Your Organization

That Trojan Horse approach works because it acknowledges the real-world constraints we all face:

• Teams have limited time for incident reviews

• People have varying levels of expertise in systems thinking

• Leaders want clear, actionable outcomes

• Everyone feels pressure to "just fix it and move on"

It works precisely because it respects these constraints rather than fighting against them. It enables continuous improvement without demanding radical change all at once.

Be Patient, Be Persistent

The most successful change often happens not through revolution, but through evolution, making each incident review just a little bit better than the last one.

Remember: people don't resist change, they resist being changed.

By meeting teams where they are and gradually expanding their perspective, we create sustainable improvement rather than resistance.

Resilience needs to be nurtured, not imposed.

"The path to resilience isn't paved with more complexity, but with elegant simplicity."

Why Most Resilience Programs Fail

Let's be honest: most resilience efforts end up as elaborate checkbox exercises that consume resources and deliver little actual resilience. You've probably seen it yourself when comprehensive frameworks, meticulously planned runbooks, and detailed incident management protocols that collapse at first contact with a real crisis.

Why? Because traditional resilience frameworks fundamentally misunderstand the nature of failure in complex systems.

The Resilium Labs Difference

At Resilium Labs, we're challenging conventional wisdom about what makes systems resilient. Our approach isn't just different for the sake of being different. It's different because decades of research in resilience engineering and complex systems theory demand a paradigm shift.

Here's how we're redefining resilience:

1. Shifting from "Root Cause" to Context and Complexity

Traditional approach: Failures are treated as linear and deterministic. Find the root cause, fix it, create a new rule, and the problem is solved.

Our approach: We recognize that failures emerge from interactions within complex systems. Instead of hunting for scapegoats or simplistic causes, we look at the full context in which failures occur and the conditions that allowed them to manifest.

Our approach shifts the perspective from finding fault to understanding context. Instead of simply identifying what went wrong, we focus on understanding why certain decisions made sense to engineers at the time they were made.

2. Championing Uncertainty and Vulnerability

Traditional approach: Command and control rules. Detailed runbooks and rigid processes intended to eliminate uncertainty.

Our approach: We embrace the reality that uncertainty is inherent in complex systems. Rather than pretending it can be eliminated, we build systems and teams that thrive in uncertain conditions. We create psychological safety that enables teams to acknowledge vulnerabilities instead of hiding them.

Resilient systems don't pretend to be invulnerable. Instead, they acknowledge their vulnerabilities and prepare accordingly.

3. Dismantling Complexity in Favor of Elegant Simplicity

Traditional approach: Adds complexity on top of complexity, with elaborate frameworks and intricate response protocols.

Our approach: We obsessively simplify. Complex systems already have enough moving parts so your resilience approach shouldn't add more. As Sir Tony Hoare famously said, "The price of reliability is the pursuit of the utmost simplicity."

Our resilience strategies are elegantly minimalist, focusing on maximum impact with minimal complexity.

4. Prioritizing Recovery Over Prevention

Traditional approach: Avoids failure at all costs. Investing heavily in prevention measures.

Our approach: We recognize that failures will happen despite our best efforts. While reasonable prevention is important, we prioritize rapid recovery capabilities. The difference between a minor incident and a catastrophe often isn't whether something fails, but how quickly you can recover.

When you optimize for recovery speed rather than zero failures, your systems become naturally more resilient.

5. Resilience as Ongoing Practice, Not a Static State

Traditional approach: Treats resilience like a maturity model with checkpoints and an end state.

Our approach: We see resilience as a continuous practice, something you do, not something you have. Organizations don't "achieve resilience". Instead, they practice it daily through learning, adaptation, and evolution.

This perspective shifts resilience from a project to be completed to a capability to be cultivated.

6. Calling Out the "Prevention Paradox"

Traditional approach: Many resilience practitioners actively choose to remain invisible or separate from the business.

Our approach: We confront the prevention paradox—the idea that when resilience efforts succeed, nothing happens, making it difficult to demonstrate value. Rather than hiding from this challenge, we make resilience visible by connecting it directly to business outcomes and strategic objectives. We make the invisible visible.

Resilience isn't separate from your business. Instead, it's what enables your business to thrive in an increasingly unpredictable world.

A Different Kind of Resilience Partner

If you're tired of resilience initiatives that consume resources without delivering real results, let's talk. At Resilium Labs, we're not interested in checking boxes or implementing rigid frameworks. Instead, we're committed to building genuine resilience that enables your organization to adapt and thrive in the face of uncertainty.

Our approach is grounded in decades of research in complex systems, human factors, and resilience engineering. We've distilled these insights into practical approaches that deliver measurable results without unnecessary complexity.

Remember: Resilience isn't about preventing failure. It's about designing systems that can adapt and recover when the inevitable occurs.

Ready to build real resilience? Let's talk.

Blog RSS

Let’s be honest; disruption is the norm, not the exception. Headlines regularly feature outages affecting banks, e-commerce platforms, entertainment providers, and airlines. Failure has become an everyday reality. From technical outages to market shifts, organizations face an increasingly complex landscape of potential failures.

But what if I told you that these disruptions could actually become your competitive advantage?

Reframing Resilience: From Cost Center to Strategic Asset

Most executive conversations about resilience start in the wrong place. They begin with questions like "How much will this cost?" or "What's the ROI?" These questions fundamentally misunderstand what resilience engineering delivers.

Resilience is not about making money. Resilience is about not losing money.

This distinction is critical. Unlike features that directly generate revenue, resilience measures typically prevent losses that would occur during failures or outages. This prevention-focused value proposition requires a different calculation framework than traditional ROI models.

Consider this: Nine major UK banks experienced a staggering 803 hours—equivalent to 33 full days—of technology outages in just two years. The compensation costs alone were substantial (source):

• Barclays: Up to £12.5 million

• Bank of Ireland: £350,000

• NatWest: £348,000

• HSBC: £232,697

And these figures represent only direct compensation payments, not accounting for the lost business, damaged customer trust, or increased regulatory scrutiny.

The question isn't whether you can afford to invest in resilience; it's whether you can afford not to.

Beyond Prevention: The Eight Dimensions of Resilience Value

Resilience engineering delivers value far beyond mere incident prevention. Here's how a comprehensive resilience approach transforms organizations:

1. Economic Value

When calculating the business case for resilience, we must consider both direct and indirect costs of failure. Direct costs include compensation payments, emergency remediation, and lost revenue during outages. Indirect costs—often far larger—include reputation damage, lost future business, regulatory penalties, and decreased employee morale.

By preventing these losses, resilience initiatives can deliver tremendous economic value, even if they don't directly generate revenue.

2. Competitive Advantage

Organizations with advanced resilience capabilities can thrive in increasingly uncertain environments characterized by volatility, uncertainty, complexity, and ambiguity (VUCA). While competitors stumble during market disruptions or supply chain issues, resilient organizations maintain service continuity, building invaluable trust with customers.

This isn't theoretical—companies like Netflix and Amazon have turned their resilience investments into significant competitive advantages, maintaining availability when competitors cannot.

3. Operational Excellence

Resilience engineering isn't just about crisis management—it promotes operational excellence by fostering continuous improvement. Rather than viewing incidents as failures to be avoided, resilient organizations treat them as learning opportunities.

This perspective shift transforms how teams approach operations. Instead of hiding problems, they surface them. Instead of blaming individuals, they examine systems. This creates a virtuous cycle of continuous improvement that extends far beyond crisis response.

4. Innovation Enablement

Counterintuitively, resilient systems enable faster innovation. When organizations have confidence in their recovery capabilities, they can move more quickly without compromising reliability.

This is particularly crucial in today's business environment, where digital transformation has made business and IT inseparable. The speed at which your technology organization can implement changes without compromising quality directly limits how fast your business can respond to market movements.

5. Risk Management

Resilience engineering provides a systematic approach to managing risks in complex systems. Unlike traditional risk management, which focuses on known risks and checklists, resilience engineering-based approaches help organizations prepare for unforeseen challenges, often referred to as the "black swan."

This comprehensive approach encompasses not just technical failures but also business-level threats such as competitive disruptions, market shifts, or regulatory changes.

6. Human-Centered Value

One of the most overlooked aspects of resilience is its human foundation. Technical systems alone cannot handle all failures, especially unexpected ones. Resilience engineering recognizes this reality and leverages the creativity, adaptability, and problem-solving capabilities of people.

By incorporating the human element into system design, resilient organizations can address challenges that automated systems cannot, particularly in novel situations that weren't anticipated during the design phase.

7. Adaptive Capacity

The most valuable aspect of resilience engineering is that it builds adaptive capacity—the ability to respond to changing threats and circumstances. This differs significantly from stability, which prevents failures, or robustness, which handles expected failures.

True resilience includes handling surprises and continuously adapting to changing conditions. Organizations with high adaptive capacity don't just survive disruptions—they emerge stronger from them.

8. Balanced Approach

Ultimately, resilience engineering provides a balanced approach to achieving both efficiency and effectiveness. While traditional approaches often focus exclusively on efficiency (doing things right), resilience brings in effectiveness (doing the right things).

This balance is crucial in today's business environment. Pure efficiency optimization creates brittle systems that collapse under unexpected stress. Resilience approaches strike a balance between efficiency and the flexibility needed to adapt to changing circumstances.

From Theory to Practice

The value of resilience isn't theoretical—it's practical and measurable. Organizations that implement comprehensive resilience programs consistently outperform those that don't, especially during periods of disruption.

At Resilium Labs, we help organizations build practical resilience capabilities while avoiding common pitfalls:

• Instead of chasing "perfect availability," we focus on rapid recovery

• Instead of building complex defense mechanisms, we create simple, elegant solutions

• Instead of treating resilience as a project to be completed, we embed it as a continuous practice

The result? Organizations that not only survive disruptions but also transform threats into opportunities for growth.

The Path Forward

If you're ready to move beyond traditional approaches to resilience and build genuine adaptive capacity in your organization, we should talk. Resilium Labs specializes in practical resilience approaches that deliver measurable business value without unnecessary complexity.

Remember: The most resilient organizations aren't those that never fail—they're those that learn and grow from every challenge they face.

Contact us to start your resilience journey today.

As our systems become increasingly complex and interconnected, the question isn’t whether failures will occur, but when and how we’ll respond. This reality has given rise to resilience engineering, a discipline that transforms how we think about failure, recovery, and adaptation.

Beyond Simple Reliability

Resilience engineering isn’t just about preventing failures or building reliable systems. While reliability focuses on avoiding failures, resilience acknowledges their inevitability and focuses on successfully responding to them. It’s the difference between trying to build an impenetrable fortress and creating a system that can take a hit and quickly recover.

At its core, resilience engineering is about developing the ability to cope with adverse events and situations successfully. This includes handling expected adverse events (robustness), managing unexpected adverse events (coping with surprises), and improving due to adverse events (learning).

What sets resilience engineering apart is its focus on socio-technical systems, recognizing that technology and human operators function as an integrated whole. It considers not just your technical infrastructure, but also your people, processes, and organizational structure.

Pioneers of Resilience Engineering

With a rich 20-year history as a scientific field, resilience engineering emerged as a discipline focused on how complex systems maintain function during disturbances rather than just preventing failures. It is important to note that resilience engineering spans far beyond software systems. It applies equally to aviation, energy distribution, transportation, financial services, emergency, aerospace, healthcare, telecommunications, and many other domains where complex systems must function reliably despite unpredictable challenges.

Several key figures established the field: Erik Hollnagel and David D. Woods are widely recognized as the primary founders, co-authoring the seminal “Resilience Engineering: Concepts and Precepts” (2006). Hollnagel introduced the influential Safety-I vs Safety-II paradigm, while Woods developed concepts like “graceful extensibility.”

Other foundational contributors include Nancy Leveson with her STAMP (System-Theoretic Accident Model and Processes) methodology, Sidney Dekker, who explored how systems “drift into failure,” Richard Cook, whose paper “How Complex Systems Fail” became a classic text, and John Wreathall, who helped organize the first resilience engineering symposium in 2004. Diane Vaughan made crucial contributions with her work on the “normalization of deviance,” showing how organizations gradually accept increasingly risky decisions because nothing bad has happened yet.

The application of safety science principles to software engineering represents a natural evolution of these foundational concepts. While drawing heavily from these safety science pioneers, the field of software resilience engineering has developed its own distinct practices tailored to the unique challenges of distributed systems. Key figures like John Allspaw played a pivotal role in this adaptation, bringing these concepts into software operations and DevOps culture. Similarly, Jesse Robbins — known as Amazon’s “Master of Disaster” — made significant contributions through his pioneering GameDay exercises, which introduced simulated failure scenarios designed to build organizational resilience in technical environments.

Today, resilience engineering principles are fundamental to managing complex distributed software systems, though the field continues to evolve with unique practices specific to software challenges.

Adaptive Capacity: The Heart of Resilience

“Adaptive capacity” — the uniquely human ability to respond creatively to unexpected challenges — forms the foundation of resilience. While adaptive capacity represents potential, resilience is its successful application when confronting adversity. Organizations practicing resilience engineering deliberately invest in cultivating this adaptive capacity, often confronting what I call the “prevention paradox”: where companies must spend money preparing for problems they can’t foresee, and their biggest wins are simply the disasters that never happen.

This human element is critical. While our technical systems can be designed to handle known failure modes, only human operators can improvise solutions to novel problems. Resilience engineering acknowledges and enhances this capability by fostering environments where adaptation can flourish.

The Journey to Resilience

Becoming resilient isn’t an overnight transformation. Organizations typically progress through several stages:

1. Stability — Initially focusing on preventing failures through technical means

2. Robustness — Embracing failures and handling them gracefully

3. Basic Resilience — Preparing for surprises and considering the entire socio-technical system

4. Advanced Resilience — Treating adversities as opportunities for improvement

Each step along this journey involves not just technical changes but shifts in mindset, culture, and organizational practices.

Prepared to be Unprepared

Perhaps the most profound insight from resilience engineering is the importance of being “prepared to be unprepared.” No matter how thorough our planning and testing are, we will encounter situations we didn’t anticipate. Our systems’ resilience depends not on preventing every possible failure but on our ability to detect, respond to, and learn from the unexpected.

This perspective transforms how we approach system design, operations, and organizational culture. Instead of fruitlessly pursuing perfect reliability, we build systems and organizations that can gracefully handle the inevitable imperfections of complex technological environments.

Resilience in Practice

In practical terms, this means organizations build capabilities across multiple dimensions:

• Develop flexible processes that allow for adaptation when conditions change unexpectedly

• Implement comprehensive monitoring to detect weak signals before incidents escalate

• Learn from both successes and failures

• Support rather than constrain human performance variability

• Take a holistic, systems-thinking approach to understanding interactions between components

Resilient organizations exemplify these capabilities through practices like chaos engineering.

This intersection of technical, human, and organizational factors in resilience engineering will be the focus of an upcoming blog post. In it, we’ll explore how organizations at different maturity levels implement these principles, practical examples across various industries, and strategies for balancing resilience with efficiency.

Why Resilience Matters Now More Than Ever

As our dependency on digital systems continues to grow, so does the impact of their failures. The cost of downtime has never been higher, both in financial terms and in terms of eroded trust and reputation.

Meanwhile, the complexity of our systems continues to increase, making traditional approaches to reliability increasingly inadequate. We can no longer predict and prevent all possible failure modes — we must develop the capacity to respond effectively to the unexpected.

Resilience engineering offers a path forward in this challenging future. By embracing its principles, organizations can build systems that not only survive but thrive amid uncertainty and change. It’s not about avoiding failure at all costs — it’s about failing gracefully, recovering quickly, and emerging stronger than before.

In a world of inevitable surprises, resilience isn’t just a nice-to-have; it’s an essential characteristic of successful organizations and the systems they build.

A resilient lone tree grows horizontally from a rocky mountainside, with half its branches covered in green leaves while others remain bare. The tree extends over a dramatic landscape of gray limestone rock formations, with distant mountains, valleys, and a cloudy sky in the background. The scene captures nature's remarkable adaptability in harsh conditions.

As our systems become increasingly complex and interconnected, the question isn't whether failures will occur, but when and how we'll respond. This reality has given rise to resilience engineering, a discipline that transforms how we think about failure, recovery, and adaptation.

Beyond Simple Reliability

Resilience engineering isn't just about preventing failures or building reliable systems. While reliability focuses on avoiding failures, resilience acknowledges their inevitability and focuses on successfully responding to them. It's the difference between trying to build an impenetrable fortress and creating a system that can take a hit and quickly recover.

At its core, resilience engineering is about developing the ability to cope with adverse events and situations successfully. This includes handling expected adverse events (robustness), managing unexpected adverse events (coping with surprises), and improving due to adverse events (learning).

What sets resilience engineering apart is its focus on socio-technical systems, recognizing that technology and human operators function as an integrated whole. It considers not just your technical infrastructure, but also your people, processes, and organizational structure.

Pioneers of Resilience Engineering

With a rich 20-year history as a scientific field, resilience engineering emerged as a discipline focused on how complex systems maintain function during disturbances rather than just preventing failures. It is important to note that resilience engineering spans far beyond software systems. It applies equally to aviation, energy distribution, transportation, financial services, emergency, aerospace, healthcare, telecommunications, and many other domains where complex systems must function reliably despite unpredictable challenges.

Several key figures established the field: Erik Hollnagel and David D. Woods are widely recognized as the primary founders, co-authoring the seminal "Resilience Engineering: Concepts and Precepts" (2006). Hollnagel introduced the influential Safety-I vs Safety-II paradigm, while Woods developed concepts like "graceful extensibility."

Other foundational contributors include Nancy Leveson with her STAMP (System-Theoretic Accident Model and Processes) methodology, Sidney Dekker, who explored how systems "Drift into failure," Richard Cook, whose paper "How Complex Systems Fail" became a classic text, and John Wreathall, who helped organize the first resilience engineering symposium in 2004. Diane Vaughan made crucial contributions with her work on the "Normalization of deviance," showing how organizations gradually accept increasingly risky decisions because nothing bad has happened yet.

The application of safety science principles to software engineering represents a natural evolution of these foundational concepts. While drawing heavily from these safety science pioneers, the field of software resilience engineering has developed its own distinct practices tailored to the unique challenges of distributed systems. Key figures like John Allspaw played a pivotal role in this adaptation, bringing these concepts into software operations and DevOps culture. Similarly, Jesse Robbins—known as Amazon's "Master of Disaster"—made significant contributions through his pioneering GameDay exercises, which introduced simulated failure scenarios designed to build organizational resilience in technical environments.

Today, resilience engineering principles are fundamental to managing complex distributed software systems, though the field continues to evolve with unique practices specific to software challenges.

Adaptive Capacity: The Heart of Resilience

“Adaptive capacity"—the uniquely human ability to respond creatively to unexpected challenges—forms the foundation of resilience. While adaptive capacity represents potential, resilience is its successful application when confronting adversity. Organizations practicing resilience engineering deliberately invest in cultivating this adaptive capacity, often confronting what I call the "prevention paradox": where companies must spend money preparing for problems they can't foresee, and their biggest wins are simply the disasters that never happen.

This human element is critical. While our technical systems can be designed to handle known failure modes, only human operators can improvise solutions to novel problems. Resilience engineering acknowledges and enhances this capability by fostering environments where adaptation can flourish.

The Journey to Resilience

Becoming resilient isn't an overnight transformation. Organizations typically progress through several stages:

1. Stability - Initially focusing on preventing failures through technical means

2. Robustness - Embracing failures and handling them gracefully

3. Basic Resilience - Preparing for surprises and considering the entire socio-technical system

4. Advanced Resilience - Treating adversities as opportunities for improvement

Each step along this journey involves not just technical changes but shifts in mindset, culture, and organizational practices.

Prepared to be Unprepared

Perhaps the most profound insight from resilience engineering is the importance of being "prepared to be unprepared." No matter how thorough our planning and testing are, we will encounter situations we didn't anticipate. Our systems' resilience depends not on preventing every possible failure but on our ability to detect, respond to, and learn from the unexpected.

This perspective transforms how we approach system design, operations, and organizational culture. Instead of fruitlessly pursuing perfect reliability, we build systems and organizations that can gracefully handle the inevitable imperfections of complex technological environments.

Resilience in Practice

In practical terms, this means organizations build capabilities across multiple dimensions:

• Develop flexible processes that allow for adaptation when conditions change unexpectedly

• Implement comprehensive monitoring to detect weak signals before incidents escalate

• Learn from both successes and failures

• Support rather than constrain human performance variability

• Take a holistic, systems-thinking approach to understanding interactions between components

Resilient organizations exemplify these capabilities through practices like chaos engineering.

This intersection of technical, human, and organizational factors in resilience engineering will be the focus of an upcoming blog post. In it, we'll explore how organizations at different maturity levels implement these principles, practical examples across various industries, and strategies for balancing resilience with efficiency.

Why Resilience Matters Now More Than Ever

As our dependency on digital systems continues to grow, so does the impact of their failures. The cost of downtime has never been higher, both in financial terms and in terms of eroded trust and reputation.

Meanwhile, the complexity of our systems continues to increase, making traditional approaches to reliability increasingly inadequate. We can no longer predict and prevent all possible failure modes—we must develop the capacity to respond effectively to the unexpected.

Resilience engineering offers a path forward in this challenging future. By embracing its principles, organizations can build systems that not only survive but thrive amid uncertainty and change. It's not about avoiding failure at all costs—it's about failing gracefully, recovering quickly, and emerging stronger than before.

In a world of inevitable surprises, resilience isn't just a nice-to-have; it's an essential characteristic of successful organizations and the systems they build.