Dissolution of problems in organisations (Human Complex Adaptive Systems) – part 5/5 – 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 the Systemic Problem Picture Analysis – SPPA. This blog post is also the wrap-up of the series.  SPPA is valid 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 self-caused problems, or conclude the absence of them first, with the help of SPPA, instead of directly use abductive or inductive approaches. Otherwise, we can never dissolve the problems and their root causes, by making a new systems design of our organization, with our method Systemic Organizational Systems Design – SOSD. Here is an overview picture of SPPA and SOSD in the Cynefin framework, symptoms – root causes – organizational solutions -in the Cynefin Framework , and the continually iterative approach to organizational problem-solving. The biggest changes will of course occur in the first iteration, if not the purpose of the organization changes, which normally is not the case. The important thing to remember is that we have two different levels of problem-solving, the organizational level and the product level, which was brought up in organizational level problems -in the Cynefin Framework.

The first thing to bring up is therefore the need to discuss the difference between self-caused and non-self-caused organizational problems, which has not been brought up clearly so far. The difference is vital to understand, since self-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. The past is the history of our organization, our human CAS. This history can be detangled by our SPPA, and is of great advantage when we make our organisation better, since it is all about learning from past failures in our way of working, so we do not repeat them. The systemic learning in an organisation is the most important learning to achieve, so we are not repeating context independent systemic faults, that affects the whole organisation. That these systemic faults originate from non-fulfilled organizational principles, are sometimes hard to understand and accept, and therefore sometimes an impediment for achievement of the solution.

Let us start with the difference between non-self-caused and self-caused problems. Non-self-caused problems are for example; start an initiative, a project, a new product to develop, something to produce, a new service, etc, or mistakes done, where Murphy’s law, changed prerequisites or mistakes are the reasons, i.e., the way of working is not followed. Self-caused problems are due to that the way of working is malfunctioning. This means that there are non-fulfilled organizational principles, which makes it impossible to achieve then purpose* (intention) of the organisation. These self-caused problems are what we often call symptoms and consequences, where symptoms finally generate consequences, like burned-out people, as a result of the malfunctioning system. Sometimes also human interactions (bad ones), also will follow the symptoms. This will later be discussed further.

Let us continue with a deep-dive into non-self-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-self-caused problem. This means that we need to find the context, the domain in the Cynefin framework, where we have a suitable way of working for the solution. 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 in a complex context like product development. In any kind of product development for big products, this is especially vital, and the systems design means an abductive approach with a well-reasoned hypothesis for reducing the complexity in the system, by doing parts of it. These parts later, but the sooner the better to get feedback, will integrate (synthesize) the parts together to the full system, and achieve a new system, 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 part (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 to arise.

An example of a framework for this is SOSD, as mentioned above, that properly also takes care of the context, for example product development, and where software product development is the main focus. Systems design means integration, and the integration can be seen as a prototype of the whole system. In this way, we can at the end 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, which of course will affect our way of working. We may need multiple concepts, maybe in parallel, to achieve the needed knowledge for our product. If we also have uncertainty in WHAT product to make, abductive approaches are needed in our way of working, 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, don’t worry, SOSD takes care also of this, with its guiding questions to achieve an awesome way of working :-).

Our organisation always needs to have a way of working, that starts with the portfolio, and that can take care of non-self-caused problems with the highest possible complexity level that the organisation will encounter. We have two different kinds of complexity for non-caused problems, that we call disciplinary complexity and transdisciplinary complexity, where the latter is about making a new cohesive systems design. When making new way of working for organizations or software product development we only have the latter of the two, but for hardware product development we will have both of them. Here they are:

1) Disciplinary complexity: Research for new technology, or new science** within a discipline, which is very complex and which we will call disciplinary complexity. This new knowledge needs to be acquired by multiple explorations out of well-reasoned hypothesis, preferably with different concepts in parallel, and even then, we do not know if we are going to make it at all. And if we do, we still have no clue about when we will be ready. This is also the reason why research is never part of a project, the complexity and risk are simply too high, so it is impossible to setup any valid time plan, even though planning still is possible.
Note! This step is only valid for hardware, not for software or for organizations. Why? Because there is no research needed, since we already have the needed science.

2) Transdisciplinary (integrative) complexity: Reducing this kind of complexity means to first make a systems design, that via the integration (synthesis) step, will result in a prototype, which we by the test results can acquire new knowledge from. After some iterations, with new knowledge acquired from every prototype (feeding the next prototype until we are done), a new product will finally be the result. We have reached a new cohesiveness, as was stated earlier. This step is what the evolution is doing continuously, but not on purpose, just by accident. Nature makes a top-down systems design with some accidental changes to the earlier design, and the integration will show if the new cohesiveness can make the new specie to survive or not.
Note! A fail to achieve the new cohesiveness, will end up in problems for a product or an organization, due to science for the product or the organization could not be fulfilled.

As mentioned above, non-self-caused organizational problems (non-self-caused by the way of working) can also be mistakes, since Murphy’s law is always valid, we cannot fully escape from human mistakes. But, if they happen, we try, like Toyota, to make the system a little better, where a more thorough instruction, or clearer picture, can avoid further mistakes. This means a minor update of the way of working which does not require a new systems design with SOSD, that can be made locally. But it may be the same problem for other parts, but with local solutions as well, so the whole system should be considered.

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. This makes that therefore root cause analyses to be discarded in a wink. But a root causes analysis is a deductive approach going backwards in the history, not forward, and that means effect to cause chains instead, which is the correct according to logic, since the cause already has happened. As mentioned earlier, the Cobra Effect is an apt example of an effect-cause chain, going backwards in the history, so we can 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.

To avoid going backwards only from one problem (symptom/incident), which will not reveal all the organizational root causes in the organization, we bring up many symptoms, so we can find all the organizational root causes. This means that SPPA makes the pre-work for the SOSD to become effective, when the way of working in the organization needs to be redesigned. SOSD also takes care of all the organizational principles need for the context that in turn originates from the purpose of the organization, to generate the new way of working.

It is also very important to point out, that SPPA, correct used, makes the organization proactive, instead of reactive. This means that SPPA does not need an incident to be started, like Ichikawa diagrams and 5Why?. If the organization anyway gets an incident, it means that we had an unsolved self-caused problem, or we made a mistake, that finally generated the incident. This incident, originating from the unsolved self-caused organizational problems, will look almost exactly like a mistake done, but the difference is vital to understand. If we do not understand the difference, we will not look for the root causes in the case of unsolved self-caused organizational problems. This leads to that we will repeat our mistake again and again, since we never update our malfunctioning way of working. This means that we will be reactive, and continuously cut the cost, bring in new consultants, or re-plan, but never dissolve the root causes, to avoid having these problems again. This is why we need to be careful with MECE, since it is never dissolving the root causes in our way of working, and neither the root causes originating from mistakes.

If we put all the above information about self-caused and non-self-caused problems above into one picture, it looks like this, Organizational and product level problems in Cynefin Frameworks:

Here is an explanation of how to read the (a little too busy) picture, but both the different levels are important to understand, as well as the different scenarios, where the numbers are grouped for the different scenarios.

First, we have the scenario when everything goes well :-).

  1. We start the product life cycle with an initiative within our purpose of our organization at the product level, where the purpose can be production, product development or others. This is the first step and we are using our current way of working.
  2. The initiative gives us the context and the domain of the Cynefin framework. Note that the complex domain has two different kinds of complexities to reduce, the disciplinary complexity (research of new science/technology) and the transdisciplinary complexity, where the latter is to achieve the new cohesiveness, the new synthesis for the product under development.
  3. The product moves on from where it started, and finally enters the Clear domain, which is also the domain for normal manufacturing of developed hardware products. See also this blog post series about the product value flow in the Cynefin framework.
  4. Congratulations, our new product is ready!
    .
    Now we have the scenario when everything is not perfect, which can be anything from a malfunctioning way of working, mistakes, or the always present Murphy’s law.:
    .
  5. We have some incidents with the solution in any of the different contexts, or in worst case an incident at the customer or user.
  6. We need to understand the root cause to the incident, so we start an investigation. If we have not released the product, it may be an easy Root Cause Analysis – RCA, but if the incident happens at the customer, it for sure is more difficult, probably with many different sources, due to an insufficient systems design.
  7. We may probably also take care of the incident at the customer, some handling to avoid secondary problems at the customer. But we can also have an incident with an employee that is unhealthy due to stress or negative stress. The latter is a consequence due to a bad system, which means that we need follow number 10. and do a SPPA to find the root causes to our self-caused problems, i.e., our way of working is deficient.
  8. We need to take care of the root causes to our incident within the product.
  9. Now we need to explore way forward and where the solution to our root cause(s) to our product problem can be, and we go to the right context, to find the product solution.
    .
    When we have repeatedly incidents of the same kind and/or too many incidents, there is definitely something wrong with our way of working, which means that we have self-caused organizational problems. This gives us the last scenario, where we need to move up to the Organizational level:
    .
  10. We now shift the focus from the product level to the organizational level, in order to get rid of the organizational problems we have. Note! The understanding of this shift from product to organizational level is vital, since it is a shift from fixing the product, to fixing the way of working. This means that we cannot use traditional problem-solving methods without consideration. One big reason for why this shift has not been done, is that a general root cause analysis is not to blame if there is a mistake done, which may hinder shifting over to the organizational level, which is clearly described in this blog post. SPPA is of course only blaming the system, by finding the root causes and then SOSD dissolves the root causes, in order for achieving a flourishing organization where our people thrive.
  11. We do a SPPA, see this blog post for a deep-dive into the actual method. When we are ready with our SPPA, we have found all the root causes to our organizational problem.
  12. Sadly, to say, sometimes there are too much unobjectivity in combination with politics, especially when there is an implementation road map already set to implement a method or framework. This makes it impossible, even though the root causes show the evidence of that something is deeply wrong with the new method or framework. The organization is now in the chaotic domain, and many times only a big failure can bring back their common sense, making them start to solve their organizational problems.
  13. But, if the common sense is still in the organization, the understanding that symptoms are impossible to solve, we move on to SOSD.
  14. With SOSD, see this blog post (coming in a future blog post) for a deep dive in the method, we bring the root causes found, the other organizational principles, the context, the domain and other important things as size, security and others, together and make our own awesome way of working.
  15. We implement our new way of working as soon as possible and try it on new initiatives, on already started initiatives or current product problems.
  16. If there are structural or political reasons that prohibit us from use SOSD, partly or fully, we need to use abductive approaches instead, where SenseMaker is one well-known method. Note! This point is more valid outside the scope of organizations, like society, or other human CASs.

We can see that for self-caused organizational problems, all organizational symptoms and their root causes are in the Confused domain (former Disorder domain) [2], and that the solutions only can be found in the Complex domain. The solution for organizational problems always depends on a new systems design of the way of working, in order to dissolve all the self-caused problems, the symptoms and the consequences and their root causes. Note that this means that the context of the way of working does not matter, it will still be a systems design in the complex domain. The new systems design of course needs to follow all organizational principles, not only the non-fulfilled organizational principles corresponding to the root causes. Note also that the picture showing the organizational problems, and is not showing if everything works as planned, due to it is already busy as it is. Since a way of working always can be better, incidents from problems with the product or service due to mistakes, can of course have their origins from organizational problems. Especially if the SPPA and SOSD methods have not been used, or only for a short while. See this series about problem-solving, about the product and organizational levels, and that there can be a connection between product and organizational problems, which is shown in the picture above.

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 [3]. The context in turn gives the organizational principles for a way of working, which means epistemology, how we know things, where the organization makes its best to get coherence with the ontology. The way of working itself is a constraint to avoid chaos in the organization, but where the way of working itself, in turn need to follow the constraints from science, the organisational principles. Otherwise, the organization 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 self-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 our Problem Picture Analysis when having organisational problems, since the context give us organisational principles for activities that automatically, if not fulfilled, lead to self-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 self-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-self-caused problems and the self-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-self-caused problems. Hypotheses should not be used when we have self-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) self-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, which always is the case when we try to solve symptoms (self-caused problems), where all solutions to symptoms mercilessly will lead to unintended consequences.

To be able to achieve systemic learning when having self-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” [4], as Ackoff stated it. Instead, we need to sort out the unsolvable problems that lead us back to the root causes first, to reduce the blurred parts of the total picture of problems, i.e., our system of problems. Otherwise, the risk is high to we will 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 self-caused problems, the symptoms and consequences, as well as the non-self-caused problems, that make the vocabulary hard to agree about. An understanding of Dissolution of Organizational Problems, could definitely sort this out.

Dissolution of Organizational Problems is with its focus on self-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 Organizational 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 Organizational 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 Organizational 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, self-caused or not, will be in the Cynefin framework. All problems, self-caused or non-self-caused, will have their starting point in the Confused domain. If they are non-self-caused of initiative type, it means that we directly, but after consideration of course to understand them, ontologically can put the problem to be solved in the correct domain, Clear, Complicated or Complex. Since we are starting our initiative, we so to say, starts another cycle of our way of working. For the product development that always is in the Complex domain, we need abductive techniques for reducing uncertainty and complexity, both for disciplinary complexity and transdisciplinary complexity, which are normal activities in any product development. For the way of working in an organization, there is only the transdisciplinary complexity that need to be reduced. The reason for the abductive techniques is because we in the Complex domain always need more knowledge. This means that we are setting up a hypothesis and experiment with it (maybe multiple in parallel for disciplinary complexity), will be a necessary approach. This goes both for reducing uncertainty and/or reducing the two different kinds of complexity, especially the disciplinary complexity needs parallel experiments, since the uncertainty is very high. 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. Other non-self-caused problems are for example problems that are generated from Murphy’s law, changed prerequisites, or human mistakes and are always part of the game, easily making things risky. These problems are most probably product or service problems, that can require traditional problem-solving methods like 5 why? or Ichikawa diagrams, that may be the best approach to solve these problems. But, remember that SPPA looks for all organizational problems and always need to be used first in order to detangle the mess of problems. By using SPPA we can detangle and distinguish the self-caused problems from the non-self-caused problems. To start with SPPA and then continue with the SOSD method, so we can redesign our system, giving us a radical or even disruptive better way of working.
Note that 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 an initiative is complex, which may be due to ignorance or lack of knowledge about systems design, we will instead treat the problem as ordered and most likely 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 gets more and more blurred. Before we apply a solution, we are still in the Confused domain, same as for all problems self-caused or non-self-caused, 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 only a symptom or consequence, since there is no subjective epistemology about solving symptoms and consequences, since it is impossible to solve them. This means that there will be many proposed solutions, but where no one is a solution). This is a very confused situation for any organisation, which can lead to an analysis paralysis. It can also lead to a very low level of agreement and shared understanding, which is a very negative consequence in many dysfunctional organisations. This inverse agreement/shared understanding puts us in the Confused domain, which is also brought up by Snowden [5].

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 self-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 principles 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 Organizational 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 indeed) 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 them, the root causes and find the present ones, to be sure that we do not mess things up, by ignoring looking for and solving them.

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.

From this series we can conclude the following important insights:

  • We always need to start with entangling our different organizational problems, or “mess – a system of problems”, as Dr. Russell Ackoff would have put it. Is the problem a non-self-caused organizational problem, like due to Murphy or changed prerequisites, or is it a self-caused organizational problem depending on a malfunctioning way of working to achieve the purpose of the organization, due to not fulfilling our organizational principles, i.e., the science for humans and activities?
  • The organizational problems occur, since our integration of our parts of the system to achieve our way of working gives a malfunctioning system (epistemologically wrong). This in turn depends on a deficient systems design, that do not follow our organizational principles for the context (where the way of working ontologically should be placed).
  • Organizational symptoms can never be solved, since they have already happened in our integrated, but malfunctioning system. Instead, we need to find the root causes, and find a solution to get rid of the symptoms and their root causes
  • Consequences, originates from symptoms, and can be referred to incidents. This means that we need to take care of consequences immediately, but we still need to find a solution to get rid of the symptoms and their root causes. Typical organizational consequences are the start of bad behaviour, like politics and master suppression techniques, that in turn will generate more consequences like unhealthy employee, and in worst case burned-out due to negative stress.
  • All interventions with the system (our organization) in real-time or not, which do not remove (dissolve) the symptoms and their root causes, also including all interventions for trying to solve one or many symptoms, introducing root causes, nudging the people within the system, or even doing continuous improvements (Kaizen), means sub-optimization of our system and will therefore give unintended consequences.
  • The only way to get rid of the problems within the system (no sub-optimization), is to dissolve the problems, as stated by Dr. Russell Ackoff more than three decades ago. He also added that when methods did not work, it depended on that the they were antisystemic.
  • Trying to solve one or more symptoms, or introducing new root causes, gives unintended consequences, which means sub-optimization of our system in one way of another, but we do not know how our system will be affected. Most probably to the worse, since we have not looked for the root causes, meaning we are only lucky if our system gets better.
  • This means that we do not need to try to optimize a clear part of the system, like a team within a virtual delivery structure, or a unit or silo in the line hierarchy, in order to call it sub-optimization. Instead, it means that we just need to try to solve any organizational symptom to achieve sub-optimization, i.e., it does not matter if we split our system into people, process, functions, technology or any other discipline. The same goes if we introduce root causes, we did not have from the start. This means that we are making changes to our way of working that are counterproductive, which means that we are acting antisystemic.
  • To dissolve the symptoms, consequences and their root causes, means to fulfil the science for the organizational principles, which requires a redesign. This means a new systems design of the system, our organizational way of working and the including structures, like the line hierarchy and possible virtual delivery structures.
  • Finding and dissolving the root causes will lead to a changed behaviour of our employees that assures the symptoms, as well as their consequences, will not appear again.

But 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 Organizational 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.

 

*With organizational purpose means; manufacture a product, service, develop a new product, etc., with a certain price and quality. We are not talking about the nowadays popular Purpose statement, that is only a continuation of the easy-gamed value and mission statements. In this kind of statements, behaviour, properties and core values of our employees are stated, which is more of wishful thinking, since they will only emerge from multiple interactions within the organization. Since the interactions in turn, also emerge from our way of working, one can believe that if the purpose of the organization is not fulfilled, neither will the emergent behaviour and properties of our organization be what one could wish for.

**to acquire new hypotheses in science, and try to prove them, is maybe the most complex thing that can be encountered

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

 

References:

[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-12-07.
Cynefin St David’s Day 2020 (2 of 5) – The Cynefin Co

[3] 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.”

[4] 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

[5] 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…”

 

Leave a Reply