The Secret of Resilience
- David Creelman
- 1 日前
- 読了時間: 3分
Organisational resilience is a popular idea that everyone can get behind. It can also be a complete waste of time. Wise HR pros understand why such an appealing concept can be so useless—and how to wield it in a way that actually solves problems.
Why the concept of resilience is troublesome
While everyone agrees resilience is important, everyone also has a different idea of what it means. A common mistake is to start with a meeting to agree on a shared definition. That won’t help much. Resilience is what I call a cloud object—inherently vague and fuzzy, a loose collection of things with a family resemblance. You can’t handle this sort of concept with a tight definition. We need a different approach to cloudy ideas in management.
Why analysis doesn’t save us
Faced with a vague, overarching term like resilience, a seemingly reasonable next step is to break it into more concrete parts. You might decide resilience is made up of:
Robustness: resistance to disruption
Recovery: speed of returning to baseline
Adaptability: ability to find new stable states
Redundancy / Slack: spare capacity to absorb shocks
Diversity / Modularity: structural ability to isolate failures
Learning Rate: how fast lessons are incorporated
This gives you plenty to work with, and your few meetings to define “resilience” can turn into a long consulting project to define and measure these factors. The trouble is that each of these factors is also a cloud object. You’ll find yourself swimming in abstractions that sound good but rarely help the business find solutions.
A more effective perspective
When someone says, “We need to build resilience,” think of it as, “I have a sense there’s a problem, and it’s somewhere in that direction.” The point isn’t to focus on the concept of resilience—it’s to uncover whatever observation triggered that concern.
Here’s an example. A manufacturing plant has run into constant trouble because of supply-chain disruptions. The problems can be traced to many components coming through a single overseas port. A brief disruption there caused ripple effects the organisation wasn’t “resilient” enough to handle smoothly.
The next step is straightforward: set up alternative supply lines or build larger inventories for components routed through that port. Later, look for similar vulnerabilities elsewhere. You’re solving tangible problems in the supply chain—not debating the abstract notion of organisational resilience.
Taking it more broadly
If the work on supply-chain resilience proves effective, it may be tempting to seek similar vulnerabilities across the organisation. My instinct is that unless leaders have signalled a specific problem, this is rarely a good use of time.
You might hear leaders say, “We have a problem with morale, team spirit, quality, customer focus, or innovation.” In each case, they’re using a cloudy term to direct attention to where something feels wrong. It’s usually better to ask what they saw that raised the alarm, rather than staying at the level of abstractions like “morale” or “innovation.”
I suspect there’s a bug in human cognition—or organisational life—that makes us believe working at the level of abstractions is the right thing to do. We need to resist that urge. Treat abstractions purely as signposts pointing to a direction, then dig into the specific, observable issues that prompted the concern.
After fixing what’s real
When you’ve addressed the concrete weaknesses in the supply chain, you might report, “We’ve increased resilience in our supply chain.” That’s fine. The abstraction is useful shorthand since leaders don’t need every detail. Just don’t mistake the abstraction for the work itself. The real value lies in the specific actions that—vaguely, loosely—relate to that cloud object called resilience.
Reprise
A concept like resilience isn’t like headcount. Headcount is tangible; resilience is cloudy. The problem isn’t that we can’t measure resilience—it’s that we treat it as something that should be measured. Use words like resilience as pointers to possible problem areas. Then identify the specific issue behind the signal, and fix that—not the abstraction.