Dissolution of problems in organisations (Human Complex Adaptive Systems) – part 4/4 – why dissolution and wrap-up

Today’s blog post is the last blog post in this series and will deepen the discussion why we always must start with Dissolution of problems in human Complex Adaptive Systems, such as organisations. And it is no matter what kind of symptoms and consequences we perceive at our work shop, we always need to try to find the root causes, instead of directly approach abductive or inductive approaches. But first we need to discuss the difference between caused and non-caused problems, that has not been brought up so far. The difference is vital, since caused problems have a history and are context independent as well. The history is of great advantage when we make our organisation better, since it is all about learning, where systemic learning is the most important, but also the hardest one to understand, accept and achieve.

Let us start with the difference between non-caused and caused problems. Non-caused problems are for example; start an initiative, a project, a new product to develop, something to produce, a new service, etc. Caused problems are often self-caused, due to that the way of working is malfunctioning and therefore does not achieve the purpose (intention) of the organisation. These problems are what we often call symptoms and consequences, where consequences will, after human interactions (bad ones), follow the symptoms, which later will be discussed further. Let us start with non-caused problems.


When starting an initiative or project as the problem, it is business as usual, since we have not (yet) caused ourselves any problems, our problem to solve is therefore a non-caused problem. A top-down approach with planning and a systems design that takes care of the wholeness, are always needed and can be taken care of directly as the first step. In any kind of product development for big products, this is especially vital, and the systems design means an abductive approach with a hypothesis for reducing the complexity in the system, by doing parts of it. This means that we later will integrate the parts together to the full system, and achieve a new cohesiveness, as Juarrero would have stated it. The cohesiveness is new, no matter how many of the parts that are new, with for example new innovations in the respective discipline. The more parts that have changed, the harder it most probably will be to achieve this new cohesiveness, and the faster feedback we need. We may also need multiple concepts and use integrational prototypes, in order to get the necessary cohesiveness.


An example of a framework for this is Test-Driven Systems Design (TDSD), that properly also takes care of the context for the product development. Systems design means prototypes so we at the end can achieve the total of the needed new knowledge, leading to that our parts will integrate to a unified and well-functioning whole. With very high complexity in HOW to make our product, the more difficult it will be. Then we may need multiple concepts, maybe in parallel, to achieve the needed knowledge. If we also have uncertainty in WHAT product to make, abductive approaches can once again be used also need to take care about this, since we can only anticipate when having uncertainty, but not predict. And here is where it starts to get really tricky for bigger organisations making bigger products, with these two different feedback loops for uncertainty and complexity respectively. But, do not worry, TDSD takes care also of this.
Note! Our organisation always needs to have a way of working, that starts with the portfolio, that can take care of non-caused problems with the highest complexity level of possible that the organisation will encounter.

An inductive approach, tries with few cases (many times only one) as a base, to put up a future goal, and achieve that. This means that the organisation’s current problems are never looked for, which means high risk for not solving the root causes. An abductive approach looks at the current problems, the current symptoms and consequences, and indirectly tries to solve them separately, by putting them in the different domains.

In both these cases, measurement is vital to be able to judge the effect, since both of them uses hypotheses, a big one for the inductive approaches or many small ones for the abductive approaches, trying to make the organisation better. But hypotheses are always hypotheses, and should only be used for uncertainty about the future for non-caused problems and when we do not have the knowledge. Hypotheses should not be used when we have self-caused problems, since then we can and should learn about our system from the past, i.e. we already have oblique knowledge. The measurements done for the inductive approaches are also mostly done on the parts, to achieve fast feedback, but measurements done on the parts are always a strongly sub-optimising measurement, not giving any information about the behaviour and results of the total system. Many hypotheses regarding improvements done when using abductive approaches are only done on parts, often on teams. This only results in a sub-optimising measurement as for inductive approaches, since aggregation of optimised parts in most cases will not optimise the whole system, especially not when complexity comes into the picture. The abductive approach used in SenseMaker is different and looks continuously at the fitness landscape as the measurement, which are then done on the wholeness.

To be able to achieve systemic learning, we need to look retrospectively at improper actions done in the past, that did not follow the already known science, and correct them. It is frankly not enough to talk about everything as uncertain and complex, since that only means that we are risking to take ourselves closer to chaos instead, or a mess – as system of problems, as Ackoff would have stated it. Instead, we need to sort out the problems that lead us back to the root causes first, to reduce the blurred parts of the total picture of (self-)caused problems, instead of increase our picture to become really blurry, an entanglement that is impossible to sort out.

Dissolution of problems is a deductive approach that is focusing on (self-)caused problems. This means that it retrospectively finds the root causes, the faulty or missing actions and interactions of the past, that led to the current problems. The root causes that are found, also include the systemic ones, which means that it is a top-down logic approach (but reversed) that takes the whole system into account. With this said, it is therefore always important to start with the Dissolution of problems step, in order to learn from our mistakes (top-down) in the past, to achieve a true systemic learning. In this way we can decrease the messiness in the entanglement of our problems, in the cases that we need to continue also with abductive approaches to decrease the uncertainty.

Let us now discuss where our problems, caused or not, will be in the Cynefin model. Caused or not they will be in the Confused domain in the Cynefin model. If they are non-caused, it means that we directly, but after consideration of course to understand them, ontologically can put the problem to be solved in the right domain, Clear, Complicated or Complex.  If we talk about non-caused problems for the Complex domain, we need abductive techniques for reducing uncertainty and complexity. The reason for that is that we in the Complex domain always need more knowledge, where setting up a hypothesis and experiment with it, will be a necessary approach, both for reducing uncertainty and reducing complexity. But where we of course need to have the wholeness in control from a top-down perspective, to avoid sub-optimisation, in both cases. Fast feedback is important to avoid premature convergence, where it is important to understand that there are two different feedback loops, one for ‘the right product’ (uncertainty) and one for ‘the product right’ (complexity). Of course, Murphy’s law is always a part of the game, easily making things uncertain. When uncertainty is referred to, the meaning is the uncertainty of making ‘the right product’ that the customer wants to buy. When Murphy comes into the picture, we will talk about risks depending on an unknown future*, since anything can go the wrong way, which is not a matter of context, it is universal. Experiments in parallel are also useful, when appropriate, to get parallel feedback.

If we neglect that a non-caused problem is complex, which may be due to ignorance or lack of knowledge about systems design, we will instead treat the problem as ordered and use solutions for the ordered domains instead. Most probably we will then without consideration directly divide the problem into parts, and solve each part by itself, just as if our solution was only a gigantic jigsaw puzzle, where the pieces already fit, or like the aggregation of a car at a manufacturing plant. After a while we will start to see the symptoms and consequences of our ignorance, which means that the situation is more and more blurred. Before we apply a solution, we are still in the Confused domain, same as for non-caused problems, but with the big difference that this time we cannot directly choose the context where we will find the solution to our problem(s), i.e. the Clear, Complicated or Complex domain. This is valid even after consideration, since subjective epistemology about solving symptoms and consequences will not help us, since it is impossible to solve symptoms and consequences. This indirectly means that we cannot really talk about complexity or uncertainty, rather about ‘a mess – a system of problems’, as Ackoff put it. Why? Since our current situation is blurred of self-caused problems, it means that to directly apply an inductive or an abductive approach with multiple safe-fail experiments, is a clear sub-optimal approach, anti-systemic as Ackoff put it. If we not take actions against the increasing number of symptoms, we will over time also get consequences due to human behaviour when things do not work as expected. Sooner or later, we will end up in the Chaotic domain.

If we continue our reasoning about systems design above, that is needed for reducing the complexity when making the parts of a system (especially big systems), that means that an ignorance of the systems design will over time generate tremendous number of symptoms and consequences. If we could solve these symptoms and consequences directly instead, it would mean that sub-optimisation did not exist. This in turn would also mean that in this specific case we could also deduce that we then never need to make a systems design, instead we could just make smaller and smaller parts. But, since sub-optimisation exist, we can instead deduce that the only solution to the symptoms and consequences of an ignored systems design, is to solve their root causes, i.e. to make the needed systems design that was ignored at the first place.

The argumentation above would also lead to that we do not need to take context into account, meaning that we always can divide the system into smaller parts and solve them separately. This means that a solution to any problem always is context independent (context-free), since the parts are not interrelated, they can then always be aggregated. That in turn would lead to that neither sub-optimisation nor scaling problems exist, which is contradictory to existing complexity theory stating that we cannot divide a complex (adaptive) system into parts and optimise the parts individually to get an optimum for the total system.

Nothing is seldom perfect and everything can become better and our organisation also needs to be resilient towards future (self-)caused problems and an always changing world, which means that we continually need to look for our organisational problems. And we need to do it with curiosity and open eyes, discuss the problems and get rid of them by finding suitable solutions to new root causes or where solutions of the root causes may not be enough anymore, which is easily happening when the world is on constant change. But, with this systematic and easy to use Dissolution of Problems, this is never an issue!

That was all for this series.

C u soon again.


*Uncertainty regarding the future is valid for every context, and many of the risks from a risk assessment can be referred to that, with some probability, which require some kind of back-up plan for at least the ‘highest’ risks, since Murphy always is present. These risks can for example be; people get long-time sick, key resources quit, tools do not work as expected, machines break, lack of knowledge, too few resources, etc. These risks need to be differentiated from the risks that yields the complexity of the product made (the product right) or the uncertainty of if the customer wants to buy the product or service (the right product).