Why the hardest problems are rarely the ones you can simply work out.
We use the words as if they mean the same thing. A tax structure is complicated; a merger is complex; a piece of legislation is complicated; a transformation programme is complex — and most of the time we reach for whichever feels heavier without noticing we have said something different. But the two are not degrees of the same thing. They are different in kind, and confusing them is, in my experience, the single most common reason that expensive, capable, well-intentioned effort comes to nothing.
A complicated problem is a clock. It may have a great many parts, and taking it apart may demand years of training, but it is knowable. There is a right answer, and a patient expert can work toward it. Building a bridge is complicated. Migrating a system is complicated. Untangling a cross-border tax position is complicated. None of these is easy — they can be brutally hard — but the difficulty lives in the parts, and the parts hold still while you study them. Get the engineering right and the bridge stands.
A complex problem does not hold still. It is not a clock but a conversation, or an argument. It behaves differently each time you approach it, it responds to your intervention by changing, and it rarely has a single right answer — only better and worse ways through. You can do everything correctly and still fail; you can muddle through and still succeed; and afterwards it is genuinely hard to say exactly why. The defining feature of a complex problem is not that it has more parts. It is that the parts have opinions.
That is the whole of it, really. The thing that turns a complicated problem into a complex one is people. A system migration in a laboratory is complicated; the same migration inside a living organisation is complex, and the entire difference is the people — the ones who will or will not use the thing, who fear what it means for them, who agreed to it in the meeting and quietly resolved to outlast it. A strategy can be logically impeccable and politically dead on arrival. A reorganisation can be correct on the slide and sabotaged in the corridor. A new process can be elegant, efficient, and completely ignored. In each case the complicated work was done well and it made no difference, because the complexity was somewhere else entirely. It was in the people, who had not been understood.
I want to be careful here, because this is easily mistaken for a softer claim than it is. I am not saying the technical work does not matter, or that it is all really about feelings and relationships. The complicated work is necessary. Get the engineering wrong, the law wrong, the numbers wrong, and no amount of sensitivity will rescue you; the people-whisperer with a bridge that falls down is no use to anyone. The point is narrower and sharper. The competence to do the logical work — to build the system, draft the instrument, model the finances — is relatively available; you can hire it. The harder and rarer thing is to navigate the human complexity around it, and that is almost always where a hard problem actually gets stuck, and where the real risk lives. Technical failure is visible, and usually survivable. Human failure is quiet, and usually fatal.
If that is true, it changes where you look for the way through. You do not get unstuck from a complex problem by importing a better framework, because the framework does not touch the part that is actually hard. You get unstuck by understanding the people — and understanding them is not a matter of asking what they want, which they will tell you imperfectly, but of watching how they behave, listening to what is said and to what is conspicuously left unsaid, and reading the situation patiently enough to see what is really going on beneath the version that gets presented. More often than I would have believed early in my career, the answer is already there: sitting in plain sight in the situation itself, or folded into the way the people closest to the problem describe it. The work is not to invent a solution and impose it. It is to find the one that is already present, and make it usable.
So the most useful question to ask of any stuck problem is not “what is the right answer.” It is “where are the people in this, and what is this problem really about for them.” The moment a problem involves people — which is to say, the moment it becomes genuinely complex rather than merely complicated — it stops being something you can solve at, and becomes something you can only solve with. Everything else is just the clock.
Further reading: Find What’s Already There · The Wrong Tool for the Right Job