Today’s blog post is the last blog post in this series and will deepen the discussion even more regarding WHY we always must start with the Systemic Problem Picture Analysis – SPPA, and then continue with Systemic Organizational Systems Design – SOSD.
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 problems (built-in or normal 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, organizational level problems -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.
The first thing to bring up is therefore the need to discuss the difference between built-in and normal organizational problems, which has not been brought up clearly so far. The difference is vital to understand, since built-in problems in our organisations originate from non-fulfilled (but “activated”) principles for the current context, and are built into our way of working. 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 normal and built-in problems. Normal problems are for example; mistakes done, where Murphy’s law, changed prerequisites or mistakes are the reasons, i.e., the way of working is not followed. Built-in 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 the purpose* (intention) of the organisation. These built-in 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 activities first. When starting an initiative or project as the problem, it is business as usual. 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 will be to achieve this new cohesiveness, and the faster feedback we need. To achieve fast feedback on the systems design and architecture is where integrational prototypes are appropriate to get new knowledge necessary for the cohesiveness to arise. Juarrero also mentions multiple concepts in parallel, a Lean concept, which together with integrational system skeleton prototypes for products, increases the chances for success. Integrational system skeleton prototypes and this Lean concept with multiple concepts are important parts when making big software systems, covered in the blog post series about TDSD.
Remember though the difference between products and organisations, since our organization is only one, meaning that multiple concepts in parallel is an impossible way to go, and to have parallel parts will not show anything about the wholeness. But, as we can see in the blog post about SOSD, the needed top-down organizational systems design needed for any context, when achieving a new way of working in order to fulfil the organizational principles, is rather straightforward. For complex contexts like system and product development, where all the organizational principles are activated, the solution frame is considerably decreased on the wholeness. This means indirectly that the root causes to problems, when having a flourishing way of working, will be at the team level, inducing those multiple concepts are possible, i.e., the hypothesis and the solutions are becoming more of Kaizen events within the teams.
An example of a method for this is SOSD for making a new systems design to be able to achieve the new way of working in the organisation. As mentioned above, it 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 the activities with the highest possible complexity level that the organisation will encounter. For products and systems, we have two different kinds of complexity for activities, that we call disciplinary complexity and transdisciplinary complexity. The former one is about research, and the latter is about making a completely new cohesive systems design, where we for software systems does not have the former one. For both hardware products and software systems we also have transdisciplinary complicatedness. This means that the current systems design, with a clear and intentional component architecture, is slightly updated, meaning iterations with prototypes to win some new knowledge where experts on systems design and architectures can guide us. But, when making a new way of working for an organization, we only have the latter one. Here we have a more thorough explanation of them:
1) Disciplinary complexity: Research for new technology, or new science** within a discipline, which is very complex since we do not have all knowledge. 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. 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 or initiative, 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, where there over time will be accidental changes to the earlier design, and the integration will show if the new cohesiveness can make the new specie to survive or not, where the ability to continue the reproduction of itself always is a necessity.
Note! A fail to achieve the new cohesiveness, will end up in problems for a product/system, due to science for the product could not be fulfilled
3) Transdisciplinary (integrative) complicatedness: This means that we already have a product or system with a current systems design and architecture, which is clear and intentional, so we can use it with some updates to make the new product/system or our new way of working for our organization.
Note! This means that we can make intentional systems design, where the fitness for purpose can be judged by experts. This directly also gives that making small changes in parallel to make changes for the whole system is not the way forward, and it is also clearly sub-optimising since symptoms can never be solved, i.e., symptoms are always in the Confused domain in the Cynefin™ Framework.
As mentioned above, normal problems in the organization, are normally mistakes, since for example Murphy’s law is always present, i.e., 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, but that instead can be made locally, probably with some clearer instructions. 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 built-in 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 look for root causes in complex systems, since they do not have cause and effect chains. This makes therefore methods to find organizational root causes to be discarded in a wink. But an analysis to find root causes, 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 is not using SPPA and therefore gets an incident, which can regard the people or the activities we are making to reach our products, it means that we had a built-in root cause, or we had made a mistake, that finally, and eventually if we had been all ears about all the preceded problems, generated the incident. This incident, if it is originating from non-fulfilled science in the way of working, 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 built-in root causes. This leads to that we will repeat our mistake again and again, since we never update our malfunctioning way of working. This also means that we will be reactive, and continuously cut the cost, bring in new consultants, re-organize or re-plan, but never dissolve the root causes, to avoid having these incidents 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 built-in and normal 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 :-).
- 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.
- The initiative gives us the context and the domain of the Cynefin™ Framework. Note! 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 completely new product under development.
- 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.
- Congratulations, our new product is ready!
.
Now we have the scenario when everything is not perfect, which can be anything from a deficient way of working, mistakes, or the always present Murphy’s law.:
. - We have some incidents with the solution in any of the different contexts, or in worst case an incident at the customer or user.
- 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 analysis to find the root cause(s), 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.
- 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 built-in problems, i.e., our way of working is deficient.
- We need to take care of the root causes to our incident within the product.
- 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 built-in organizational problems. This gives us the last scenario, where we need to move up to the Organizational level: - 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 traditional analysis to find the root cause(s), avoids to blame if there is a mistake done. We shall of course never blame our people, but if we do not understand that we have also an organizational level, this 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.
- 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.
- 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.
- But, if the common sense is still in the organization, the understanding that symptoms are impossible to solve, we move on to SOSD.
- 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.
- 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.
- 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 built-in 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 built-in 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™ Framework, 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, both regarding many people and the activities to be done, but where the whole way of working itself, in turn need to follow the constraints from science, the organisational principles for people and activities. Otherwise, the organization can end up in the Chaotic domain without warning (due the ignorance of the upcoming symptoms/problems; phenomenology), since the epistemology (by mistake or ignorance) did not match the ontology (maybe due to the nowadays common mono-ontological thinking). To be able to achieve the right context, we 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 built-in problems per se; symptoms and consequences in our organisation, i.e., no difference compared to the products we develop, they also need to fulfil science. It also means that the only way to get rid of them, is to solve the root causes, fulfil the principles, i.e., once again no difference compared to our products. This is the reason why we always need to start with our Systemic Problem Picture Analysis when having organisational problems, since the context give us organisational principles for activities that automatically, if not fulfilled, lead to built-in problems, that is directly impossible to solve. And as we 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 increasing complexity of the context we are operating in, when the number of people increases. Not fulfilling one or more of these principles, will of course give us symptoms and consequences. This leads to that our way of working always need to follow all the activated principles for the activities in the given context, and for all principles regarding people in the normal case, since organizations normally are more than one person.
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 built-in 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 normal problems and the built-in problems, and indirectly tries to solve them separately. This is done by putting a problem in a domain, which once again means that the root causes are not looked for regarding the symptoms and consequences. This means that an abductive approach is not possible.
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 complex activities we are trying to solve. Hypotheses should not be used when we have built-in 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) built-in 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 almost every 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, where all solutions to symptoms mercilessly will lead to unintended consequences. Remember also that you get what you measure, since gaming will be started. If delivery time is important, the teams will not allocate enough work, to be sure to deliver to look good, or if we need to deliver much, the risk is that our user stories become smaller and smaller. The latter will also happen at high risk, when consultants need to sell a new method or framework, since they need to show how fast the new method or framework is. Teams measure only for their own sake, not to be compared with other teams, and due to different complexity in the user stories or different number of dependencies, trying to compare teams only lead to chaos and “we and them”-thinking.
To be able to achieve systemic learning when having built-in 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 insolvable 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”, detangle 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 or intractable or sticky problems, so here we need a common vocabulary to straight things out. Probably it is this blurred and confused picture itself, of all the built-in problems, the symptoms and consequences, as well as the normal problems, that make the vocabulary hard to agree about. And sometimes with a problem, even the meaning of an initiative, project or activity is meant, having very different meaning to a problem as a symptom. A deep understanding of why we need to dissolve organizational problems, could definitely sort this out.
Dissolving the problems within organizations, is with its focus on built-in 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 wholeness approach that takes the whole system into account. With this said, it is therefore always important to start with the dissolving the 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 dissolving the organizational problems and abductive approaches, like Triopticon™ from The Cynefin™ Co, 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 dissolving the 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, built-in or normal, as well as activities will be in the Cynefin™ Framework. All problems, will have their starting point in the Confused domain, but not activities. Activities like an initiative in product development, starts another cycle of our way of working to develop our new product. For the product development that always starts in the Complex domain for new products, we need abductive techniques for reducing uncertainty and complexity. For the latter, we need abductive techniques both for disciplinary complexity and transdisciplinary complexity, where reducing complexity (or complicatedness) are normal activities in any product development since it is about to make the product right. The reason for the abductive techniques is because we in the Complex domain always need completely new knowledge, and where experts cannot guide us. 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 new knowledge needed is very high, as well that we do not know when we have results, or even if we will get results. We of course always need to have the wholeness in control from a top-down perspective, to avoid sub-optimisation, both regarding the handling of uncertainty and complexity. 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. Normal problems are for example problems that are generated from Murphy’s law, changed prerequisites, or human mistakes in the current way of working, and are always part of the game, easily making things risky. These problems are most probably product or service problems, if it comes so far, that can require traditional problem-solving methods like 5 why? or Ichikawa diagrams, that may be the best approach to solve these problems, since they have already happened. 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.
But, remember that SPPA looks for all organizational problems and always need to be used first in order to detangle the mess of problems, and that it is proactive, meaning that we can fix our problems long before we find the problems within our products or becoming deep organizational problems with irreversible negative consequences. This goes both for the different mentioned normal problems above or a mal-functioning way of working generating built-in problems. By using SPPA we can detangle and distinguish these two types of problems. We 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.
It is worth adding that the consequences of the need to find the root causes first with the help of SPPA, means that the top management cannot by themselves implement a new strategy that includes a new way of working. Top management has no clue about the root causes to the problems they see, where their problems normally are non-fulfilled organizational purposes. This means that the whole organization need to be involved from start every time we need to eliminate organizational problems, otherwise we cannot connect the problems for top management with the root causes. This involvement leads to a mutual understanding within the organization, which is really important to achieve. By doing SPPA over the whole organization, top management will also understand that they cannot take decisions about changing the way of working by themselves, which is explained in this picture, Non-fulfilled purposes cannot be directly solved (cannot be wished for, no gap can be closed, i.e., only effects of root causes):
All this leads to that it will much easier to do changes and transformations, since we both have the employees involved from start, as well as that the whole organization will understand that the new way of working really will eliminate the current problems. Here is picture showing that, Problems all the way to the root causes is necessary:
This need of involving the organization already from start, will not change the need of people with change management skills, but it will have some major impact on today’s change management models. Why? The employees will now be engaged from start, and also part of the solution, which means that change management cannot be agnostic to the changes the organization are doing. This also means that the organization itself has most of the knowledge, since we need to know the old way of working, as well as the solution to the root causes. This also leads to decreased need of top management consultants since the solution to the problems now is in the hand of the organization itself. Since the solution to the problems will reveal the organizational changes needed, a proper decision can be taken when reorganizing or in worst case, head count need to be reduced due to a crisis. And before we have a proper way of working we can neither do any Technology Transformation (digital, data, etc.), which is a kind of optimization trying to increase the organizational efficiency, see this blog post for detailed information.
By knowing all the root causes, the output from SPPA, the implementation plan for the needed changes/transformation, can now be further detailed. The solution to the root causes is put in the plan so they are implemented in the right order and at the right time, in the different parts of the organization. It is also important that other on-going organizational changes are stopped, so that the root causes found are solved. This is extremely important since normally organizational changes many times are only sub-optimizing solutions, and most probably will be obsolete when solving the root causes. The plan will be rather straightforward, and due to the need of solving the root causes top-down, there will sometimes not be any early low-hanging fruits in the plan. The reason is that many of the low-hanging fruits that normally is referred to as low-hanging fruits, are only sub-optimising in a product development context, not bringing any meat to the whole. It is also important to understand that since many parts of the organization is connected in product development, many of the changes will be synchronized in the plan, i.e., like at integration events for a product.
Here is a summarizing picture that clearly shows that we need to move from, not only setting goals and closing gaps regarding problems, but also that neither a multiple number of interactions, will eliminate our built-in problems. Actually, there is no difference between the red circle and the red oval, since in both cases the attempt is to solve symptoms. The visual “length” from the root causes does not matter, since symptoms always are impossible to solve, meaning that unintended consequences will be generated in both cases. We always need to go for the root causes, which is shown in this picture, where to solve organizational problems:
Fulfilling science for organizations should go without saying, in the same way as when making products, but is unfortunately not obvious for an organisation and its way of working (including people structures). If a product does not fulfil the needed science, it will not work. Same goes for the way of working in our organizations, if we do not fulfil the organizational principles, fulfilling the purposes of the organizational will be substantially more difficult and, in many cases impossible. And we can never know in advance if it will only cost us some money, or if our products will completely fail, or in worst case our employees will become unhealthy, so the risk we are taking can never be worth it. The sooner we get out from the Wheel of Curse, the better, and now when we know how to do that, it is easy! We just make a problem picture analysis with SPPA, to get the built-in, as well as potentially added self-made normal problems, to be able to find the root causes. Another way to put it is that the problems we experiences are our feedback, and we need to go back in time with SPPA, to find where the feedback loop started, i.e., which are where we will find the organisational root causes. If the built-in or normal root causes found, are way back and long before the teams (or team of teams) even started their work, hypothesis and PDCA-cycles within the teams (or team of teams) will only be sub-optimising, since it is impossible to solve symptoms. This means that short feedback loops in these cases are an impropriate solution and only a waste of time and effort.
Do not forget that SPPA is a method that is context independent and therefore agnostic to way of working, domain or context, it can simply be used for all kind of organizational problems. After we have found the built-in root causes with SPPA, we make a new systems design of our way of working with SOSD to eliminate all our built-in problems. Piece of cake :-). But, our thought pattern, is the tough part to change, since we have been bombarded with methods and frameworks for product development, that divides the whole into parts, in any possible disciplinary breakdown. And since the whole does not work (due to sub-optimization), there is yet another deeper level of parts to optimise, in the next version of the method or framework. But, trying to find a better performing solution of the whole, by aggregating the sub-optimising solutions to the problems in increasingly smaller and smaller parts (disciplines) of the whole, is still sub-optimization. The solution to our built-in root causes in our way of working (incl. the organizational structures), is transdisciplinary and never disciplinary with smaller parts. This also leads to the fact that, the longer it takes for us to change the thought pattern, the more years we can add to our experience working with the wrong thought pattern. In short that means that it is even harder to change the thought pattern, since it is privileged to have long experience of the current most popular method or framework in the CV, instead of concentrating on if the method or framework actually solves the root causes to the problems.
Another name for the place where the Wheel of Curse takes place, is something that Dave Snowden denotes Shadow [6], a place where we cannot be too eager in having a solution, but where we neither can wait with the solution too long. But even this ambiguity of finding the exact right time for our interventions, will never help us because symptoms are insolvable. If we anyway try, we will have unintended consequences, which are new symptoms to the existing ones, meaning we are instead making things messier. As we can see in the picture, the built-in root causes are the ones that we need to shine all our light on. The sooner we do it with the help of SPPA, the faster we are able to leave the Wheel of Curse, or the land of Shadows (Snowden), or mess – a system of problems (Ackoff).
But, as we understand, it will still not be an easy task to move the focus from the right to the left in the picture above, since the right part is today’s behaviour and mindset to take care of organizational problems and organizational development. As the picture tell, we have not seriously been looking for the root causes to organizational problems, which Ackoff brought up already 1995 when he talked about anti-systemicness. His statement was built on all his research on organizations, as well on an American evaluation of many methods used in the 1980s, see this blog post series for a deep-dive into the methods he mentioned. So, the right part of the picture has been going on for some half century or so. And as we understand, if we have not been looking for the root causes, it will also be difficult to start explain that what has been done on the right side is only trying to solve symptoms, which is impossible. And to add, that all root causes are only non-fulfilled science, which also is the reason to why (organizational) symptoms cannot be solved, and always leading to sub-optimization, will be a barrier too, that we need to handle. As well as that the new way of working, that eliminates the problems, always requires a new systems design, all in order to get the desirable systemic solution to our problems. And if we do not move to the left, we will continue to develop our product slowly, to a high cost, have bad quality and in worst case make the wrong and erroneous product, by unhealthy people. But with our deductions made in System Collaboration, and with our common sense, experience and knowledge increasing over time, when we are making way of workings for organizations, the possible solutions to the root causes to organizational problems are considerably reduced to our favour, leaving is in a rather clear context. Our experts can guide us to achieve an updated and better way of working when dissolving the root causes with SOSD, or when implementing the method TDSD for software.
For example, we are seldom making groups/teams bigger than 15 persons, which is a cognitive limitation for how many persons we can feel trust and sympathy for. This have over time led to that we also normally have the right amount of work for the leader/manager of the group/team. All our common-sense, learned mistakes and experience we already have, makes it easy to make a new systems design that will actually be much better than before when dissolving the root causes. And with the help of experts when doing SPPAs, they can from the result (the found root causes), guide to a new organizational systems design with SOSD. This means that we are in the Complicated domain of the Cynefin™ Framework, very close to the border to the Complex domain, which Snowden probably would have stated as the liminal state between Complex and Complicated. We always need to think about our unique human adaptivity, which means that as long as we do not miss processes for reducing disciplinary or transdisciplinary complexity of our product within the way of working, we will most certainly find a way forward, even though it may take long time for the product with for example lower quality to be ready, before we can realize it.
If we neglect that an initiative in product development 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 normal or built-in, 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 and common 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 use terms like 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 problems, normal or/and built-in, it means that to directly apply a straightforward inductive or an abductive approach, is a clear sub-optimal approach, anti-systemic as Ackoff put it. And even to have multiple safe-fail experiments, do not changed that fact. 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. If we have non-fulfilled organisational principles (due to unawareness of their existence and/or that we need to fulfil them) in our way of working in the organisation, we will sooner or later perceive a lot of issues (symptoms), generated due to the non-fulfilment of the basic original scientific constraints in the first case. Without understanding about that these basic scientific constraints need to be fulfilled in the way of working in the first case, we have soon undeliberately induced new natural scientific “constraints”, that we need to fulfil, in order to find a solution to all the perceived issues (symptoms). But these induced constraints will only increase the entanglement of issues (symptoms), and since symptoms are insolvable, meaning that only more insolvable symptoms will be generated, when we are trying to solve the symptoms, i.e., with or without the induced constraints. These induced constraints can be for example; inattentional blindness, look at abstract signification to break entrained patterns of thinking, distributed consciousness, scaffolding, etc., which all at the right occasion have value in themselves, but never in order to find the root causes.
This means that we always need to find the root causes to our issues (symptoms), to be able to detangle all symptoms, that is originating from these root causes. This also shows that we need to start with dissolving the 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 in 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 normal problem, like due to Murphy or changed prerequisites, or is it a built-in 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.
- Every time we need to change our way of working, the whole organization need to be involved. Top management can never invent a new strategy without knowing the root causes to the problems in the organization first. And to find the root causes the whole organization needs to be involved, as well as when finding the solution to the root causes so the new way of working can be implemented.
- 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 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 dissolving the 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…”
[6] Snowden, Dave. Blog post. Link copied 2022-04-02.
Control in the shadow 1 of 2 – The Cynefin™ Co