Field Note #083 | The Resilience Illusion

The weather was calm. The foundation was rotting.

PRASAD BHONDE

7 min read4 days ago

The Resilience Illusion: Why a System That Never Fails May Still Be Fragile

The difference between operating without disruption and being prepared to survive one.

The most reassuring sentence in a workplace is sometimes the least informative.

“We’ve never had a problem.”

A product has been operating for years.
The software has maintained its availability.
Deliveries have arrived on schedule.
The team has met its commitments.

Everything appears to be working.

But ask a different question.

What happens when the conditions that made everything work suddenly disappear?

What happens when the primary supplier cannot deliver, the infrastructure becomes unavailable, the workload changes dramatically or the person who understands a critical process is no longer there?

Suddenly, the organisation discovers that its excellent operating record and its ability to withstand disruption are two different things.

This is The Resilience Illusion.

It describes the mistake of treating uninterrupted operation under familiar conditions as proof of an ability to withstand unfamiliar disturbances.

1. The comfort of familiar conditions

Consider a system that has operated consistently for several years.

Its procedures are established.
Its people understand the routine.
Its dependencies are functioning.
Its performance indicators remain within acceptable limits.

There is little reason for anyone to question it.

Yet the system may never have encountered the conditions that would expose its weakest assumptions.

A software platform may have an impressive availability record without anyone having rehearsed a complete restoration from a serious backup failure.

A manufacturer may meet every delivery commitment while depending heavily on one supplier whose absence would halt production.

A business may operate smoothly while a handful of employees quietly carry knowledge that has never been documented or transferred.

These are illustrative situations, not reported incidents.

The common problem is straightforward:-

we become familiar with the conditions under which something succeeds and gradually mistake those conditions for proof of resilience.

The absence of disruption is reassuring.
It is also incomplete information.

2. Stability and resilience answer different questions

Stability concerns the consistency of performance under particular conditions.

Resilience concerns what happens when those conditions change.

The distinction matters because a system can be remarkably stable inside a narrow operating envelope and deeply vulnerable outside it.

Imagine a bridge carrying ordinary traffic every day.
Its uninterrupted service is useful evidence about its performance under the loads and conditions it has experienced.

It does not, by itself, establish how the structure will respond to every combination of unusual loading, environmental exposure, material degradation and maintenance failure.

The same distinction applies to organisations.

A team that has never missed a deadline may have excellent processes.
It may also have no tested way to redistribute work when two critical people become unavailable.

A supply chain that has never experienced a significant interruption may be efficient.
Its recovery capacity remains a separate question.

A calm operating history describes the past.

Resilience concerns the system’s capacity to deal with a changing future.

3. What makes a system resilient?

Resilience engineering offers a useful way to examine this question.

Erik Hollnagel’s framework identifies four important capabilities:

Respond: Can the system take appropriate action when conditions change?

Monitor: Can it recognise developing conditions and warning signs?

Anticipate: Can it prepare for circumstances that may challenge its current operating assumptions?

Learn: Can it use experience to improve its future behaviour?

Together, these capabilities offer a more useful way of thinking about resilience than simply asking whether something has failed.

Notice the shift.

Instead of examining only the system’s output, we examine its ability to understand and respond to its environment.

This is particularly important in complex organisations, where a disturbance rarely remains confined to the component in which it originates.

A supplier interruption may become a production delay.
A production delay may affect customer commitments.
A staffing shortage may expose undocumented dependencies.
A software failure may reveal that the backup and restoration processes were designed around assumptions that no longer hold.

The system must do more than continue operating.

It must recognise, respond, recover and learn.

4. Testing the conditions that matter

This is where deliberate testing becomes important.

A test should challenge an assumption.

If the critical question is whether a component tolerates a specified load, the test must examine that load within a defined engineering protocol.

If the concern is thermal performance, the relevant temperature boundaries and operating conditions must be considered.

If a business depends on a backup process, the useful question is whether the backup can actually be restored.

There is an important distinction between having a contingency and demonstrating that it works.

Get PRASAD BHONDE’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

NASA’s Systems Engineering Handbook describes qualification testing at higher-than-normal environmental levels to examine performance margins and behaviour under worst-case scenarios.

It also treats different verification and validation activities separately.

The underlying engineering lesson is valuable:-

define the conditions that matter, determine how they will be examined and establish what constitutes acceptable performance.

However, testing has boundaries.

A successful test does not prove that every possible failure mode has been discovered.
It provides evidence about the scenarios, assumptions and configurations actually examined.

The objective is to reduce important unknowns, not manufacture an illusion of certainty through a large number of test reports.

5. The weaknesses that ordinary operations conceal

There are several questions worth asking whenever a system appears exceptionally reliable.

Hidden dependencies: Does the system rely on a component, person, supplier or infrastructure provider whose absence would create disproportionate damage?

Untested assumptions: Which operating conditions have simply been assumed rather than demonstrated?

Recovery capability: When something fails, who responds, what resources are available and how does normal operation resume?

Weak signals: Are small deviations recorded and investigated, or dismissed because the overall performance remains acceptable?

Knowledge concentration: Can the system function when the individual who normally resolves exceptional situations is unavailable?

The last question deserves particular attention.

A system can appear resilient because one exceptionally capable person repeatedly compensates for its weaknesses.

That individual may be the person who understands the old software, knows which supplier to call, remembers an undocumented workaround or can repair a process when the formal procedure stops working.

The system receives the credit.

The individual quietly carries the risk.
Until they are unavailable.

6. A practical resilience review

A useful review begins with one simple exercise.

List the assumptions that must remain true for the system to operate.

Then examine what happens when each assumption becomes false.

This is an illustrative starting register.
Actual test conditions, acceptance limits and safety controls must be defined for the specific system.

Record what has been tested, what passed, what failed and what remains unknown.

Do not use a green status indicator to disguise the absence of evidence.

An unknown condition is not a failed condition.
But it should never quietly become an approved one.

7. The boundary of the argument

There is a temptation to interpret this idea as an instruction to test everything under increasingly extreme conditions.

That would be a mistake.

Testing consumes resources.
Some tests can damage equipment, introduce risk or produce results that do not represent realistic operating conditions.

No organisation can anticipate every possible disturbance.

The objective is to identify the most consequential assumptions, examine credible stress scenarios, understand failure behaviour and maintain the ability to adapt.

Testing must be appropriate to the risk, system, intended use and applicable requirements.

Resilience also requires more than testing.
Monitoring, resource availability, decision authority, learning and recovery arrangements matter.

A system can pass a demanding test and still be poorly equipped to respond to a different kind of disruption.

This is why an absence of failure cannot establish resilience, and a single successful test cannot establish it either.