What I mean is that if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve certainly learned something about it yourself. The teacher usually learns more than the pupil. Isn’t that true? – Douglas Adams, Dirk Gently’s Holistic Detective Agency
Most of the issues we run into with our lives can be traced back to one thing – we don’t look at all the factors that matter in a situation.
And that’s because it’s normal to look at the presenting problem – the thing that’s most obviously wrong.
For example, if someone makes a mistake at work a common reaction is to create a rule that aims to prevent that happening again.
Let’s say a person has to do a number of checks and some of them get missed.
One way to help is to create a checklist, something they tick off as they go along.
Now, what you’ll find over time is that someone will come up with the bright idea of adding signature boxes to the bottom of your checklist.
What that aims to do is add accountability – the person doing it signs it and then a person who double checks it signs it too – a sign of quality control.
What this always does is reduce quality because now you have two people, each of which is tempted to believe the other will pick up on errors and who both get more focused on whether they have followed a checking process than whether the right thing is being done.
One of the things people need to understand is that you cannot “inspect quality” into a process – you have to build quality in right from the beginning and a checklist is a tool to help, not a weapon for allocating blame.
But what is this quality thing anyway?
Quality is something that emerges from doing something well for someone else – it’s the experience they have.
So that’s something weird, isn’t it.
When you say a Rolex is a quality product, do you mean that every piece in there is machined to a particular tolerance or that the glass is a certain kind of material?
That’s one take on quality – an adherence to specifications – but that’s not what people think when they wear a premium watch – no one really oohs and aahs over the micrometer measurements of the product.
But those micrometer measurements matter too – without them you have something that feels cheap and poorly put together and you can tell the absence of quality.
Now, in the physical world of products, because what you use and how well it all fits together contributes to that feeling of quality, we associate quality with standards and tolerances.
So then when you come to services and concepts and dreams it’s tempting to use the same approach – we can improve quality through standardization.
For example, you do things like having a customer relationship management (CRM) system, set KPIs and targets, have service level agreements – which result in rules like we will answer the phone in five minutes or less.
But is that what you want when you call up customer services – a short wait – or do you want your problem solved?
Maybe the person who talks to you gets to you in two minutes, they update the CRM with all the information and create all the flows that are needed by the process – they follow all their standards and rules exactly – but if your problem isn’t sorted you still feel that it’s low quality work.
That’s one of the frustrations people have with government, where the overriding concern is about process rather than result – where people spend huge amounts of time inspecting and checking and measuring and reporting and scoring rather than actually doing the job well.
And that’s because they can’t see the big picture – the whole thing – because we’re trained not to.
We’re taught that if you can’t measure it you can’t manage it, so we focus on the things we can measure and completely miss the things that matter.
Maybe what we should be taught is that if you can’t model it, then you can’t understand it – and that’s why you can’t manage it.
Being able to model something is what matters, and some of the things in your model can be measured and that’s going to help you but other things can’t and you need to be able to tell the difference and live with the implications.
But how do you create a model that works for real-world situations?
Well, one way is to start using the word “system” in the right way, because it means something very different to different people.
Some systems might be seen as real and physical – like your IT system or your transportation system.
Others are more amorphous and complex – like the economic system or value system or healthcare system.
The crossover from real and measurable to conceptual and abstract is not always obvious but it doesn’t help that we use the word “system” for everything that we could possibly want to manage.
One solution is to use the word “holon” – a word that has been put forward for “the abstract concept of a whole which might then be used to understand or create real-world systems”
So, we use the word system to mean something in the real world, something we can point to and touch – while we use holons for concepts that we hold in our minds.
So what’s this holon thing then?
In “Soft Systems Methodology in Action” Peter Checkland suggests using the word “holon” for the “abstract idea of a whole having emergent properties, a layered structure and processes of communication and control which in principle enable it to survive in a changing environment.”
The basic idea that Checkland puts forward is this – we have these abstract concepts in our heads when we think about the world and the big issue we face is talking about these abstract things with others.
We can use holons to make those abstract concepts visible, and then by comparing your abstract concept with my abstract concept we can understand each other better and have a conversation about how we can live together.
The process of modeling a holon is shown in the image above – you have activities that are connected together – and there is communication and control between them.
These activities together make a whole.
And from that whole you have something that emerges that is not in any of the parts but happens because of how those parts work together.
A holon is something you can create pretty quickly – it’s there to help you have a discussion about what’s in your head.
How would you use this in practice?
I don’t know much about politics, so let’s ask Wikipedia what Republicans and Democrats are – what makes them them and see if we can quickly construct holons to compare and contrast the two.
Here are two holons – first a model of what republicans believe.
and then a model of what democrats believe.
Now, these are quick models, one interpretation of the words that are in the Wikipedia articles – they are selective and partial and reflect what seemed most obvious to me – the person constructing the model.
But now, instead of shouting at me from your point of view – whichever party you support – you can look at the two holons and correct what you see as errors.
Should the activities or connections be different, are there things missing?
Eventually, there could be a holon that you are happy with which, for you, allows the concept of being a Democrat or Republican to emerge
And then there are two holons which you can compare and discuss and use to understand what’s different about the two and where there might be room for discussion and where there is none.
Now, of course, there are layers under each activity, and that’s the idea of hierarchy, you can create more holons that express each of those nested ideas and that’s also the a feature of inquiry into real-world situations – models and emergence exist at different levels each building on the next.
You need to get your head around the idea that a holon is simply a way to model what a person thinks.
And where it matters is that if you listen to someone and then build a holon of what they think which they agree captures what they have said you’ve now created a useful model of that discussion.
That’s something you can build on as you move to the next step of whatever you’re working on – the project or product or process or business you’re trying to build.
So the next thing we should look at is bringing it all together, making sense of it all.
Over a series of posts we’ve looked at listening, tools and methods to do it better, and some techniques to help us model situations.
So what have we learned, what do we think and what are we going to do next.
We need to tackle some of these ideas in the next few posts.