Dissolution of problems in organisations (Complex Adaptive Systems) – part 1/2 – Introduction

Today’s blog post is the first and introductionary one in this series of two posts, and will go through what Dissolution of problems in Complex Adaptive Systems (CASs) means, with focus on our organisations. In the next and final post, a general method for being able to dissolve the problems in any organisation no matter context, will be presented, as well as the wrap-up.

There are different ways to describe a CAS, and the most common is to describe it as containing agents with interrelationships.

But, as our complexity guru Dave Snowden* has stated it; “The only thing we with certainty can say about a CAS is that any intervention with the system will have unintended consequences”, where the Hawthorn effect [1] is a good example of unintended consequences as a result of an intervention. This means that we cannot intervene with any agent in a live system, not model it nor measure on its parts, since then we will sub-optimise the system; or as Russell Ackoff always put it “all interventions with the agents are anti-systemic**”, egoistic is an apt word.

The implication of this is that any live interventions in a complex adaptive system will cause unintended consequences. Kind of tricky, right? We simply need to look for other ways of solving our organisational problems, otherwise we will easily have a walk in the dark. And that yields also abductive techniques like mapping the dispositional state and identifying adjacent possible states in the fitness landscap by drawing conclusions from observations, where SenseMaker® is one tool with big similarities to safe-to-fail experiments in parallel, see Dave Snowden’s blog posts for more information [2], [3]. Remember also that we humans for a long time have learnt that in order to reduce complexity, we need to do it by a top-down approach, by starting with the whole and divide into parts (that later are integrated and verified) in for example product development where we are doing systems design. This top-down approach also goes hand in hand with deductive techniques which also are top-down. Without organisational understanding why we need to reduce the complexity top-down in product development, implementations of both inductive or abductive techniques will be cumbersome to stop. These latter techniques, are bottom-up techniques used by many scaling frameworks; start with small parts in the bottom, imitate them and scale up, unfortunately with all complexity left.

Safe-to-fail experiments mentioned above are a common way in software development as a way for agile teams to do Continuous Improvements on for example unit performance or to improve after retrospectives, often with methods like PDCA cycles or similar. This is problematic since there is a clear difference in context between manufacturing and product development, where the PDCA cycle technique has its origin in the former. In manufacturing we have predictable relationships and the parts of the product are aggregated to be able to validate/production test/inspect the product. In product development, we instead have unpredictable interrelationships and the parts of the product are later integrated to be able to verify the product (which of course first requires a systemization with systems design, so we know that the parts will fit on the whole). As you understand this makes it cumbersome (read: impossible) to just adopt any Continuous Improvement method without any adaptation at all, not to mention trying to scale it. The context of manufacturing that is an simple context and the context of product development that is a complex context, are simply too different as mentioned above.

Let us look at problem solving in our organisations in another way.

One way to describe a system is this [4]; “A set of principles according to which something is done”. If we use this definition of a system, that means that we; 1) need to find that set of principles  2) make an organisation with our people doing their activities, using a way of working that is following these principles. First we need to start with defining our organisation.

So, what is the purpose of our organisation? For its survival, our organisation’s purpose is to fulfil the need of today’s market where the organisations is operating, for example, manufacturing, service, product development, etc.. And our organisation consist of, as our system start definition states; “People that interact to solve activities with interdependencies, for a particular purpose”, see this blog post for details. From this start organisation definition, we then have thoroughly explored the history of the market and organisations in this blog post, and how they are intertwined. This made it possible to derive our set of principles from the already existing science, where also our evolutionary prerequisites have been taken into account so we are sure that our people can follow the principles. And with our set of principles, we can build our flourishing organisation.

But, if we already have an existing way of working in our organisation, it would be neat to know how to fix the organisational way of working problems, without risk for sub-optimisation. And as stated above, trimming of silos or Agile teams are only sub-optimising, so that is together with situational assessments according to complexity theory, a very difficult and time-consuming way forward with no guaranteed results, i.e. extremely high risks.

So, if an organisation’s way of working, does not fulfil one or more of our principles, it for sure means problems within the organisation, either by not handling the activities correct, having bad structure etc., or we have principles that our people can not follow due to violation of their cognitive abilities. That means that the non-fulfilment of a principle is a root cause, which means that if we negate our principles, we have all the possible root causes to problems within the organisation. This also means that if we fix one of the root causes, we will automatically fulfil the corresponding principle, which means that we have changed our system and thereby dissolved our former organisational problems. And according to the definition [4] of a system, it means that we are redesigning the system, and not interferring with it.

This is the difference between dissolution and solution; when we dissolve something, we act systemically to get something we want (or get rid off problems), but when we solve something (the symptom) directly, we act antisystemically and try to get rid of something (the symptom) we don’t want, quoting three times Russell Ackoff [5]: “Improvement must be focused on what you want, and not on what you don’t want!”, or here [6]: “… not to get rid of what you don’t want. Defect management is not an effective mode of management.” and the final quote about using design when possible [7]: “Dissolution involves design. Solution involves research. We don’t recognize design as a way of dealing with problems, that’s superior even to research.”

Another way to put it is that dissolution means that we will redesign our existing system, to a new system to get what we want and where the problem (symptoms’ chains of the root cause(s)) no longer exist. That is coherent with the above, which states that a problem within a system cannot be isolated and solved.

We can also look at our organisation as a black box, with permeable boarders to make it resilient to customer and environmental changes, doing problem-solving of activities within its domain and the different contexts for its parts. By viewing our organisation as a black box, we do not interfer with it, which makes it easier to understand why dissolution of problems does work.
The input to our black box is our way of working built on the “principles”, what to achieve (the product or service) as a requirements specification, and our healthy people. As output comes hopefully the correct product on time, to the right cost and quality and our people still healthy.
If we change the input (the cause) for example the “principles” for the way of working, removing “Respect for people”, we will recieve another output (the effect), most probably a bad one regarding the product, apart from that we now of course also have unhealthy people, at least long-term.
Of course we do not want to make our system worse, we need to make it better, but this was only an example of the important aspect that we have not violated anything in complexity theory. Because we have not interferred with the system, not modelled it, not measured it, not needed to make a situational assessment, not sub-optimised it, just changed one of the inputs (cause) regarding what principles to follow (in this case to the worse) and waited for the output (effect).

Since we have not opened the box, it also means that we do not need to know the vocabulary within it, and especially complexity theory have a very difficult  vocabulary (and needed within its own domain of course), when we dive into its depth. But, as stated in this series of blog posts about a needed common vocabulary on the top level when we are working transdisciplinary, we do not need to know the details of the different disciplines, but we definitely need a common language to even be able to talk on the top level. Once again we can refer to Ackoff’s quote “Dissolution involves design. Solution involves research. We don’t recognize design as a way of dealing with problems, that’s superior even to research.”, since the design of our organisation is trans-disciplinary, and do not require in-depth reserach. If we do not have a common language on the top level of the domains, the risk is that even though the different disciplines’ experts are sitting in the same room, they can only work multi-disciplinary, making them more of an adviser then active taking part in the problem-solving, which is very common in traditional silo organisations. Or as Snowden puts it; “In effect we have a basic mistake, the belief that a collection of specialists is as good a generalist. ” [8].

And as we already know, there are many organisational way of working problems in today’s silo or Agile organisations that cannot be explained. But with our set of principles, we can easily judge, that the panaceas of today trying to cure symptoms, are clearly sub-optimising, trying the impossible of solving symptoms. These panaceas are anti-systemic and this is handled in this series of blog posts, referring to the great work of Dr. Ackoff. Sometimes the organisations themselves during a transformation of their way of working, understand that something else need to be done, and takes care of the real root causes and in this way takes control of their transformation. Unfortunately, many organisations do not understand that the method or framework they are transforming to are not interested in solving root causes. These frameworks states that they are context independent, so they are therefore simply only trying to solve symptoms, and sadly continue with their transformations despite big problems.

To be able to understand all these organisational symptoms, is where our Prefilled Root Cause Analysis Map comes in, see this blog post for the details. Here the structure of it can be seen:


If we negate also the purpose (the blue box at the top) of our organisation, we have the complete problem description to why an organisation is not working. And by asking why, why, why, from this problem description, the symptoms (the white ones) can be found, which finally ends up in one or more root causes (the red ones).

Now it is not only obvious that the panaceas cannot work, it is easy to see as well and now we also know what to do about it. Only acceptance of this naked truth, is the hard part. Very, very hard, to be honest.

In next blog post, we will go through the general method for dissolution of problems and wrap up this series.

C u then.

 

*at Cognitive Edge, the father of the Cynefinframework

**Do not mix anti-systemic with non-systemic. Non-systemic means that there are no side effects. A good example where there are no non-systemic cures, only anti-systemic, are medicines taken orally trying to cure a symptom in the body. This is because the body is a complex system too, which means that no symptoms in the body can be cured with any medicine without effecting parts of the body with side effects. Instead the root cause(s) to the symptoms need to be found to really cure. The same goes for our organisations and only the root cause(s) to the symptoms can be solved, since trying to solve the symptoms mean more other symptoms, that can be hard to foreseen and never directly solved either.

***remember that on the whole only continually improvements can be done, due to the synchronisation needed between the processes when the respective process’s improvements are executed at the same time, for example takt time change. The processes can (and must) themselves be continuously improved, as long as they do not affect another part, in order to be able to improve the takt time on the whole manufacturing plant, as well as to be flexible enough due to ups and downs in the number of manufactured units.

References:

[1] Snowden, Dave. Blog post. Link copied 2021-01-03.
Of effects & things – Cognitive Edge (cognitive-edge.com)

[2] Snowden, Dave. Blogg post. Link copied 2020-12-12.
The dispositional state – Cognitive Edge (cognitive-edge.com)

[3] Snowden, Dave. Blogg post. Link copied 2020-12-12.
Power laws & abductive research – Cognitive Edge (cognitive-edge.com)

[4] Lexico. System. Link copied 2021-01-03.
System | Definition of System by Oxford Dictionary on Lexico.com also meaning of System

[6] Ackoff, Russell Lincoln. Article. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/

[7] Ackoff, Russell Lincoln. Presentation film, at 10.55min.
Link copied 2018-11-21.
https://www.youtube.com/watch?v=k8g6ZoobDV4

[8] Ackoff, Russell Lincoln. Presentation fil, at 1.02.31 min.
Link copied 2018-11-15.
https://www.youtube.com/watch?v=EbLh7rZ3rhU

[9] Snowden, Dave. Blogg post. Link copied 2020-12-12.
“Its not science until I can mathematize it …” – Cognitive Edge (cognitive-edge.com)

Leave a Reply