Today’s blog post will go through the “why”, the theory behind the Systemic Problem Picture Analysis – SPPA, as well as the theory behind the systems design step within Systemic Organizational Systems Design – SOSD, to cover the total of dissolving organizational problems, that in turn is part of the total concept “A systematic approach to systemic learning”. Welcome.
First, we start with some common definitions (in italics), that are used in this blog post, including also some definitions (expressions) that are specific, in order to achieve the necessary meaning and to avoid ambiguity.
System in Merriam-Webster: “a regularly interacting or interdependent group of items forming a unified whole, such as a group of devices or artificial objects or an organization forming a network especially for distributing something or serving a common purpose”
This means that every organization, including its way of working and people structures, is a system.
Organization in System Collaboration: “People that interact to solve activities with dependencies for a particular purpose”, derived from the definition of organization in Cambridge dictionary: “a group of people who work together in an organized way for a shared purpose”.
Part of any organization is of course the way of working, where the way of working also includes the people structures of the organization. The way of working gives the interacting and dependence between different parts within the organization, that all together are making the work to be able to fulfil their particular and shared organizational purpose.
Systems analysis in Wikipedia: “a problem-solving technique that breaks down a system into its component pieces, and how well those parts work and interact to accomplish their purpose.”
Systems design in Wikipedia: “the process of defining the architecture, components, and data of a system to satisfy specified requirements”
Another way to put it is that, the systems design aiming to secure that the system becomes united, unified and well-functioning. This can of course, and many times preferably, be done iteratively, especially if the system is novel and not only an incremental update of a former system. Any system built, will end up with an architecture with components, no matter if the architecture is systems designed or not from the beginning, but if it is not, it implicates that the risk taking has been enormous.
Cause in Merriam Webster dictionary: “a reason for an action or condition” and “something that brings about an effect or a result”
Causal factor in Collins dictionary: “If there is a causal relationship between two things, one thing is responsible for causing the other thing.”
Effect in Merriam-Webster dictionary/thesaurus: “something that inevitably follows an antecedent (such as a cause or agent)” and “a condition or occurrence traceable to a cause”
Antecedent in Merriam-Webster dictionary: “a preceding event, condition, or cause”
Symptom in Merriam-Webster dictionary: “something that indicates the existence of something else”
Root cause in Urban dictionary: “The basic cause of something. A root cause is an initiating cause of either a condition or a causal chain that leads to an outcome or effect of interest. The term denotes the earliest, most basic, ‘deepest’, cause for a given behaviour; most often a fault.”
In the causal chain we will find causal factors.
Problem in Merriam-Webster thesaurus: “something that requires thought and skill for resolution”
In System Collaboration, when talking about the negative consequences that follow from root causes, the word symptom is used instead of effect. This means that a root cause, generates symptoms, or chains of symptoms. A preceding symptom, is therefore the causal factor to the next symptom(s) in the chain. When using the word effect in System Collaboration, it will usually be connected to non-fulfilled organizational purposes (inefficiency, unhealthy people, bad product quality, non-working product, etc.), if nothing else is stated.
In order to be able to differ between different types of root causes that we can encounter in an organization, System Collaboration have two different types of root causes:
Organizational root cause in System Collaboration: “a built-in root cause in a way of working, that per se makes the way of working malfunctioning”
This means a root cause in the way of working, that over and over again will generate chains of symptoms, if the root cause is not eliminated (dissolved).
Normal root cause in System Collaboration: “a root cause originating from inexactness, Murphy’s law, mis-communication, or misunderstanding”
A normal root cause is independent of if the way of working is malfunctioning or not, but the more organizational root causes we have in our way of working, the more normal root causes will be generated. Remember that System Collaboration is focusing on making a flourishing well-collaborating system, which means focus on eliminating the organizational root causes, and never (ever) blaming the people when things go wrong.
In System Collaboration, the word problem itself, will not be used as a synonym for symptom to avoid ambiguity, since problem is sometimes mixed up with cause, or even root cause. This also leads to that in order to differ between different types of problems that we can encounter in an organization, System Collaboration differ between three types of problems:
Initiative in System Collaboration: “can be anything from developing a completely new platform or product, making enhancements, like new or enhanced functionality/performance, solving deficiencies, or performing maintenance in an existing product”
Organizational problem in System Collaboration: “a symptom that originates from an organizational root cause, or from another organizational problem, when making an initiative with the current, malfunctioning way of working”
Normal problem in Systems Collaboration: “a symptom originating from a normal root cause, which occurred when making an initiative with the current way of working”
This distinction of having three different types of problems, is of utterly importance, since the three different types, have completely different solutions, for their “elimination”.
Throughout the remaining parts of this blog post, the word subsystem will be used for a part/item/object/agent of the system, to emphasize that there has been a mandatory systems design preceded by analysis to achieve it, no matter product or organization. This means that the synthesis of all the subsystems will become a united, unified and well-functioning whole system. This indirectly also means that value streams, value chains or any other construction used for product development, in the cases where they are not making whole systems by themselves, per se cannot become a united, unified and well-functioning system. And neither the product/system they are developing can become united, unified and well-functioning in these cases, since only the functional requirements are divided into respective value deliverer (Epics, Features, User Stories), and the non-functional requirements are not systems designed.
Now it is time for the axioms, and the deductions that can be withdrawn from the axioms, that all together shows why System Collaboration and its methods, actually is working, as well as why malfunctioning methods or frameworks do not work. System below can be an organization, a product, a specie (not in focus), to name a few.
Axiom: Any well-functioning system, and all its subsystems, follow (all the needed) science.
The system can be a product or a human system, where the latter can be an organization.
Deduction: (from the common definitions of system and systems design): All systems have an implicit system architecture that is showing its sub(-sub)systems and their interfaces (explicitly built by a systems design, or not, where the latter means high risk for a malfunctioning system).
The visualization of the systems design, will be a top-down system architecture, layer per layer.
Deduction: The achievement of the systems design of a whole, is always a hypothesis regarding that the implementation of the (sub-)subsystems, will integrate to a united, unified and well-functioning, long-term qualitative whole, i.e., since we need to reduce transdisciplinary complexity (find new information about how the subsystems will make the whole), until the whole works as intended. (The more novel system, the more transdisciplinary complexity we need to reduce.)
Reducing transdisciplinary complexity, means that we need new knowledge from the verification (of the implementation) of the whole, to understand if our systems design of our (sub-)subsystems was correct, or not.
Deduction: This hypothesis of the systems design always need to be verified, by doing the implementation of it, which indirectly means that no (sub-)subsystems of the whole, no matter size, can be validated in itself, neither by review of the (sub-)subsystems specifications (or software code) nor by a successful verification of the implementation according to the (sub-)subsystem specifications, until the implementation of the whole is successfully verified.
That it is not possible to validate subsystems by themselves, indirectly means sub-optimization if we try, i.e., it means that we are trying to solve symptoms, which is impossible, which will be further deduced below. This directly also means that we cannot just add requirements to a subsystem, functional or non-functional requirements, that has not originated from a systems-design of the whole (and further systems-designs down to the subsystem, level by level), since that also means sub-optimization.
Deduction: The higher transdisciplinary complexity we need to reduce, the more iterations of our (hypothetical) systems design is needed, until the implementation of it, fulfils all the requirements of the whole system.
This fulfilment means that our final hypothesis, explicit or not, about how our subsystems shall be integrated to a united, unified and well-functioning whole, i.e., our intended systems design, has been correct. This does not mean that the systems design always is possible to explain, e.g., the systems design of organisms (at least not yet).
Deduction: A well-functioning and long-term qualitative system, fulfil (all the needed) science per se, which also includes its sub-systems, sub-sub-systems and so on, as well as all integrations of them, all the way up to the whole integrated system.
This goes for all different systems, for them to be able to work as intended, the needed science always need to be fulfilled, even though it of course may be different science per (sub-)subsystems and/or whole. A good example of the need of fulfilling different science regarding a product, is a boat, that in its whole need to fulfil Archimedes’ principle, even though not even one single piece of the boat needs to (not even the hull, since it also is made of pieces). Our organizational principles are the needed science for organizations, to be able to achieve a flourishing way of working. Our organizational principles are also contextual, which can be summarized as; the more complex context, the more of our organizational principles are “activated” and therefore need to be fulfilled, when trying to find a solution within the given context. Note! Even though we fulfil science, this does not mean that our system will work as intended, or even at all. Note also that science can be of more trivial kind, like weight and size. Remember also that symptoms always are acontextual, since they are insolvable.
Deduction: If the needed science are not fulfilled, the system will be malfunctioning, and the non-fulfilled science will be the corresponding root causes.
This means that our hypothesis, explicit or not, about how our subsystems shall be integrated to a united, unified and well-functioning whole, i.e., our intended systems design, was not correct.
Note that for all the functions we need to achieve with our system, all the needed science need to be fulfilled, otherwise we will fail, no matter if we need to send a space rocket to the moon, or we need make an axe for chopping wood.
Remember that we always will have normal problems, that depends on that we are human, which also have root causes, but where the solution is more of making a better instruction, or the fact that a mistake was done.
Deduction: If our system does not fulfil (the needed) science, i.e., having root causes, it will therefore work improperly, or not at all. This will generate symptoms linked in chains of symptoms, originating from the root cause(s). The symptoms (if we listen and are observant) are showing us that something is wrong with our system.
Symptoms that are generated from an erroneous systems design of the way of working that not fulfils our organizational principles (the needed science), are called organizational problems in System Collaboration, since they will occur due to built-in root cause(s) in our way of working.
Symptoms that are generated even though our systems design of the way of working fulfils our organizational principles, means that we have normal problems, i.e., mistakes will always be made.
If we perform our method SPPA in our organization, we can proactively perceive symptoms of any kind early, and sort them out, to be able to distinguish between organizational and normal problems. This means well before we partly or completely will fail the purpose* of our organization, and therefore long before our employees start to get unhealthy due to a bad way of working.
Axiom (and common sense): Symptoms can never be solved in order to try to remove the root cause(s) (neither the cause(s)) in a system, since symptoms are only the result of the existence of something deeper rooted that is not working, i.e., the root causes.
Deduction: Trying to solve symptoms within the system, always lead to a sub-optimization of the whole, since non-fulfilled science on the subsystem or the whole still will not be fulfilled.
Instead more and nastier symptoms will be generated within the system.
Deduction: No sub-systems can neither be optimized, or optimize their way of working, in any system, well-functioning or not, if that leads to that the system no longer is fulfilling the science, or fulfilling less science, since that only means that (more) root causes within the whole instead are generated.
This means that we can only frame (to only a subsystem within the system) a found symptom, and force the solution (optimization) to be found within that frame, if, and only if, the root cause(s) to the symptom are stated to be within that frame. This kind of symptom can be generated due to that the systems design for the subsystem was not fulfilling the science, or that the systems design was correct, but the implementation of the subsystem was erroneous. This also gives that Continuous Improvement on subsystems (locally) of the way of working in any organization, is wrong per se. This also means that local decisions about the local way of working are treacherous to take, if the root cause(s) to the symptoms found locally, are originating from above. And we can never know where the symptom is originating from, until we have made a problem picture analysis for the organization.
This also gives that trying to improve organizations by system analysis, always means the necessity of finding the root causes to the symptoms, by looking on the total way of working. This is due to the fact that all breaking down of the system into pieces (framing), and trying to optimize the pieces, means that we are trying to do the impossible, i.e., solving symptoms within a frame (symptoms that we believe are root causes since we have framed them), which means sub-optimization of the whole system.
Deduction: Since our people, all have the same DNA, where built-in collaboration is a very important characteristic, this means that our people can never be blamed, when the organizational purpose is not fulfilled.
This means that no one, team, team or team, etc. can be replaced to achieve improvements, compared to a subsystem of a product that can be erroneous (built wrongly). This also means that even if the way of working is correct, we can still have malfunctioning products, which in this case are symptoms originating from human mistakes, which means normal problems. To minimize the risk for making the same mistakes again, we need to look over the description of our way of working to make it clearer. Components can be anything from a resistor in hardware to a piece of code in software.
Let us exemplify. If the activity of systems design of the actual product in product development, or planning is missing (needed in all contexts), a new systems design is needed for our way of working, since we need a new HOW to be able to efficiently and effectively solve the WHAT. Worth to remember is that these two examples are referring to activities that in the former case is needed in product development and in the latter case are always needed in any way of working. This is valid no matter how many persons in an organization that are actually solving the activities, even though the systems design of the organization may be different, depending on for example the number of people in the organization.
If we take planning of a systems design as an example, this means that we need to plan short-, middle-, and long-term, no matter if there are one or many persons in the organization doing the job. This means that we always need to follow the organizational principles for activities (especially logic and complexity theory) valid in the context. If we are only one person in the organization, we still need to add the organizational principles regarding to reduce the complexity by using documented information (text, pictures, diagrams, structures, etc.). If we are many people in the organization, we need to structure all the people, but not anyhow, since now we also need to add the organizational principles for people that regards, 5 (Miller’s number/Chinese Wisper, 15, 150, etc.). So, in the end our systems design needs to be built on all the organizational principles needed for a certain context, but to be able to make a valid systems design of our way of working that is proper already from start, we need to use our experience, knowledge, common sense and critical thinking, so that we in the end will have a flourishing organization fulfilling our organizational purpose.
Deduction: When the root causes are non-fulfilled science, and since symptoms never can be directly solved, this means that the only way to eliminate the root causes to organizational problems, is to make a new systems design of the way of working, that fulfils all the (needed) science for the system.
This means for example that if the organization is too expensive (organizational problem), we can only focus on the built-in root causes on the whole, and make a new systems design that fulfils science. This means that a cost reduction program, or outsourcing of subsystems, are very dangerous due to the extremely high risk of sub-optimization, at the same time, as no root causes are eliminated.
This means that if we compare system analysis and systems design of organizations, the heavy part is on the systems design, where we are looking for the solution that eliminates the found symptoms in the analysis phase. This means that for organizational systems design, the competencies of system analysis and systems design, should never be separated into different disciplines/people. This due to the fact of the needed transdisciplinary perspective of the organization, instead of trying to go into the details of the different individuals, groups, teams, team of teams or departments of the organization, which will lead to sub-optimization.
Axiom: All human systems are adaptive (Human Complex Adaptive System – Human CAS).
Deduction: The adaptivity of human systems make them able to fulfil the organizational purpose to some extent, even though there are built-in root causes in the way of working.
This means that even if we have smaller anomalies in our way of working or we make mistakes, and the future is unknown, we can still to some degree with collaborative effort handle that. But that does not mean that we can handle also bigger anomalies in our way of working, i.e., built-in root causes, without being inefficient, late and in worst case also ineffective.
This also makes us very different from other complex adaptive systems like ant hills or flocking birds, that only have adaptiveness (but great of course), for different environmental circumstances. But they strictly follow what is in their DNA, but where we humans also are adaptive, even if our way of working does not follow the organizational principles. This means that we in some cases, especially in non-complex contexts, will get something out from our way of working, even though it is not optimal from an efficient and effectiveness perspective.
Deduction: The adaptivity of human systems leads to that built-in root causes, that are not handled (even though they are early detected due to symptoms), can lead to severe consequences and incidents much later; for example, low or no fulfilment of the organizational purpose, and the risk for big and increasing physical and mental ill-health.
Deduction: If there are incidents, i.e., severe consequences from the symptom(s), they always need to be handled promptly.
Examples of incidents are; our people are unhealthy, or the customer have problems with our systems (products), which may require a restart of the system, until the system is properly fixed and updated.
In the reminder of this blog post, we are going to indirectly elaborate mostly on the deductions above.
There are different ways to define a Complex Adaptive System, a CAS, which is a system containing of agents, that has an unpredictable emergent behaviour or emergent properties (abstract qualities like mindset, culture, trust, innovation, etc.), that the agents do not have on their own [1]. One common definition is to describe it as “containing agents with interrelationships”.
Another way to define a system is; “A set of principles according to which something is done” [2]. This second definition is also in line with the first definition above, they are only on different abstraction levels. The second definition with scientifical principles, is on the lowest abstraction level for any system. The principles and laws of natural science is the only true basis for any system, no matter the complexity in its emergent behaviour or emergent properties, or the complexity of “something done”. In the continuation of this blog post series, this is what is meant when the word principles are used, and specifically the organisational principles, if nothing else is stated. Since they are derived from natural science, this also means that these principles are universal/context independent/context-free, since they are valid in all contexts. But this does not mean that all principles are “activated” in every context; Clear, Complicated or Complex if we refer to the Cynefin™ Framework. This also means that if the “activated” principles in the context are not followed, the system will be a dysfunctional system to some degree, depending on the possibility of adaptivity; the adaptivity for our employees in the case of our organization. Every organizational principle is not only an explicit constraint since we know about it, but it is also an enabling constraint. This means that the fulfilment of an organizational principle leads to less risk for failure, and that we to a greater extent will have a flourishing organization with thriving people.
Science is always an enabling constraint. A constraint for success.
With (especially) organisations in focus, this second definition of a system is appropriate for dissolving the organizational problems (from the concept dissolve a problem, Ackoff [7]) in human complex adaptive systems. Because if we are not following the “activated” principles for a context, we will for sure have problems that is built-in; symptoms and consequences, so to say, which are impossible to solve in a direct way. The symptoms and consequences are some kinds of implicit constraints, i.e., unintended consequences that we cannot directly do anything about. And if the organisation is a dysfunctional organisation according to above, we will for sure not understand it, due to all the symptoms and consequences emanating from non-fulfilled principles, it will be a mess – a system of problems [8], as Ackoff stated. And we will not only have unpredictable symptoms and consequences giving us a bad result in form of a non-fulfilled purpose. The multiple interactions within the organization will not only increase dramatically due to all problems, they we will also generate non-favourable emergent behaviour and emergent properties. That is why there is a strong connection between the purpose (result) and the emergent behaviour and properties, shown in the picture. Trying to directly change these “erroneous” interactions will not help in trying to solve all the symptoms (built-in problems) within the organization. This leads to that nudging people, by trying to influence, stimulate, catalyse or reinforce their interactions, therefore unfortunately will not help, and is clearly not an alternative to dissolving the organizational problems in organizations, it will instead in fact only lead to more unintended consequences, since symptoms can never be solved.
Too many symptoms and consequences can in turn lead to, since our organization is a complex (adaptive) system and we are having this messy situation looking complex, that we are demanding (only looking for) complex solutions this system of problems. This means that are thought patterns are constrained, instead of focusing on the non-fulfilment of the principles the organisation needs to follow in their way of working, to achieve the purpose. We need to change our thought pattern, so we not continue with the overarching problem-solving approaches of today, that focus on the problems themselves, i.e., the symptoms that only are truly insolvable. Instead, we need to embrace the opportunity to dissolve root causes.
To only look for complex solutions seems even more easily done regarding human systems, where for example Dave Snowden often refers to the difference between animal and human systems and talks about the individual human ability of intention, identity and intuition [9]. He argues that this makes us humans very different from animal systems, which he summarizes in the term anthro-complexity (anthropology and complexity). Of course, he is right about that animal and human systems are very different. But, let us not forget that we humans set purposes (intentionally) for our organisations as described above and from the purpose gets the context and makes a way of working to bring an overall order and control of our system. The necessity of controlling and bringing order in human complex adaptive systems has also been picked up by Snowden; “While nature is always complex, humans have learnt how to create order, and also how to order aspects of complex systems.” [10] and “In fact a complex system needs more centralised and disciplined control than an ordered one.” [10]. But, while we humans strive to bring order and control, we at the same time also have built-in principles in our DNA that we need to cope with, even if these built-in principles can be very different from the animals’. So, the question is what is happening if we are not following our organisational principles, when we make our organization, where we really can talk about systems design? Is the solution to that dysfunctional organization to be considered needing a complex solution?
Let us take an example where we many decades ago treated, not only the behaviour of the system, but also the solution to the system, as complex. But that changed 1987, when Reynolds [11] modelled flocking behaviour with a simple set of rules, that made random individual agents to behave like flocking or shoaling. Even though all birds do not have the same genetic code, Reynolds showed that they all have the same built-in principles (not necessarily his set of rules) for the ability of flocking in their DNA, making this needed collaboration possible. The flocking is the purpose (unknown to the birds themselves) of the complex adaptive system (the flock of birds). The behaviour of the flock of birds for achieving the flocking, looks very complex due to its unpredictable emergent behaviour originating from innumerable, and unpredictable as well, interactions, but that we now know has a non-complex solution.
We humans also have collaboration principles in our DNA, in the same way as the principles that are making ant hills, shoal of fish and flock of birds possible. Our collaboration principles have been built over millions of years of co-evolution with nature. Originally the purpose for these collaboration principles evolved to be able to collaborate within families and tribes, to collectively protect us from other species, to get food, protect us from the weather, etc. These principles are also what’s in our DNA today, having the same validity also for our collaboration within bigger entities like organisations and cities among others. And the best part is that we already have understood the needed science already regarding these principles, like Dunbar’s number, Miller’s magical number seven, etc. This means that we do not need to invent any new science about us humans by digging deeper within the corresponding disciplines We just need to follow the principles when we transdisciplinary make our integrated** way of working (HOW), otherwise we are risking only new panaceas, a term that Ackoff frequently used. The HOW means a synthesis**, or a cohesiveness**, a systems design** of the organisation that will fulfil the purposes. Our HOW is a context dependent way of working for our organisations, that depends on the complexity and uncertainty level, where for example all kind of product development is a complex context. This means that the context dependent purpose of the organisation, produce or product develop, gives the complexity level and together with the uncertainty level of the product (WHAT), directly will affect the HOW. That also means that WHAT to do is not as important as the uncertainty level of the WHAT.
Of course, we humans are not ants (Snowden), fish or birds. One main difference between us humans and (most of the) animals, is that animals obey under these built-in collaboration principles, but we in many cases are not. This means that we can make an organisational structure that we as humans cannot cope with, even though we are adaptive. Another important aspect is that the birds do not know the purposes of any of the principles (rules) they obey under, for example the principles supporting the need for flocking, or other collaboration principles in their DNA that they need to obey.
Another big difference between (most of the) animals and us humans as mentioned above, is that we humans can set a purpose ourselves, giving us the context, as mentioned above, and we can talk about contextual purposes. That means that we understand what we are doing and why we are doing it in that context, and we can, as Snowden mentions, also handle many different contexts by changing our identity depending on context, family mother or CEO in a big organisation. But even though we humans can set our contextual purposes ourselves in an organisation, we still need to set up the way of working so the principles in our DNA for collaboration are fulfilled. If we do that, we have a big chance to fulfil our purposes and achieve also a flourishing organisation, even do we can never predict the emergent behaviour of our organisation, our complex adaptive system, where the behaviour of the organisation also depends on environmental changes. The Cobra Effect is a good example of a human system that sets a purpose, to get rid of the cobras, which was a good purpose (intention), but where the solution with the bounties was sub-optimal and only sub-optimising the total system.
But many times, we humans are ignorant to these organisational principles, which may be due to lack of knowledge or anti-intellectualism or both, even though science since a long time, have found out about them. This regards both the human principles we indirectly ‘obey’ under (need to fulfil) for a flourishing collaboration, as well as any other ‘non-human’ scientific principle that we definitely obey under, logic, mathematics, physics, etc. Ignorance of the latter means not only big problems with the output from the organisation regarding our products and services. It also means that even if we from start are following the principles for human collaboration in an organisation, the continuation of this ignorance of ‘non-human’ principles requires horrendous master suppression techniques. Which of course lead to neglection of respect for people in our organisation, a very important principle to live up to. This will even in the short run generate consequences due to bad human behaviour and in the long-run the culture of the organisation will deteriorate, the organisation will for sure have a walk in the dark. This ignorance also means that we 30 years after Ackoff started to criticize panaceas, still continue trying to make them, claiming that their manufacturing-like solutions this time are universal. And this is happening even though we from an organisation’s purpose easily can judge if we are in the Complex domain or not, for the problem to solve.
Now it is time to come back to our organisations and the presented definition of a system. If we use this definition of a system for our organisation, that means that we; 1) need to find that set of principles 2) make an organisation with our people doing their activities, using a way of working that is following these principles, so we can achieve the purpose with our organisation in a flourishing way.
So, what is the purpose of our organisation? For its survival, our organisation’s purpose is to fulfil the need of today’s market, in which context the organisation is operating, for example, manufacturing, service, product development, etc. And our organisation consists of people and activities. As earlier blog posts stated, this gives us our context independent (context-fee) system start definition; “People that interact to solve activities with interdependencies, for a common purpose”, see this blog post for details. From this start organisation definition, we then have thoroughly explored the evolution of the market and organisations in this blog post series, and how they are deeply intertwined. We have then looked into the already existing science (also context independent) about activities and people, which is our evolutionary prerequisites and added these principles to our organisational definition. Depending on the more complex context the organisation is operating in, the more principles will be “activated”. By only adding the minimum needed principles to our organisational definition, we are not only sure that our people can follow the system definition of our organisation, but also that the organisation built is not more complicated than necessary. And with our set of principles needed, we can then build our flourishing organisation.
But, if we already have an existing way of working in our organisation, it would be neat to know how to fix the organisational way of working problems, without risk for sub-optimisation. And as stated in the first blog post in this series about sub-optimisation, trimming of silos or Agile teams will only be sub-optimising. This trimming is therefore together with situational assessments, according to complexity theory regarding unintended consequences, a very difficult and time-consuming way forward with no guaranteed results, only extremely high risks.
So, if an organisation’s way of working, does not fulfil one or more of our principles, it for sure means problems within the organisation. This will be either by not handling the activities correct, having bad structure etc., or we have principles that our people cannot follow due to violation of their cognitive abilities. That means that the non-fulfilment of a principle is a root cause, which means that if we negate our principles, we have all the possible root causes to problems within the organisation. This also means that if we fix one of the root causes, we will automatically fulfil the corresponding principle, which means that we have changed our systems design of our organisation and thereby dissolved our organisational problems. And according to the definition of a system above, it means that we are redesigning the system, and not interfering with it by trying to do the impossible, solve symptoms and consequences. We will simply get rid of the current unintended consequences, originating from the past non-fulfilment of the principles.
This is the difference between dissolve and solve*** in organisations; when we dissolve something, we act systemically to get something we want (i.e., get rid of symptoms and consequences within a system), but when we solve something (the symptoms and consequences) directly, we act anti-systemically [7] (a word that Dr. Russell Ackoff often used) and try to get rid of something (the symptoms and consequences) we don’t want. Quoting three times Russell Ackoff: “Improvement must be focused on what you want, and not on what you don’t want!”, or here [8]: “… not to get rid of what you don’t want. Defect management is not an effective mode of management.” and the final quote about using design when possible [12]: “Dis-(solving)solution involves design. Solution involves research. We don’t recognize design as a way of dealing with problems, that’s superior even to research.”
Another way to put it, is that dissolving means that we will redesign our existing system, to a new system to achieve the purposes of our organisation (what we want), and where the problem (symptoms’ chains of the root cause(s), that we don’t want) no longer exists. That is coherent with the science about complex systems, which states that a problem within a system cannot be isolated, modelled or solved.
We can also look at our organisation as a black box, but with permeable boarders to make it resilient to customer and environmental changes, solving activities within its domain and the different contexts for its different parts (/subsystems). By viewing our organisation, our system with the way of working that includes also the people structures, as a black box, we cannot interfere/intervene within the box. This makes it easier to understand why dissolving the organizational problems does work, since we do not make interventions within it, we change the way of working by doing a new systems design of it. The input to our black box is; our way of working built on the “principles”, what to achieve (the product or service) which also includes our purpose, and our healthy people. As output comes the fulfilled purposes of the organisation; the correct product correctly built, on time, to the right cost and quality, and where our people still are healthy. The permeable boarder is of course important for changes in the environment, to be able to meet changing customer needs. But permeable boarders also put the fingers on the need of having permeable boarders also on the parts (/subsystems) of the organization that together design, build and test, to be able to deliver something new, like in product development of new products. Because the permeable boarders are a necessity to be able to make the necessary interactions between our people, in order to make something novel, since the interactions in this case cannot be predetermined. This is also the reason why the virtual structure setup of projects, was invented in the 1950s, see this blog post for detailed information. And we can also see that to be able to fulfil the organizational principles for product development, we need both the line hierarchy as the (rigid) fundament for order and structure, and virtual delivery structures, where also most of the people will do their work, for permeability. Since this solution, fulfils the organizational principles, it means that it eliminates the problems, and therefore the never-ending meetings and discussions about for example; too large people structures, poor fitness towards purpose, too many unplanned (inter)dependencies, and too rigid boarders. Having projects is only one solution for virtual structures, taking care of the wholeness to deliver, also including keeping track of the (inter)dependencies between the parts/subprojects/components. The latter means that administration including logistic work, is removed from the teams, that instead can concentrate on what they do best, and shall not be seen as someone on the top ordering**** the teams what to do. We always need both these people structures, so we can remove the classic sub-optimization and therefore avoid hampering of our people’s interactions, see the blog post about SOSD for a detailed explanation.
Let us take an example. If we change the input for example the “principles” for the way of working, removing “Respect for people”, we will receive another output (the effect), most probably a bad one regarding the product, apart from that we now of course also have unhealthy people, at least long-term. Of course, we do not want to make our system worse, we need to make it better, but this was only an example of the important aspect that we have not violated some theory of complexity theory. Because we have not interfered with the system, not modelled it, not measured it, not needed to make a situational assessment, not sub-optimised it, just changed one of the inputs (cause) regarding what principles to follow (in this case to the worse) and waited for the output (effect).
Since we have not opened this black box, it also means that we do not need to know the vocabulary within the different disciplines within it. This goes especially for complexity theory that has a very difficult vocabulary, and needed within its own domain of course, when we dive into its depth, which we do not need to do in this case. But, as stated in this series of blog posts about a needed common vocabulary on the top level when we are working transdisciplinary, we do not need to know the details of the different disciplines, but we definitely need a common language to even be able to talk on the top level between the disciplines. Once again, we can refer to Ackoff’s quote [12] “Dis-(solving)solution involves design. Solution involves research. We don’t recognize design as a way of dealing with problems, that’s superior even to research.”, since the design of our organisation is trans-disciplinary, and do not require in-depth research. If we do not have a common vocabulary on the top level of the disciplines, the risk is that even though the different disciplines’ experts are sitting in the same room, they can only work multi-disciplinary. This will make them more of advisers, which is very common in traditional silo organisations, rather than actively taking part in the transdisciplinary problem-solving in order to achieve a new synthesis, or new cohesiveness (Juarrero). Or as Snowden puts it; “In effect we have a basic mistake, the belief that a collection of specialists is as good a generalist.” [13]. Unfortunately, stopping at only multi-disciplinary work and not reaching the necessary transdisciplinary work, is very common for agile frameworks at scale on the top level of the organisation and system product as well.
And as we already know, there are many organisational ways of working problems in today’s silo or Agile organisations that seems that they cannot be explained. But with our set of principles, we can easily judge, that the panaceas of today trying to cure symptoms, are clearly sub-optimising, trying the impossible of solving symptoms. These panaceas are also anti-systemic and this is handled in this series of blog posts, referring to the great work of Dr. Ackoff, who talked about panaceas already three decades ago. Sometimes the organisations themselves during a transformation of their way of working, understand that something else needs to be done, and takes care of the real root causes and in this way takes control of their transformation. Unfortunately, many organisations do not understand that the method or framework they are transforming to are not interested in solving the root causes of the organisation. These frameworks instead (indirectly) states that they are context independent (universal), which means that they therefore simply only are trying to solve symptoms in a complex context, by the implementation of artifacts. Sadly, since the approach is bottom-up and in reality, take considerably long time to implement, the organisations still continue with their transformations despite big problems, putting more good money on the bad money. Often these transformations start with an clear context of maintenance or small functional enhancements in an already existing systems design, architecture, systems test, with people already knowing the product, not to mention the best people, which is far from developing a novel product. Removing people’s skills, experience and common sense from the problem-solving picture during the transformation and instead replace that with artifacts, is what the panaceas always have been pushing for. By doing that, the panaceas try to show that they are universal and that the solution is always as easy as in a manufacturing context and that a simple education makes the participant to an expert as well. But, in a complex context like product development, where scale makes it even more complex, solutions, thinking and principles from a manufacturing context will never work.
If we look at all the observed problems within the organisation, we can see that they are universal, due to the fact that we in any problem rarely see any connections to our organisation. This means that with the total picture problems cannot judge which organisation it is. The reason is that the principles are universal, which in turn makes all problems universal too. To be able to understand all these organisational symptoms, is where our Prefilled Problem Picture Analysis Map comes in, see this blog post for the details. If we negate also the purpose of our organisation (low price, cheap development, the right product, fast to market, etc,), we have the complete problem description to why an organisation is not working. And by asking why, why, why, from this problem description, with all the observed problems within the organisation, the symptoms and consequences can be found, we will finally end up in one or more root causes.
Now it is not only obvious that the panaceas cannot work, it is easy to see as well, and now we also know what to do about it. Only acceptance of this naked truth, is the hard part. Very, very hard, to be honest. This yields especially for service organisations like banks, insurance companies and governments, that recently moved from buying systems, to instead making the systems themselves, meaning that they are moving from an easy context to a complex context*****. These organisations are very vulnerable, making them easily accepting panaceas, since the managers and top management do not understand complexity. We therefore need a very easy and straightforward way of looking at problem-solving and learning in our organisations. “A systematic approach to systemic learning”, with its first step of always collecting the problems within the organisation and try to find the root causes, is a true eye-opener for the entanglement of problems in an organisation and how we in most cases can dissolve this entanglement, or “a mess – a system of problems” as Ackoff would have stated it.
So, in the same way as we now have understood that flocking behaviour only look complex, but have a solution that is non-complex, we simply need to stop treating the solution to organisational problems as only being complex, just because the behaviour of an organisation looks complex. Instead, we need to detangle all organisational problems that originates from non-fulfilled organisational principles, which are our root causes, and solve them, since they in the same way also have a non-complex solution******. By doing this we will avoid all the things that we need to cautiously consider that were listed in the introductory blog post of this series.
It should also be mentioned that a traditional analysis to find the root cause(s), like 5 why? or Ichikawa diagram, is a lagging indicator, since it is used when the incident happens, or when the compliance test fails. But, dissolving the organizational problems on the other hand, is a leading indicator, since we very early can see the first symptoms of unsolved root causes, i.e., the non-fulfilled organisational principles. Dissolving the organizational problems can and should be done continually a couple of times per year, or at certain scheduled occasions over the year, since the effort is really minimal as described in an earlier blog post in this series.
This was all for today. Next blog post in this series discusses why starting with the SPPA method is so important, not only to find the root causes for built-in problems, but also to detangle the mess of problems. It will also show that the use of inductive or abductive approaches is not interchangeable with this necessary detangling, and we will also have a wrap-up of the series.
C u soon again.
*a common purpose, see a); Purpose statement, see b)
a) don’t mix up the word purpose itself with setting the purpose for an organisation. All organisations have a purpose, which means that only the word itself is context independent, or a context-free constraint, for example according to Juarrero [14]. But, as soon as we are setting the purpose for our organisation, we are also choosing the context for the organisation. For every context it means that a certain amount (subset) of the organisational principles will be “activated”, and with a more complex context, the more of them. In a complex context, the Complex domain according to Cynefin™ Framework, the whole set of the organisational principles are “activated”, and need to be followed, to achieve a flourishing organisation.
b) 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.
**integration, synthesis, cohesiveness (Juarrero [14]), systems design, meaning all the same thing, we simply integrate to a way of working, but even if we follow the principles, we are exploitational, meaning that it most probably will not be perfect the first time we try, but of course to than when we ignore (the existence of) the principles.
***a problem (symptom) in a product, can of course mean that a subsystem is broken when the systems design is correct, so we need to analyse, find, fix or change the broken subsystem. That is the big difference between products and organisations, since in organisations we have us humans, so we can only dissolve our problems top-down by changing the systems design of the organisation.
****Even when building a house, there is need of a project management (and of course an architect making the systems design of the building), keeping track of what to build and in that order, leaving the actual work to the engineers. And the engineers are for sure very happy that they do not need to also be the architect and project manager.
*****An apt example is government institutions, which in the past only have bought the technical systems, both hardware and software, to run their businesses. Recently, more and more of these government institutions are transforming to organisations that make their own software supporting the service that the respective institution is aiming for and that normally is very specific and not a shelf product that can be bought.
This means that these government institutions are making a contextual change, from an easy context (Clear domain in the Cynefin™ Framework), where they only buy the products, to a complex context, where they actually make the software product development themselves. Going from an easy context to a complex context is an extremely big mindset change not to mention also the need of a completely new knowledge base regarding complexity theory, where the focus is moving from the actions that is solving an initiative to interactions that will solve the initiative.
Moving from an easy context to a complex context, means that more organisational principles will be activated, or constrain (in a good sense) an organisation’s way of working. In for example the complex context of product development, the complexity level needs to be correctly reduced, otherwise the product will be done wrongly, which is never a case in an easy context.
This means that the principle for reducing complexity, a necessity for developing new products, now will constrain our way of working in an institution. The organisational principles are always constraints, but they are never limiting ones. Instead, they are enabling universal constraints due to the fact that the organisational principles are science. And science is always an enabling constraint, which also Snowden refers to; “But I used the occasion to elaborate the idea of using the natural sciences as an enabling constraint.” [15]. Which is not controversial at all, since if we not follow fundamental laws and principles of science, we will fail, no matter if we are making an organisation or a product. It is always a necessity to follow science, no matter context, since science is universal.
And as we understand, this is a giant leap for any government institution, and also any other service organisation starting to develop their own software, like banks, insurance companies, retail companies, etc. If we are not following the organisational principles properly, we are going from a context with the risk of inefficiency, i.e., high cost and bad quality, to a context where we also adding the risk of ineffectiveness, the product we are longing for may not even work. This giant leap is especially valid regarding the principle for reducing complexity, since that principle never constrains an easy or a complicated context. Here is where the mindset change comes into the picture, which only can be achieved if this principle is understood by the management and other leaders, that are responsible for the way of working. A wanted mindset can never be wished for, it is instead emergent from the interactions within the system. A problem that commonly arise regarding this is when the mindset from an easier context, where for example the mindset of dividing things into smaller things always is valid, is totally wrong in a complex context like product development. This means that if this mindset is still ruling, it is diametrically opposed to the solution of the root causes we will get with this wrong mindset. This means that we can never dissolve the symptoms and their root causes, since the mindset is prescriptive also regarding the solution.
Another bad news for government institutions, is that the current hierarchical structure alone, will not be able to support this contextual change that product development imply. But there are some good news and that is that the current hierarchical structure is still a necessity for the stability of a bigger organisation. What we need to add is a virtual structure for a product development initiative in focus, to avoid the hampering of interactions and innovations, and instead nurture them, to be able to achieve the new cohesiveness, which always is needed for the development of new products.
******the solution is instead integrative, which means a solution in the Complicated domain, where we need to acquire some new knowledge to get the cohesiveness needed for the updated and improved way of working.
References:
[1] Wikipedia. Emergence. Link copied 2021-11-16.
Emergence – Wikipedia
[2] Lexico. System. Link copied 2021-01-03.
System | Definition of System by Oxford Dictionary on Lexico.com also meaning of System
[3] Snowden, Dave. Blog post. Link copied 2021-07-29
Naturalising narrated – Cognitive Edge (cognitive-edge.com)
[4] Snowden, Dave. Blog post. Link copied 2021-07-29
Control is key in managing a CAS – Cognitive Edge (cognitive-edge.com)
[5] Snowden, Dave. Blog post. Link copied 2021-08-02.
The necessity of constraint – Cognitive Edge (cognitive-edge.com)
[6] Snowden, Dave. Blog post. Link copied 2021-08-02.
Importance of a solid understanding of the nature of complex systems (cognitive-edge.com)
[7] Ackoff, Russell Lincoln. Article. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/
[8] 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. At 10.55min and 12:45min. Link copied 2018-11-21.
https://www.youtube.com/watch?v=k8g6ZoobDV4
[9] Snowden, Dave. Blog post. Link copied 2021-07-06.
Humans are not ants, agents or angels – Cognitive Edge (cognitive-edge.com)
[10] Snowden, Dave. Blog post. Link copied 2021-08-03.
Control is key in managing a CAS – Cognitive Edge (cognitive-edge.com)
[11] Reynolds Craig W. (1987) ‘Flocks, herds, and schools: a distributed behavioural model’, Computer Graphics 21(4), July: 25–34.
[12] Ackoff, Russell Lincoln. Presentation film, at 1.02.31 min.
Link copied 2018-11-15.
https://www.youtube.com/watch?v=EbLh7rZ3rhU
[13] Snowden, Dave. Blog post. Link copied 2020-12-12.
“Its not science until I can mathematize it …” – Cognitive Edge (cognitive-edge.com)
[14] Juarrero, Alicia. Presentation from the Lean WX conference, April 2015.
Constraints that Enable Innovation – Alicia Juarrero on Vimeo
[15] Snowden, Dave. Blog post. Link copied 2021-08-06.
Natural science as counter-factual – Cognitive Edge (cognitive-edge.com)