Every business has one. The problem that’s been stuck for years, that you’ve thrown people at and written plans for, and that still won’t budge. Eventually you decide it’s just a hard one and learn to live with it.
It might not be hard. It might be misnamed.
Most business problems are one of two kinds, and each needs the opposite method. Get it wrong and you’ll pour a year into a plan that was never going to work, without ever quite seeing why.
Complicated and complex are not the same word
Strip away the jargon and it comes down to one question: can you work out the answer in advance, or do you have to act to find it?
A complicated problem is knowable. Cause and effect are real and traceable, they’re just not obvious. You need expertise and analysis to get there, but the answer is sitting there waiting to be reached, and often there’s more than one good one. You can break the problem into parts, solve each part, and put it back together. Why your quoting process takes three days when it should take one. Why last month’s numbers won’t reconcile. How to turn the way your best estimator prices a job into something anyone on the team can follow. These all have answers. The method: analyse it, bring in the right expertise, write the process. A template is exactly the right tool.
A complex problem is different in kind, not just in difficulty. Cause and effect only become clear in hindsight. The parts interact, and the system reacts to whatever you do to it, so there’s no fixed answer sitting out there waiting. Your own actions change what the right answer would even be. Getting two teams to actually work as one after you’ve merged them. Getting the workshop and the office to stop pointing fingers at each other. Getting everyone to actually use the new system you just paid for. None of these has a clean answer you can settle at a whiteboard, because the moment you act, the people react and the ground shifts under the plan. The method here is the opposite of a grand plan: run small, safe-to-fail experiments, watch what actually happens, do more of what works and drop what doesn’t. The answer emerges. You don’t design it up front.
The tell is the plan. For a complicated problem, a detailed plan is a sign of good work. For a complex problem, a detailed up-front plan is the trap. It looks reassuring in the room, and then reality refuses to honour it.
The expensive mistake is treating the second like the first
There are two ways to get this wrong, and one of them is far costlier than the other.
Under-analyse a complicated problem and you flail. You tinker and experiment where an expert could have just told you the answer. Wasteful, but you can see it happening.
Over-analyse a complex problem and you get the expensive one. You commission the plan. You build the framework. You roll out the reorg. It all looks competent, and it fails quietly over months, because you brought a blueprint to something that was never going to hold still long enough to be built to spec. Nobody can say exactly why it didn’t work, so the business concludes the problem is “just really hard” and reaches for the same kind of solution again. That’s the loop that eats years.
Most of the “we’ve tried everything and nothing sticks” work we get called into is sitting in that loop. Nine times out of ten nothing was wrong with the effort. The effort was aimed at the wrong kind of problem.
The first move isn’t solving. It’s naming.
The most dangerous state isn’t complex or complicated. It’s not knowing which one you’re in. When people can’t read a situation, they fall back on the method they’re most comfortable with. The proceduralist reaches for a checklist. The expert wants to analyse. The founder wants to experiment, including on problems that have a known answer sitting right there. Each is applying a favourite tool to problems it doesn’t fit.
So before you solve anything, ask what kind of problem it actually is. Four questions, in order, and you stop at the first yes.
Is this an active crisis with no time to think? Then it’s chaotic. Stabilise first, worry about the elegant solution later. If not: are cause and effect obvious, with a known answer anyone could apply? Then it’s simple. Use the standard response and move on. If not: is the answer knowable by analysis, the kind of thing experts would converge on if they dug in? Then it’s complicated. Bring in the expertise and do the work. If not, if the answer only shows up once you act and the system reacts to what you do, then it’s complex. Don’t demand a plan. Probe, sense, respond.
It costs almost nothing to ask, and it’s the single cheapest thing you can do to stop pouring money into the wrong method.
The good news: problems move
These aren’t fixed states, and that’s the useful part. A complex problem, worked through experiments, gradually reveals what works. Once you know what works, it becomes complicated: a knowable thing you can analyse and plan around. A complicated problem, once solved, can be standardised into a simple one: a checklist, a template, a rule anyone can follow.
Push problems down the ladder and your business gets cheaper to run over time, because yesterday’s hard problem becomes today’s standard procedure. That only works if you named each one correctly to begin with.
Where this fits
This is the first question we ask on any engagement, before we touch a tool or draw a process: what kind of problem is this, actually? It’s the same instinct behind systems thinking and behind our Engage, Enable, Enrich approach. Understand the real problem first. Match the method to it second. Most of the expensive mistakes we get called in to unwind skipped that order.
The next time something in your business isn’t working and nothing sticks, stop before you commission another plan and ask whether you’ve been treating a complex problem as a complicated one. It’s the cheapest move you’ll make all quarter.