I spent a couple of days this week working with a leadership team on the topic of decision-making in adversity and the session kept returning to the same territory – the importance of diagnosing the kind of challenge that is in front of you. We had a particularly interesting debate around the difference between complicated and complex problems, as captured in Dave Snowden’s Cynefin framework (a perennial favourite of mine), and set out similarly as the three types of problem in the world:
Clear or ‘simple’ problems are known knowns. You’ve been there before, understand what to do, and so this is the domain of checklists and best practice. Follow the recipe and you can reliably get the same result. Complicated problems are like sending a rocket to the moon – harder to solve, way more variables, requiring analysis and expertise across different fields, but a right answer does exist and solving it once meaningfully increases your chances of doing it again. Complex scenarios or challenges have many moving parts that may be sitting in an environment which itself is changing constantly. Like raising a child, doing it once provides experience but no guarantee of success with the second. Patterns emerge and shift, meaning that the answer is not knowable in advance, only in hindsight. So emergent methods are the only response. In my books, I wrote a lot about the need to apply the right ways of working to the right context – standard operating procedures for clear contexts, linear and milestone-driven methods for complicated domains, and working in adaptive cycles for complexity.
The difference between complicated and complex is often where it’s easy to lose the nuance. Snowden has a neat analogy. A commercial jet sits in the complicated domain since it is composed of millions of discrete parts but is also understandable and predictable through expert analysis. A rainforest is complex because it is an ecosystem in constant flux where the whole is radically more than the sum of its parts. If a part breaks on a jet airliner, it can be taken apart, a linear cause and effect established by an expert, and put back together again to replicate its previous state. But you can’t take a rainforest apart to fix it because everything is interconnected, cause and effect are only knowable in hindsight, and the very act of intervening changes the system itself.
In the session I ended up telling my favourite story about what a genuinely complex problem looks like. Designed by Norman Foster and engineered by Arup, the Millennium Bridge opened to great fanfare in June 2000. On the opening day around 90,000 people crossed the bridge and there were as many as 2,000 people on it at the same time. The bridge started to wobble, swaying disconcertingly up to 70mm, and after two days it was closed again. The engineering of the bridge was not inherently wrong, and the swaying was almost impossible to predict. There was no design code for it because most bridges are either too stiff to sway at walking pace or never carry a big enough crowd. And it seemed like the act of that many people crossing the bridge was what was producing the instability. After £5 million worth of dampers were installed the bridge reopened after almost two years and Arup tested it by walking 2,000 people across it in early 2002. The accepted explanation for the wobbling was that pedestrians unconsciously fell into step as they walked across the bridge. This was widely agreed upon for twenty years, until it was revised in 2021 by researchers who argued that the walking synchronisation was a consequence of the wobbling rather than its cause. Visibility improves with hindsight but it still took two decades to settle on an explanation which, even now, is still arguable.
AI can easily make complex problems present as complicated ones. Ask AI about a complicated challenge and it will decompose the problem, analyse, and form a recommendation. Ask AI about a complex challenge and it will do exactly the same, because decomposition and pattern-recombination from previous cases is what AI does. The two problems require a very different approach but the complex domain output is indistinguishable from the complicated domain output. You get a confident, well-structured recommendation either way, with nothing to tell you that your diagnosis was wrong.
So diagnosis needs to combine with technique, each domain suiting a different way of working with AI. Simple and clear contexts are obvious candidates for automation. Automation can effectively freeze a process at scale so the real work should go into checking that the workflow you’re encoding is the best one available rather than one that has just been there for a long time.
AI can be really strong in complicated domains. It’s very adept at breaking a problem down into constituent parts, supporting good analysis, checking your analysis using a method or framework you hadn’t thought of, unearthing assumptions and providing a route to expertise and existing solutions that you don’t have easy access to. In Cynefin this is sense, analyse, respond.
Complex scenarios need something different because the answer is not sat there waiting to be found. So when using AI the job is to hold the options open to prevent premature convergence, which means generating diverse perspectives and rival diagnoses to explore rather than closing in on a single answer. It means using AI to argue each one properly and asking what would need to be true for this to become complicated. A thin answer here probably means you’re going in the wrong direction. And it means deciding in advance what would count as evidence because, as the wobbly bridge showed, feedback in complex systems is slow, often ambiguous, and easy to read as confirmation of what you already think. Cynefin’s answer to complex scenarios is to probe, sense, respond. AI can dramatically reduce the time and costs involved with running small probes in parallel, but navigating complexity is about learning fast, not immediately landing on an answer.
Few leaders, it seems, pause to consider what domain they might be operating in, and so the wrong methods get applied in the wrong context leading to poor outcomes. But it’s worth considering that a single project can also incorporate multiple domains. The company I was working with this week was a large, engineering-based business and here (like many organisational contexts) a project may well have a complicated, technical core inside a complex commercial and human system. Rather than seeing the whole thing as sitting in one domain, this requires the project to be broken down into workstreams, and a plan with different levels of detail and different cadences of review for each workstream. This workstream split also enables you to understand the potential role that AI can play for each context and each workstream, and define some much clearer expectations and ground rules for how AI can be applied in the best way to support project outcomes.
All of this can read like it’s a solo act but in a business diagnosis has to be shared. Yet it rarely is. AI can make this worse because everyone can generate their own, confident answer without diagnosis ever being a part of the discussion. Running the diagnosis openly first, and convening around the domains you’re working with, creates the common ground you need to address the challenge with the right methodology. Once the bridge started swaying Arup knew that they had a complex problem on their hands but they could only establish what happened after the fact, and it still took twenty years. In complex scenarios the diagnosis is available before the answer is.
A version of this post appeared on my weekly Substack of AI and digital trends, and transformation insights. To join our community of over thirteen thousand subscribers you can sign up to that here.
To get posts like this delivered straight to your inbox, drop your email into the box below.
Leave a Reply