When a strategy paper says “resilience”, what is usually meant is something other than what safety research means by resilience. An inventory of contingency plans, a crisis response team with escalation protocols, buffers in stock and personnel, documented recovery times after an outage. All of this is legitimate and valuable. However, it is robustness, or business continuity, or crisis management. It is not resilience in the sense in which the concept was developed.
The confusion is not harmless. Robustness and resilience behave differently under real complexity, sometimes in opposite directions. Building one while meaning the other leads, under stress, to difficulties that the programme did not anticipate.
What “resilience” usually means in practice
A look through resilience programmes in organisations turns up a recurring inventory. Crisis playbooks defining who takes which role in an emergency. IT buffers limiting downtime. Supply chain diversification against single-source risks. Stress tests checking load reserves. Staff training in “resilient working”, often with elements borrowed from the wellness vocabulary. The list is not wrong. It is, however, robustness.
Robustness is the capacity of a system to absorb defined disturbances without functional loss. It is built proactively against anticipated threat scenarios. Once all probable failure paths are known, the system can be hardened against them: through redundancy, through buffers, through tested recovery procedures. This is a serious and non-trivial discipline, and it is the foundation of any functioning crisis preparedness.
Robustness reaches its limit the moment a disturbance is not on the scenario list. A supply chain disruption that no risk register foresaw, a cyberattack of a form no one expected, a regulatory tightening overnight: robustness logic cannot prepare for the unknown because it is optimised for the known. This is exactly where the concept of resilience comes in, and exactly where it tends to get steered away.
What resilience means in the strict sense
The concept has a longer history than its organisational use. Crawford Stanley Holling coined it in 1973 for ecological systems: the capacity of an ecosystem to absorb disturbances without flipping into a qualitatively different state. Engineering picked up the term in the 1990s in a narrower form, closer to robustness than to Holling’s original meaning. With the volume Resilience Engineering: Concepts and Precepts by Hollnagel, Woods and Leveson in 2006, the definition that now dominates in safety research emerged: resilience as the capacity for adaptation to the unexpected, not as recovery from the known.
Resilience, in the sense Erik Hollnagel has anchored in this tradition, is not the ability to absorb known disturbances. It is the ability to function under conditions that were not anticipated in planning. Hollnagel makes this concrete through four capacities: anticipating what might develop, monitoring what is happening, responding to the unexpected, and learning from what has occurred. A robust organisation has these four capacities as well, but it has trained them on the predictable: risk registers for known scenarios, dashboards for defined indicators, playbooks for pre-considered situations, lessons learned from incidents that have occurred. A resilient organisation trains the same four capacities on the unexpected: anticipation oriented to classes of possible disruption rather than only to named scenarios, monitoring for weak signals beyond the indicator list, responding without a playbook, learning from near misses rather than only from the loud event. In the realm of the predictable, both function. In the realm of the unexpected, the two differ fundamentally, because resilience keeps the four capacities operational where preparation reaches its limit.
David Woods has sharpened the same property with the term graceful extensibility: the question of how far a system can be stretched before it breaks, and how it behaves while being stretched. A robust system has a clear load limit and fails sharply once that limit is exceeded. A resilient system has a fraying zone before the limit, in which it loses functionality but does not collapse. Actors in the system have room there for adjustments that hold the system together.
The distinction may sound pedantic, but it has operational consequences. Robustness is optimised against lists: whoever has the complete list has secured the system. Resilience is optimised against surprises. Building resilience means accepting that the list will never be complete and investing in properties that carry beyond it.
Robustness is optimised against lists. Building resilience means accepting that the list will never be complete, and investing in properties that carry beyond it.
Prerequisites that the discourse often overlooks
Resilience in the strict sense is not a single mechanism. It is a property of a system that emerges from several preconditions. Three of these are underexposed in most programme designs.
The first is slack: operational room beyond bare utilisation. An organisation that optimises its staffing and material reserves to the necessary minimum has, by definition, no capacity to respond to the unexpected. Slack is not waste. Slack is the reserve that allows a system to respond to conditions that were not part of the utilisation plan. In efficiency-driven organisations, slack is systematically engineered out.
The second is safe communication along the hierarchy. Resilience requires weak signals from the line to reach the top when they matter. An organisation in which speaking up about problems is personally risky cannot be resilient, no matter how many crisis playbooks it holds. Amy Edmondson’s work on psychological safety provides the research foundation for this, and it is rarely connected to resilience programmes.
The third is tolerance for variation. Resilient systems allow local adaptation by their actors, because the script never fully knows local conditions. An organisation that treats every deviation from the procedure as a compliance breach trains its line to hide the adaptive work that its safety depends on every day. Building resilience in the strict sense means accepting that variation is not a defect, but the ongoing translation of the rule into reality.
None of these three preconditions can be presented on a programme slide. All three are costly; they require giving up maximum utilisation, reflexive sanctioning, and strict procedural adherence. They are not certifiable. They are the conditions under which resilience can emerge in the first place.
Why the confusion happens
If the distinction is clear and the preconditions can be described, why does the term blur so consistently in organisational use? The honest answer lies in the incentive system, not in the concept.
Resilience in the strict sense is hard to measure, hard to report, and hard to plan beyond the quarter. It calls for investments whose payoff comes in the form of crises that did not happen. A crisis that did not happen is difficult to claim as a KPI. A board that invests in resilience funds a property it cannot measure and cannot show.
Robustness, by contrast, is friendlier. Crisis playbooks can be documented, stress tests passed, buffers quantified, recovery times benchmarked. Building robustness can be shown in quarterly reporting. Building resilience requires explaining what did not happen because it did not happen.
This incentive gap explains why “resilience” in organisational discourse has become whatever is reportable. What is reportable is predominantly robustness. It is not bad faith. It is structural logic. A board optimises what it can show. What cannot be shown drops out of the programme, even when it keeps the name.
The pattern became visible after 2020 in a wave of organisational “resilience” programmes. The pandemic had exposed supply chain gaps in many industries; the programmes set out to close them: multi-sourcing, safety stocks, local production capacity. All of this is sensible, all of this is robustness. What few of these programmes built was the capacity to spot the next unforeseen disruption earlier and to unlearn and relearn faster, before it became a crisis. That is the resilience question. It was not asked, because it does not fit on a roadmap.
How to spot the confusion
When a “resilience programme” is on the table, the diagnostic questions are not hard. First: where in the programme are reserves being built, and where are the existing efficiency programmes adjusted accordingly? Second: where are mechanisms described for the safe reporting of weak signals, and where are the sanctioning logics that make such reports costly today being revised? Third: where is tolerance for local adaptation made explicit, and where are compliance expectations recalibrated so that the adaptation is allowed to remain visible?
If all answers are blank, the programme is not resilience. It is robustness under a new label. That does not mean it is worthless. It means the organisation has a gap it does not know about, because the label makes the gap invisible.
What is worth saving of the concept
Saving the term takes two moves. The first is semantic: holding resilience and robustness apart, even where doing so makes strategy documents more demanding. What is robustness should be called robustness. What is business continuity should be called business continuity. Resilience reserved for what Hollnagel and Woods meant by it.
The second is organisational: taking resilience as a property with its preconditions seriously, that is, slack in the system, safe communication, tolerance for variation. And accepting that these preconditions do not become visible in the reporting format by which the organisation otherwise measures success. Those who cannot accept this should drop the term rather than dilute it further. Robustness deserves recognition on its own. It does not need the resilience label.
Sources
- Erik Hollnagel – Safety-II in Practice: Developing the Resilience Potentials, Routledge 2018
- Erik Hollnagel, David Woods & Nancy Leveson (eds.) – Resilience Engineering: Concepts and Precepts, Ashgate 2006
- David D. Woods – “Four concepts for resilience and the implications for the future of resilience engineering”, Reliability Engineering & System Safety 141 (2015)
- C. S. Holling – “Resilience and stability of ecological systems”, Annual Review of Ecology and Systematics 4 (1973)
- Amy C. Edmondson – The Fearless Organization, Wiley 2018