Why is ‘nothing ever simple’? I find myself saying it often, frequently to my children, but I don’t believe it. Some stuff is definitely simple – we’ve done it before, we know how it works, we can do it again. Easy.
So why is ‘nothing is ever simple’ such a popular phrase? I would hypothesise that it’s because a whole load less stuff is as simple as we first think. The stuff that really is simple we don’t notice. Because it’s simple. The stuff that we think is simple, but isn’t, gets us thinking ‘why is nothing simple?’ – usually with a few descriptors around the edges too.
I’ve just re-read that last paragraph. I think it works.
The ordered world is either obvious (it used to be called simple) or complicated. Obvious things are the ones where best practice is found, the checklist is employed: they are tightly constrained and repeatable. The complicated domain is still governed by constraints but requires expertise to know which of perhaps several good practices should be employed. I can’t change my car’s gearbox, but I know a man who can.
The unordered world is divided into complex and chaotic domains. Things in the complex space are enabled by constraints rather than governed by them and practice emerges through trying things out because we can’t predict outcomes. The chaos domain is characterised by a lack of constraints, cause and effect is unclear but innovation and novel practice abounds.
Those last two paragraphs are a crazy-fast dip into the Cynefin framework (and doesn’t do it justice) but serve to introduce the purpose of this post.. At last.
I observe a lot of mis-understandings and conflicting viewpoints between individuals both within teams and across organisations. Sometimes the underlying cause of the mis-communication is that the parties involved believe the item under discussion is in a different domain. For example, if I think the situation is complicated I could be very confused and frustrated if you are approaching the same situation as complex. In the software world the project manager asking the developer when the bug will be fixed is (probably) treating the bug-fix as complicated but predictable. The developer, on the other hand, is faced with an un-reproducible error report, badly written. She can’t get access to the reporter and can’t get her own setup to behave in the same way. Her approach is to experiment, but right now the outcome is un-predictable – at least in terms of timescale. She’s faced with a complex situation.
So pay attention to how constraints are worded or written – it may just give you a clue to the perceived complexity of what is constrained, which in turn might explain the behaviour you observe. And, of course, that works both ways.
And the bug I mentioned? It absolutely has to be fixed by Friday.