Not so wicked

Are we looking at wicked-problems in the wrong way? Does the term itself mislead us about how to work with them?

Perhaps more to the point, should we be describing them as ‘wicked’ at all? Would another term be a better fit for what’s actually going on in those contexts?

Yeah, this is another one I’ve been brewing for quite a while…

Let’s look first at the characteristics of a so-called ‘wicked-problem’, in the more generalised form summarised by Jeffrey Conklin:

  1. The problem is not understood until after the formulation of a solution.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not right or wrong.
  4. Every wicked problem is essentially novel and unique.
  5. Every solution to a wicked problem is a ‘one shot operation.’
  6. Wicked problems have no given alternative solutions.

All fair enough: we see all of those often enough in enterprise-architecture and the like. Yet notice one really important point: there’s no problematic morality there, no ‘bad behaviour’ or anything like that.

Wicked-problems aren’t ‘wicked’ as in bad, naughty, misbehaving – so why do we describe them as ‘wicked’? Seems kind of unfair, doesn’t it…?

Seems to me that the only reason why they’re called ‘wicked’ is that there’s a perception – or expectation, perhaps – that they somehow ‘should’ be ‘tame’, predictable, controllable, certain, like all of those other nice, easy, solvable problems that stay solved once we’ve solved them. You know, the ones that behave? Like they ought to?

Yeah, you’ll kind of get the voice there – a kind of whingeing, peevish complaint that world just ‘won’t play fair’, won’t do what it’s told, meld itself to match up to our assumptions and delusions. Which it doesn’t. But why is that fact somehow the world’s fault, rather than ours?


Let’s look at this another way.

Wicked-problems are often contrasted with ‘tame-problems’ – problems that can be formulated before solution, that do have a stopping-rule, that do have right-or-wrong answers, that do repeat in (roughly or exactly) the way each time, that are repeatable, and that in some cases can have whole families of repeatable right-or-wrong solutions. They could be any level of complication, perhaps, but they’re always nice, predictablewell-behaved problems. Yeah: ‘tame‘ – that is the right word.

Yet the usual opposite of ‘tame’ isn’t ‘wicked’. It’s ‘wild‘.

Exactly the same kind of contrast between a tame animal, and a wild animal.

So a better term for this would be wild-problem.

It’s wild: it doesn’t always do what we expect it to. Which, for something wild, is what we ought to expect.

It’s wild: we can perhaps understand it, by mapping its behaviour, its context and its drivers, but it still remains unpredictable – and often much larger than we are.

(Gerry Weinberg gave a great example of this in his classic book The Secrets of Consulting, where he talked about a ‘Buffalo Bridle’. Reality is that we won’t succeed if we try to put a bridle on a buffalo: it’s just too big an animal, too strong, and always too much of the wild. But you can make a buffalo go anywhere, as long as it wants to go there; and you can keep a buffalo out of anywhere, as long as it doesn’t want to go there. A Buffalo Bridle, he said, isn’t something you have, or do, it’s more something you know: it’s how you set things up so that the buffalo goes where you want it to go, and how the buffalo doesn’t go where you don’t want it to go – with no apparent force or constraint at all.)

If we look at it in SCAN terms, tame-problems sit over to the left-side of that ‘boundary of effective-certainty’; wild-problems sit over to the right:

A tame-problem is one that is predictable. Once we’ve solved it, reduced it to a formula, an algorithm or a predefined process, it stays that way.

A wild problem may have tame elements, but can never be fully reduced to ‘tame’ without breaking it – much like ‘breaking’ a horse, breaking its will, even its sense of self. The act of supposedly ‘taming’ it changes it: it’s no longer the same problem as it was in the wild.

(There’s another interesting comparison there, too: people often talk of the ‘majesty’ of a wild animal, versus often the pathos, or sadness, or even loss of soul, of the broken ‘tamed’ one. It might sometimes be useful to think of wild problems versus tame ones in much the same way…)

The other essential cross-map here would be with James P. Carse’s concept of finite versus infinite games:

Finite games have a definite beginning and ending. They are played with the goal of winning. A finite game is resolved within the context of its rules, with a winner of the contest being declared and receiving a victory. The rules exist to ensure the game is finite. …

Infinite games, on the other hand, do not have a knowable beginning or ending. They are played with the goal of continuing play and sometimes with a purpose of bringing more players into the game. An infinite game continues play, for the sake of play. The rules exist to ensure the game is infinite.

Tame-problems are like finite-games: they have a definite beginning and ending, a ‘right-or-wrong’ answer in terms of its rules or algorithms, and are always subject to – in fact defined by – those rules. Much as Carse says, the object of play with a tame-problem is to win – to achieve completion, to achieve the right answer.

Wild-problems are like infinite-games: they don’t have a knowable beginning or ending, and there is no ‘right answer’ – only a ‘better-or-worse’ answer relative to that specific context. There are sort-of-rules in play, but in practice more like ‘meta-rules’ in the same sense as metaframeworks – a kind of higher-order rules from which context-specific rules will arise dynamically for a single instance, often or usually different every time. And the object of play with a wild-problem is to learn – to discover something new, and continually discover something new and different every time we meet up with that type of problem.

Yet the distinction between ‘tame’ and ‘wild’ is recursive, and fractal: exactly as in SCAN, and exactly as with animals too, every wild-problem has tame-problem elements within it, and every tame-problem will likewise also have wild-problem elements within it – sometimes deeply-hidden, within deeply-improbable-seeming ‘special-cases’, yet somehow, somewhere always there.

In reality – and again as we can see with SCAN – tame-problems are actually always special-cases of wild-problems: wild-problems with special conditions imposed, much like fences and chains and bridles and the like that are used to ‘tame’ wild-animals. In the exact same sense that finite-games exist only as special-cases within an infinite-game.

And as Carse also says, ultimately, there is only one infinite-game, and there is only one wild-problem: life itself.

So let’s stop insulting those ‘unknown’ and ‘unsolvable’ problems by calling them ‘wicked’: they’re not wicked at all. They’re just being what they are: real problems, out in the wild, without the artificially-imposed constraints of ‘the tamed’.

Let’s treat them with respect: they’re not ‘wicked’, they’re wild.

And as we treat them with respect, maybe they’ll find it easier to treat us with respect too?

Over to you for your comments and thoughts, perhaps?

Posted in Complexity / Structure, Enterprise architecture Tagged with: , , , , , , ,
2 comments on “Not so wicked
  1. sam williams says:

    Of course ‘wicked’ can also be considered a positive term as in ‘cool’,’exciting’,”interesting”….

    I personally think ‘wild’ problems are ‘wicked’ 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *