Complex vs. Complicated: The Diagnosis You Can't Skip

Get this call wrong, and every structure you pick afterward works against the room, not for it.

The Call You Make Before Anything Else

Most failures I've watched didn't come from a bad structure. They came from a bad diagnosis.

A complicated problem has an answer that already exists. Somewhere, an expert knows it. Your job is to go find it.

A complex problem doesn't work that way. The answer isn't hiding, waiting to be found. It emerges while you work, and it keeps changing as you go.

Here's the test I use: can you describe "done" before you start? For a complicated problem, yes, the bridge stands, the software runs. For a complex one, no. You only know it worked once it's behind you. And two organizations with the "same" problem can end up needing two completely different answers.

A merger. A culture shift. A staffing crisis. None of these are puzzles waiting for a solution. They're situations you maneuver through.

If you see a group tackle one of these with a project plan and a Gantt chart, you're watching a category error happen in real time. The Agreement-Certainty Matrix exists so a group can catch that themselves, not so you can tell them.

What the Diagnosis Buys You

Once you know a problem is complex, the rest follows.

You don't converge before you diverge. The answer isn't sitting in one head, waiting to be extracted; it has to come out of perspectives colliding.

You don't plan a straight line from A to B. You move in small, safe steps, with room to adjust as you go.

You bring in more difference on purpose. Look at a complex problem through one lens only, and half of it stays invisible.

And you measure progress by the buy-in the group actually feels, not by how fast they agree. Quick consensus tells you almost nothing about what survives contact with Monday morning.

The diagnosis drives the design, structure by structure.

Matching the Structure to the Problem

A few situations I run into constantly.

The group is facing something complex and reaches for the first solution too fast. Slow the convergence down on purpose. 1-2-4-All or TRIZ protect the range of perspectives from collapsing onto whoever talks loudest.

The group is stuck chasing the perfect plan for a situation that can't hold one. Shift them toward safe-to-try. 15% Solutions, or thinking in pilots instead of rollouts.

Nobody's sure yet what kind of problem this even is. Then sorting comes first, before anything else.

The structure is never the starting point. The diagnosis is, the structure just follows from it.

The Disguise

Here's what makes complex problems dangerous: they dress up as complicated ones.

A leadership team tells you, "we need to redesign how we run meetings," as if it's a design job with a clean answer waiting. They expect you to walk in with that answer.

The real assignment is almost always something bigger: power, trust, habit. Things you can't redraw on a whiteboard. You can only shift them together, with the people who hold them.

Take the assignment exactly as it's handed to you, and you'll deliver a tidy plan that changes nothing.

The skill is spotting the complex problem hiding inside the complicated request, and having the nerve to open that conversation before you touch the design.

Why This Still Gets Me

Complexity isn't a philosophy you bolt on to sound serious. It's the difference between a design that fits the shape of the problem and one that fights it.

After all these years, this is still what keeps me in the room: watching self-organization happen, live, in one room, in one afternoon, with real people. That's the Cynefin-adjacent thinking behind Liberating Structures, in practice rather than on paper.

It only works if you saw the problem clearly first.

How do you tell a complex question from a complicated one during an intake, and when did you get it wrong, in hindsight?