Most resilience programs don’t fail because the plans are wrong. They fail because the people running them make the work more complicated than it needs to be, and never tie it back to what the business actually cares about.
Over the past years, I’ve watched multiple experienced, capable executives run resilience programs inside large, complex organizations. They knew the material cold. They cared about getting it right. And they still, without meaning to, buried simple programs under layers of structure, terminology, and process that no one outside the program could follow, and that no one in the business could connect to a reason they should care.
The language got denser. The committees multiplied. A simple decision became a paragraph. A one-hour training session got its own communication plan. By the time a point reached the people who had to act on it, it had picked up so much process, qualification, and acronym that the original idea was hard to find.
None of them were bad leaders. That is exactly why this is worth writing about. Overcomplicating your resilience program is not a failure of intelligence or effort. It is a failure of discipline, and it is one of the most common ways good programs stall.
The Complexity Tax
Every layer you add to a resilience program has a cost. Not just the cost of building it. The cost of everyone underneath you having to understand it, navigate it, and explain it to someone else.
I call this the complexity tax. You pay it every time you stand up another team or tier that overlaps with one you already have. Every time you use four words where one would do. Every time you answer a yes-or-no question with a framework.
The tax is invisible on the org chart and brutal in a real event. When a disruption hits, your program does not run at the speed of your intentions. It runs at the speed of the least-clear thing in it. If your team cannot explain who decides what in one sentence, they will not suddenly find that clarity at 2 a.m. with systems down and a ransom demand on the table.
Resilience is not the same thing as sophistication. The goal is a program people can actually run under pressure, not a program that impresses people in a planning meeting.
The Obvious Fix Makes It Worse
When a resilience leader senses that the program is shaky, the instinct is almost always the same: add rigor. Stand up another team. Write another charter. Build a more detailed taxonomy. Schedule a recurring meeting to coordinate the other meetings.
It feels like leadership. It is usually the opposite.
| Old view | New view |
| More structure means more control | More structure means more places for clarity to leak |
| Adding a team or a step closes the gap | Adding a team or a step usually creates two new handoffs |
| Precise terminology signals expertise | Plain language signals you actually understand it |
| A finished plan means the work is done | A plan no one ties to the business is just paperwork |
| Knowing the framework means knowing the plan | If you can’t explain what the plan does, you don’t have one |
The leaders I watched were not lazy. They were diligent to a fault. The problem was that their diligence expressed itself as addition. More bodies, more words, more caveats, more process. Almost never subtraction.
Five Ways Leaders Overcomplicate Resilience
Here is what the complexity tax actually looks like in practice. I have seen versions of all five from leaders who knew their material and still managed to make it harder to follow.
- A structure no one can explain. Plenty of programs run several response teams: a cyber crisis team, a broader crisis team, an escalation tier above them. There is nothing wrong with that on its own. The problem starts when the person running it cannot explain, in plain language, who does what and where one team hands off to the next. I have watched leaders raise that exact question about their own structure, meeting after meeting, and never resolve it. If you cannot explain your own response model simply, one of two things is true: the design is too complicated, or you are not communicating it well enough. Both are yours to fix.
- Terminology that hides the meaning. Resilience runs on acronyms. BC, DR, BIA, RTO, RPO, MTPD, on and on. The shorthand is fine among practitioners. It is poison in front of the business. The clearest case I saw was a leader describing the role a program actually needed. What they meant was simple: we need one person to own this so it doesn’t fall apart. What they said was that they wanted to ensure continuity of process and the rigor and discipline to support it going forward. The second version sounds more senior. It is also nearly impossible to act on. Abstraction is where accountability goes to hide.
- A program that isn’t tied to the business. This is the big one. Too many resilience programs exist to satisfy themselves. They produce plans because plans are the deliverable, not because anyone connected them to what the business needs to keep running. When a program cannot say which revenue stream, customer commitment, or critical process a given plan protects, it has stopped being resilience and started being paperwork. Leadership feels that disconnect even when they cannot name it, and it is why so many programs fight for funding and attention they should not have to fight for.
- Explaining plans you don’t actually understand. I have watched leaders talk confidently about “the BC plan” or “our DR capability” with no real grasp of what those plans do, what they assume, or whether they would hold up. Saying “we have business continuity plans for our sites” means nothing if you cannot say what happens when a site goes down, who moves what, and how long it takes. Borrowed language without underlying understanding is the most dangerous kind of complexity, because it sounds like competence right up until the moment you need it to be real.
- Solving confusion by adding more process. Faced with a gap, the reflex is to add something. A one-hour training gets a multi-touch communication campaign. An ownership question becomes a proposal for a new standing meeting. A naming problem becomes another playbook. None of these are crazy on their own. Stacked together, they turn a program anyone could follow into one only the architect can navigate.
None of these come from incompetence. They come from caring a lot, knowing a lot, and never running the work back through a single filter: is this simpler or more complex than it needs to be?
What To Do Instead
You do not fix overcomplication with more sophistication. You fix it with discipline. Here is the practical version.
Explain the whole program in five sentences. If you cannot describe your response structure, who decides what, and how it escalates in five plain sentences, the problem is either the design or your command of it. Find out which, and fix that, before you brief anyone else. The five-sentence version is not a dumbed-down version. It is the real one.
Cut the acronyms in front of the business. Among practitioners, use the shorthand. In front of executives, say what you mean in words a smart outsider would understand. When you catch yourself reaching for “rigor,” “discipline,” or “continuity of process,” stop and name the person, the date, and the task instead. Your team cannot execute a noun. They can execute a person, a date, and a task.
Anchor every plan to a business outcome. Before you build or maintain a plan, name the revenue stream, customer commitment, or critical process it protects. If you cannot, you are not ready to build it, and you should not be spending the money. A program tied to the business gets funded and used. A program tied to nothing gets ignored, no matter how complete it looks.
Know your own plans cold. Do not talk about a BC or DR plan you cannot explain in plain language: what it protects, what it assumes, what happens in the first hour, and how long recovery actually takes. If you do not know, say so and go find out. Borrowed confidence is worse than admitted uncertainty, because it fails exactly when you are counting on it.
Subtract before you add. When something is unclear, default to removing a step, not adding one. For every team, meeting, or document, ask what would break if it disappeared. Most of the time the honest answer is “nothing, except some egos.” Simplicity is a choice you have to keep making.
Translate before you publish. Before any plan, charter, or briefing goes out, hand it to someone two levels down who was not in the room. If they cannot tell you what it means and what they are supposed to do, it is not done. The executive who has to use your program in a crisis carries none of the context you carry. Write for them.
What Good Looks Like
A resilience program that works is not the one with the most components. It is the one a tired person can run correctly at the worst possible moment.
That means fewer moving parts, with sharper edges. Plain words instead of acronyms. Every plan tied to something the business actually cares about. One owner per outcome. A leader who can explain the whole thing in five sentences and trusts the room to act.
The leaders I watched had everything they needed to build that. Deep expertise. Real authority. Genuine commitment. What they did not have was a habit of subtraction, and that one missing habit cost their programs speed, clarity, and momentum they could not afford to lose.
Resilience is not about how much you can build. It is about how little stands between your people and the right action when it counts.
Strip it down. Say it once. Then go.
Keep Going
A few ways to go deeper if this was useful.
- Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Crisis Management.
- Build one system, not a pile of parts. The Resilience Operating Model® integrates business continuity, crisis management, IT disaster recovery, and risk into one operating system instead of competing teams and disconnected plans.
- Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap, including where complexity is slowing you down.
- Talk to us. Set up a call to think through your program with us.
Resilience Is a Profit Center, Not a Cost Center