On the complexity of change
Hey, Friend,
It’s been a while since I have written about the complexity of change. You say you didn’t even notice? What has been the problem? Yes … for me as well. For me: the usual: too many fingers in too many pies. Some days, I felt like I was kneading dough in 713 bowls in rapid succession. Hour after hour. Day after day. I got it somewhat right in one bowl, while the yeast was bubbling aggressively in all the other bowls … It looked like the more I worked, the more dough there was to knead.
What was your problem? Why didn’t you do the things consistently that you wanted to do? What has changed? What did not? Were you able to solve this problem? Over time? Instantly? Not to worry, I won’t keep bugging you. Let’s look at the problem differently.
Problem-solving has figured in my previous blog posts, but we have not really taken a step back and looked at what a problem is. Why would one want to know you ask. Well, it is often easier to address something, disentangle something, work on something, once we understand this something better. Also at an abstract level. When we abstract, we take away some features, characteristics of a complex thing or process, to be able to focus better on the ones we did not remove or ignore. Done right, the abstraction is more widely applicable, not just to the thing we abstracted from but also to similar ones. We have learned something that will help us …
Alright, what’s a problem? We want to gain an abstract understanding, therefore we are not asking: what’s the problem? Actually, it’s best to have a couple of problems. I know this might only be true for this thought experiment; but maybe it isn’t, let’s see. We take a bunch of problems and compare them to one another. What do they have in common? What is specific to only one problem? The specific features, we can probably discard. They are unlikely to be part of a problem generally; they are just part of this one. This way, we get the general idea of what a problem is. After this generalization, we can abstract. And again, this is often helpful both for encountering other problems and for dealing with the one you are facing right now; at least we know something before have to dive in deeper into the specific problem of the moment. During this further abstraction, we look at each of the general features of our set of problems, and we are working out which of the factors, components, and traits we found across our problems actually make this a problem. Which of them are essential? These are part of the essence. If it were possible to remove the these characteristics — and in our thought experiment everything is possible — then the problem is not a problem anymore. It would be something else: a gift, a nice note, or a lawnmower. We just don’t know — anything but a problem. So, in generalizing, we only take note of the features that are general to our bunch of problems; and in abstracting we focus only on the general features that are essential, in that they make each problem a problem.
You knew all this, you say. I had an inkling you might say this, and I will oblige: Let’s jump right to the highest – or is it deepest? – level of abstraction. I am sure you understand that I had to say what I wrote until now, so that we are able to dive into this abstraction without suffocating in fuzzy matter.
Abstracting, each problem has two features. (1) There are two states: one — we call it state C for Challenge — is here right now in all its glory, and state G — we call it G for goal — is longingly desired, deeply wanted, desperately needed, or harshly ordered and may exist some time in the future. (2) There is a gap or an obstacle, like a hurdle, between state C and state G. Now, that’s a problem. How are we going to solve it? Let’s do this analytically.
We look at the different parts and features of the problem and their context. What is state C like? What is its context, both in time — its history or pedigree — and space — what else is there in its environment: what entanglements, dependencies, consequences, but also what leverage and tools. And how do you envisage state G? What’s your goal? Consider that in context, again both in time and space, as well. Everything going well, you will gain a good or at least sufficient understanding of both states.
Of course, the gap or obstacle is a different one in each problem. We will leave that for another post. In a previous post, I have described simple, linear, and complex problems and have given an example of a chaotic problem. Each of these is best suited to a different approach to problem solving. In a later post, I will also allude to the difference between well-defined and ill-defined problems.
Until then, why don’t you have a look ’round, read or re-read some earlier posts. Let us know what you think.
Panta Rhei Enterprise 