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, no matter what kind of problems; symptoms and consequences we perceive at our work shop for problem-finding, situational assessment, mapping, or what we call it. We always need to try to find the root causes of our problems, or conclude the absence of them first, instead of directly approach abductive or inductive approaches.

The first thing to bring up is the need to discuss the difference between caused and non-caused problems, which has not been brought up so far. The difference is vital to understand, since caused problems in our organisations have a history and are context independent as well, since they originate from non-fulfilled (but “activated”) principles for the current context. This history can be detangled by a root cause analysis, and is of great advantage when we make our organisation better, since it is all about learning. The systemic learning in an organisation is the most important, so we are not repeating context independent systemic mistakes affecting the whole organisation. That these systemic mistakes originate from non- fulfilled principles, are sometimes hard to understand and accept, and therefore also achievement of the solution.

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 most often self-caused, due to that the way of working is malfunctioning, since there are non-fulfilled principles, 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 continue a deep-dive into 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, meaning that our problem to solve is 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 for example product development, that is a complex context. 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 integration, a new cohesiveness, as Alicia Juarrero [1] would have stated it. The cohesiveness is new, no matter how many of the parts that are new in the integration, 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 new knowledge necessary for the 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, where software product development is the main focus. Systems design means prototypes of the whole system, so we at the end can achieve the total of the needed new system 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 are needed 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, due to the 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, to take care of non-caused problems with the highest possible complexity level that the organisation will encounter.

Let us now deep-dive into (self-) caused problems, where we start with discussing the reason for why we need to start looking for root causes when having problems in our organisations. This is very important, since the common thinking is that we cannot do root cause analyses in complex systems, since they do not have cause and effect chains, and therefore root cause analyses are discarded in a wink. But a root causes analysis is a deductive approach going backwards in the history, and that means effect to cause chains instead, since the cause already have happened. The Cobra Effect is an apt example of an effect to cause chain, going backwards in the history, to be able to learn from it. Reducing the number of cobras was the initial thinking of the Englishmen, their purpose, which also is coherent with organisations that always have purposes.

The purpose of the organisation gives the context and therefor the ontology that the organisation is operating in; the Clear, Complicated or the Complex domain according to Cynefin model, that is an ontological framework [2]. The context in turn gives a way of working, which means epistemology, how we know things, where the organisation makes its best to get coherence with the ontology. The way of working itself is a constraint to avoid chaos in the organisation, but where the way of working itself, in turn need to follow the constraints from science, the organisational principles. Otherwise, the organisation can end up in the Chaotic domain without warning (due the ignorance of the phenomenology), since the epistemology (by mistake or ignorance) did not match the ontology. To be able to choose context, we only need to know the purpose of the organisation, but we do not need to know the size of the organisation (>0 people*). This means that no matter the size of the organisation, we need to follow the organisational principles for activities, “activated” within the context, which follows the science of logic and complexity theory. In turn this means, that if we are not fulfilling one or more of these principles, it means that we will have caused problems for ourselves; symptoms and consequences in our organisation. It also means that the only way to get rid of them, is to solve the root causes, i.e., fulfil the principles. This is the reason why we always need to start with root cause analysis when having organisational problems, since the context give us organisational principles for activities that automatically, if not fulfilled, lead to caused problems, that is directly impossible to solve. And as you understand, we have not yet touched the organisational principles for us people. When our organisation is bigger than one person and increasing, more and more of the organisational principles for us people will be “activated”, but not only depending on size, but of course also depending on the complexity of the context we are operating in. Not fulfilling one of more these principles, will of course give us also give us symptoms and consequences.

An inductive approach on the other hand, tries with few cases (many times only one) as a base, to put up a future goal, and achieve that, which means a high risk for the correlation-causation error. This means that the organisation’s current caused problems are never looked for, which in turn means high risk for not solving the root causes. An abductive approach avoids the correlation-causation error and looks at the current organisational problems; the current non-caused problems and the caused symptoms and consequences, and indirectly tries to solve them separately. This is done by putting them in the different domains, which once again means that the root causes are not looked for regarding the symptoms and consequences.

In both these approaches, measurement is vital to be able to judge the effect of changes, 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 when we have non-caused problems. Hypotheses should not be used when we have caused problems, since 1) we can and should learn about our system from the past, the history of our organisation, i.e., we already have “oblique” knowledge and 2) caused problems are symptoms and consequences that are not possible to solve. 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, a kind of nudging the system, and looks continuously (to imitate real time) at the fitness landscape as the measurement, which therefore are done on the wholeness, or at least bigger parts of the wholeness. But still, the risk for sub-optimisation is high, especially when having caused problems in product development (complex context), that originates from root causes that require a systemic top-down solution.

To be able to achieve systemic learning when having caused problems, we need to look retrospectively at improper actions done in the past, that did not follow the already known organisational principles (science), and correct them. It is frankly not enough to talk about everything as uncertain and/or complex, since that only means that we are risking to take ourselves closer to chaos instead when intervening with the system, or further increasing “a mess – a system of problems” [3], as Ackoff stated it. Instead, we need to sort out the caused problems that lead us back to the root causes first, to reduce the blurred parts of the total picture of problems, instead of increase the number of problems and making our problem picture to become really blurry, an entanglement that is even more impossible to sort out.

In order to “de-mess” the problems, we really need to be more careful about the use of expressions like uncertainty, ambiguity, complexity, volatility, etc. This, so we are not mixing them together to a mess itself, where sometimes uncertainty includes complexity or the other way around. Having different meaning for different persons seems to be common for complex or wicked problems, so here we need a common vocabulary to straight things out. Probably it is this blurred and confused picture itself, of all the caused problems, the symptoms and consequences, as well as the non-caused problems, that make the vocabulary hard to agree about. An understanding of Dissolution of Problems, could definitely sort this out.

Dissolution of problems is with its focus on caused problems, retrospectively looking at the history of the organisation and finds the root causes, the erroneous or missing actions of the past, regarding the implementation of the way of working, that have led to the current problems; the symptoms and the consequences. The root causes that are found, also include the systemic ones, which means that it is a systemic approach 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 solve all our problems, or in some cases, solve some of our problems, and in that way at least decrease the messiness in the entanglement of our problems, in the cases that we need to continue also with abductive approaches. This also means that Dissolution of problems and abductive approaches, like SenseMaker, are complementary methods, meaning it is both/and instead of either/or. But it is though important to point out, that we always need to start with Dissolution of problems to avoid a Walk in the dark, since symptoms and consequences cannot be solved, not even by abductive approaches.

Let us now discuss where our problems, caused or not, will be in the Cynefin model. All problems, caused or non-caused, will have their starting point in the Confused domain. 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, which is a normal activity in any product development. The reason for this is that we in the Complex domain always need more knowledge, where setting up a hypothesis and experiment with it (maybe multiple in parallel), will be a necessary approach, both for reducing uncertainty and/or reducing complexity. 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). So, when uncertainty is referred to, the meaning is the uncertainty of taking decisions and making ‘the right product’ that the customer wants to buy. Of course, Murphy’s law is always a part of the game, easily making things risky. When Murphy comes into the picture, we will talk about risks depending on an unknowable future**, since anything can go the wrong way, which is not a matter of context, it is universal.

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. The reason is due to the fact that the problem is caused and therefore only a symptom or consequence. This is valid even after consideration if we are trying to solve the symptoms and consequences, since subjective epistemology about solving symptoms and consequences will not help us, since it is impossible to solve symptoms and consequences. This means that there will be many proposed solutions (but, where no one is a solution), which is a very confused situation for any organisation, which in turn leads to a very low level of agreement and shared understanding, a negative consequence in many dysfunctional organisations. This inverse agreement/shared understanding puts us in the Confused domain, which is also brought up by Snowden [4].

This indirectly means that we cannot really talk about complexity and/or uncertainty, rather about ‘a mess – a system of problems’, as we stated above with reference to Ackoff. Why? Since our current situation is blurred of caused problems, it means that to directly apply a straightforward 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 misbehaviour and the use of master suppression techniques, when things do not work as expected. Sooner or later, we will understand that we have severe problems, and we will end up in the Chaotic domain.

It should be noted that it is important to understand that the organisational principles are constraints, in a positive sense, since it makes us avoid problems in our way of working. This means that if have non-fulfilled organisational principle in our way of working in the organisation, we will soon undeliberately have induced new “constraints” that we will perceive (phenomenology) as constraints, due to this non-fulfilment. These induced constraints will be an entanglement in itself, in the same way as the mess of symptoms and consequences, and they are directly unsolvable as well. This means that we need to find the root causes, to be able to detangle all symptoms and consequences and avoid induced constraints, that is originating from the root causes in our entanglement of problems. This also shows that we need to start with Dissolution of problems, also before we start with mapping of the constraints. Not only because new “constraints” are induced, but most of all since the organisational principles (constraints) we have “violated”, cannot be known until we have found them, and these constraints we need to follow to avoid our mess. We simply need to start to look for, and continually look for, root causes and find the present ones, to be sure that we do not mess things up, by ignoring looking for and solving them. This ignorance often means real-time interventions on the symptoms and consequences, which only will lead to unintended consequences.

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, as well as 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.

Next “chapter” according to the reading proposal tree is the blog post Finding the root causes to queues, but for a bunch of examples of what is happening when we neglect our problems and the explanation why, see the blog post series Are you stuck in a rabbit hole…?, where many of your different organisational problems most probably can be found ;-).

C u soon again.


*For example, the planning of all activities can be done for only one person and means a completely serial time plan, no matter context, but when the organisation is growing, the planning will have more and more parallel activities. The planning is needed in order to achieve structure and is a kind of constraint, which in turn helps to avoid chaos.

**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).



[1] Juarrero, Alicia. Presentation from the Lean WX conference, April 2015.
Constraints that Enable Innovation – Alicia Juarrero on Vimeo

[2] Snowden, Dave. Blog post (comment field). Link copied 2021-08-15.
Separated by a common language? – Cognitive Edge (cognitive-edge.com)
“…while Cynefin is an ontological framework that allows radically different conversations mediated by epistemology and phenomenology.”

[3] Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 2.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995.
Link copied 2018-10-27. At 13:20.
Russell Ackoff – Systems-Based Improvement, Pt 2 – YouTube

[4] Snowden, Dave. Blog post (comment field). Link copied 2021-08-15.
Separated by a common language? – Cognitive Edge (cognitive-edge.com)
“…I’ve seen many cases where a perception of agreement and shared understanding is in practice dis-order and therefore confused…”