You can’t tame Wickedness by presenting a binary choice
Thanks to Jean Boulton for the title of this message. She has very kindly agreed to come and talk to us on the 28th July, so please do put that in your diaries.
In my last message, when I joked about being in or out of the E.U., I promised that this wasn’t a political group or communication, and it isn’t. However, I can’t not comment on the referendum on Thursday and the events that have unfolded since though. From a systems perspective that is.
I’ve been particularly struck by the “wickedness” of the problems we had to grapple with in making our “in” or “out” decisions. The problems we have been trying to solve with the simple binary choice we were given of “in” or “out” are highly wicked in nature and encompass a huge amount of Volatility, Uncertainty, Complexity and Ambiguity (VUCA). If we remind ourselves of the defining characteristics of a “wicked problem”, I think that we can recognise all of them in the choice we were asked to make last Thursday.
- The problem is not understood until after the formulation of a solution.
- Wicked problems have no stopping rule.
- Solutions to wicked problems are not right or wrong.
- Every wicked problem is essentially novel and unique.
- Every solution to a wicked problem is a ‘one shot operation.’
- Wicked problems have no given alternative solutions.
I suppose this is why referenda are not a common feature in our decision making. This one certainly seems to have been far too simplistic a choice to address the deeply complex social and economic challenges we face and this binary, linear choice around a supposedly singular issue was created to address.
And now that a “right” or “wrong” decision has been made, what are we finding? This simplistic approach to decision making has led to a situation where we have far more Volatility, Uncertainty, Complexity and Ambiguity through unintended consequences than we did before we made it. That’s the nature of “wicked problems”. Let’s now hope that a more systemic approach to dealing with the plethora of amplified and interlaced wicked problems we now face can be taken.
SCiO do VSM very well
So, back to normal service. On Saturday, I went to London for a SCiO organised Viable System Model (VSM) training workshop. It was excellent and I’m very glad I went. I had found VSM slightly impenetrable and esoterically theoretical when I looked at it previously. I was wrong to find it that way though. It’s actually deeply practical and was explained in a way that made it immediately accessible and useable. I’ll be very happy to talk to anyone about it and share my experiences if you would like. I like my coffee black and without sugar.
Drawing a boundary is not easy
Thursday’s STA session was a productive one. We reviewed our context diagram and discussed where we should redraw the boundary for our System of Interest. This prompted interesting discussions and it became clear that choosing what should be in and what should be out makes a significant difference to the “purpose” of the system and how we view it.
So, even though this is just an exercise and we are not trying to solve any real problem, it became apparent that when we do begin to use these approaches for designing and modifying services, we will need to pay careful attention to where we decide to draw our system boundary. Serious thought about the implications of what we put inside and what we leave outside will be needed. I think this is a helpful approach.
Thinking about how to think
Indeed, the interesting and powerful thing about this is that we are now thinking about how to think about problems. We have inserted an extra step into our thought process and rather than just diving into trying to solve a problem, we are carefully thinking about what the problem is and how we should view it. That can’t be a bad thing.
As last week’s note suggested, now we have defined what our system is, we will now return to defining its purpose. We are going to use a more thorough approach to doing so than simply using the 18 word statement as we have so far.
We are going to use an Affinity Diagram to define the functional requirements (or sub-purposes) of the system and then use a Tree Diagram to structure them. I’ve attached Stuart Burge’s papers on those diagrams for you.
Happily, our fellow Systems Thinker, Julian, has facilitated the building of Affinity Diagrams previously and has kindly offered to facilitate Thursday’s session. He’s very enthusiastic about the usefulness of this diagram and it promises to be good session. We are going to follow the “in silence” version of the approach, so if you are going to be there, do please read the briefing paper in advance and also try to arrive on time as I think we will try to cover a lot of ground in the hour.
I hope to see you there.