The most expensive management mistake isn’t a bad decision

It’s a sound method aimed at the wrong kind of situation…

The most expensive management mistake I see isn’t a bad decision. It’s a sound decision-making method aimed at the wrong kind of situation. The method is rigorous, the plan is detailed and confident — and it’s pointed at a problem that doesn’t obey the rules the method assumes. So it fails slowly, expensively, and with everyone behaving impeccably the whole way down.

You rarely get a dramatic blow-up. You get a year of competent-looking motion and nothing to show for it.

The fix starts by refusing to treat “a problem” as one kind of thing.

Two situations (out of several)

Cynefin — the sense-making framework behind this — maps several spaces: clear, complicated, complex, chaotic, and a middle state with two faces: confused, when you don’t realize there are different situations and act from the wrong one without knowing it, and aporetic, when you deliberately suspend judgment — an intentional, thoughtful double-take — until you can sense where you actually are. I’m going to stand on a single boundary, because that’s where a lot of the money leaks: the boundary between ordered and complex.

Ordered work has a knowable answer. Cause and effect are reliable; ask the right people, do the analysis, and the answer holds still long enough to write down and repeat. A flaky payment integration failing in production is ordered: you don’t brainstorm it, you pull in the engineer who knows the system, read the logs, and fix it. Ordered work has two grades — at the clear end the answer is already known (match it to the rule and respond); at the complicated end the answer exists but takes expertise to find (analyze, then respond).

Complex work has no answer you can know in advance — only in hindsight. Expertise buys confidence, not certainty, and the act of intervening changes the thing you’re trying to read. Will customers accept a new pricing model? Will this culture change stick? You can’t analyze your way there. You run small, safe-to-fail probes — try something, watch what actually happens, amplify what works, dampen what doesn’t. Testing rough product ideas against real user behavior is the everyday version.

“Complicated” is not the opposite of complex, and not the whole of ordered — it’s one room in the ordered house. Flattening ordered into complicated, or the whole map into two spaces, is the confusion that does the damage.

Most of your real problems are mixed

Phaseshifts occur. Here’s the part that makes it usable: almost no real initiative sits in one space. Take “re-platform billing and move customers to usage-based pricing.” Pull it apart:

• The new billing engine is mostly complicated — a known engineering pattern. Bring in people who’ve built one before and plan it.
• The data migration looks ordered but rarely behaves that way. Legacy data hides edge cases and undocumented rules nobody remembers, so you don’t get to plan it clean — you migrate a slice, see what breaks, reconcile, and go again. That’s iterative and emergent: complex in practice, even though the end state is fixed. Each trial run is a safe-to-fail probe.
• Whether customers accept usage-based pricing — and how they behave under it is squarely complex. Nobody knows in advance, your own rollout shifts the answer, and you can only read it in hindsight. A bet, not a plan.

Run the whole thing as one confident program with a locked launch date and a business case that assumes both the data and the pricing behave, and you’ve dressed two complex bets in an ordered plan’s clothes. The engine build was never the real risk. The data and the pricing were — and you ran them as certainties.

Consider the context. The same activity can sit in different spaces depending on the data you’ve inherited, the people you have, and what’s moving around you — so read the situation in front of you, not the label on the work.

And they don’t sit still

A problem’s domain isn’t a fixed address — it phaseshifts, and the borders between spaces are transitional zones, not sharp lines. Cynefin calls those in-between zones liminal. The skill is to manage the crossing on purpose — or monitor the phase shift and respond appropriately — instead of pretending it isn’t happening.

The most common managed crossing runs between complex and ordered. You probe in complex until something works; sometimes a successful experiment becomes a documented, repeatable process and the work crosses into ordered. The pricing bet is the example: once a probe lands on a model customers actually accept, you don’t experiment forever — you standardize it, write it down, and run it. When that codified process later stops working, you cross back: re-open it into complex and probe again. Organizations that do this well are ambidextrous — running stable, repeatable work and live probes at the same time, and moving work across the border as it earns the crossing.

You’ll hear that rhythm labeled “explore versus exploit.” Handle the label with care — it’s a binary you should treat warily. Exploration can mean a deliberate move toward chaos, not just probing in complex; a probe can be about exploiting an opening as much as discovering one; and plenty of exploiting happens inside complex, not only in ordered. Let the space tell you how to act, not the slogan.

Chaos itself has two faces. One you sometimes step toward on purpose: a market lurches or a competitor moves, and the right response is to act fast and make something new before the situation settles — launch the answer now, make sense of it after — then pull back. The other you fall into. The edge between clear and chaotic is drawn in Cynefin as a cliff, not a slope, and the mechanism is complacency: treat something as more routine than it really is — lock the plan, hard-wire the dependencies, strip out the slack — and it holds right up until it doesn’t. Then you don’t drift into “a bit complex”; you drop straight into chaos, where the only move left is to act first and stabilize before you can think.

The data migration shows the difference. A complicated-at-best job treated as routine — hard cutover, old system already scheduled for decommission — until the data turns out to be a pain in the arse: undocumented rules, broken records, reconciliations that won’t reconcile. Catch that in a dry run and you’ve simply crossed into complex for a while: probe, adapt, then codify the fix back into ordered. Catch it at cutover with no way back, and the floor gives way into chaos — customers double-billed, money moving wrongly, an all-hands incident nobody chose. Same problem. The difference between a managed crossing and a fall off the cliff was whether you’d kept a way back.

What to do differently tomorrow

1. Sort before you fund. For the biggest bet on your desk, ask one question: is the answer knowable in advance, or only in hindsight? Knowable → plan it and bring the expert. Only-in-hindsight → stop planning and start probing.
2. Split the mixed ones. Separate the parts with a known right answer (plan and resource those) from the genuine bets (run those as experiments). Govern them differently — a known build deserves a plan; a data migration or a pricing change deserves a probe loop.
3. Trade one big plan for three small safe-to-fail probes. For the complex part, make each probe small enough that failing it teaches you something cheaply instead of sinking you. Decide up front how you’ll know it’s working, and what you’ll scale or kill based on what you see.
4. Codify what works repeatably — then stay ready to re-open it. When a probe lands on something repeatable, write it down and move it into ordered. But diarize the assumption it rests on, because the day it stops holding, that process needs to go back into the complex pile, not get run harder.
5. For probes to be safe to fail, keep a way back — For anything you’re treating as ordered that might not be, preserve a fallback — a staged rollout, a parallel run, a rollback path. It’s cheap insurance against the floor giving way, and it’s the difference between a surprise that lands you in complex and one that drops you off the cliff into chaos.
6. When a reliable process suddenly stops working, change mode — not effort. Re-running the procedure harder is the ordered reflex. A process that used to work and now doesn’t usually means the ground shifted from ordered to complex: probe, don’t just tighten the screws.

One caution on that last move: don’t swing straight from “run it harder” to “launch a dozen experiments.” Both are the same impatience. When something you trusted stops behaving — or the team deadlocks between two strategies, each camp certain it’s right — the most useful first response is a deliberate pause. That’s the thoughtful face of Cynefin’s middle state — aporia, productive puzzlement: you hold the contradiction (“this always worked; now it doesn’t, so my read of the situation is wrong”) without rushing to resolve it. Sit in that not-knowing just long enough — it’s the eye of the storm, or the beat before a riddle clicks — and then re-sense which domain you might be in. Skip the pause, and you’ll probe confidently in the wrong direction.

“Best practice” is a domain claim, not a virtue

Notice what “best practice” quietly assumes: this situation is stable and well understood enough that someone else’s answer will work here too. Fair in ordered work — best practice at the clear end, good practice at the complicated end, where experts can legitimately disagree. Dangerous in complex work, where copying another company’s answer imports their context with it — and you have the recipe and none of the kitchen.

So the next time someone says “Company X runs it this way,” don’t ask “did it work for them?” Ask “is our problem the same kind of situation as theirs?” If it’s complex, their model is a story — interesting, maybe instructive, not transferable. The honest move in complex work is to set enabling constraints (a clear boundary and goal, not a prescribed method), then manage for emergence: you don’t get to decide what grows, you make some outcomes more likely than others and adjust as the system shows its hand.

Where this comes from

The person to read is Dave Snowden; the framework is Cynefin — developed originally in knowledge management at IBM, popularized by the 2007 Harvard Business Review piece he wrote with Mary Boone, and refined over two decades since. What I value most is its intellectual honesty: it doesn’t promise complexity can be tamed, only that you can act sensibly inside it. Less marketable, far more useful.

One thing to try this week: pick the biggest plan you’re about to approve and find its core assumption. Is it knowable — or a bet you’ve dressed as a certainty? And if it’s a bet, who would have to admit that before you’d run it as one?

Sources & further reading

• The Cynefin Company — https://thecynefin.co
• Cynefin.io, the open community wiki — https://cynefin.io
• Scrum Guide Expansion Pack, Complexity — https://scrumexpansion.org/complexity/
• Snowden, D. & Boone, M. (2007), “A Leader’s Framework for Decision Making,” Harvard Business Review
• Snowden, D. et al. (2020; 2nd edn. 2022), Cynefin: Weaving Sense-Making into the Fabric of Our World, The Cynefin Co.

Subscribe for weekly pieces that hand executives sharper lenses, not heavier methodologies.

About the author

John Coleman writes about adaptive organizations and executive leadership. His book MORE Executive SUCCESS — The Great Hypothesis (foreword by Dr. Marshall Goldsmith) is forthcoming.