The wrap-up of the System Collaboration Suite™ Blog

Welcome to the wrap-up blog post of the System Collaboration Suite Blog™, its last blog post!

If you have read all the blog posts in this blog book, I need to congratulate you. Your organisation will have great benefits of your, by this time, big understanding of what is needed in order to achieve true system collaboration for your organisation, doing changes and a transformation possible that will make your organisation flourish.

If this is the first blog post in this blog book you read, don’t worry, just read below and you will soon know the best way for yourself to digest the blog book.

This wrap-up blog post is divided into two parts, a conclusion of the whole blog book and a summary with a reading proposal how to best digest the 100+ blog posts. The blog posts are for you that want to understand the details, examples and consequences of the conclusion. Especially the consequences make it very clear that many organisations and/or their way of working have built-in organisational problems. To read the whole blog book can be of big importance, not because there is some rocket science in the details (rather the opposite), but because it is about the following:

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought.

• – Albert Einstein

This is really what this blog book is all about, a totally different way of thinking in order to very easy get rid of wicked and intractable problems in our organisations, but where the change of current patterns of thought is the hard part. It is about what Dr. Russell Ackoff called Dissolve a Problem [1], which means to change a system or its environment in order to dissolve the system’s root causes, and by this indirectly also dissolve the problems. Ackoff understood already in the early 1990s that many organisational problems could only be dissolved, but his track has not been continued on in the complexity theory since then. Why dissolving the organizational problems is the only possible way forward to get rid of organisational problems, is shown in the conclusion below and with details and examples in this entire System Collaboration blog book and will be referred to as Organisational problem-solving.

In the blog book we have from start differed between built-in problems and normal problems, which is very important when we want to get rid of organizational problems. Built-in problems means that they will happen sooner or later when we start our interactions in the organization, it is just a matter of time. Built-in problems are simply generated from our own malfunctioning system, our own way of working that is not good enough, or even really bad. Our way of working consists of too many unsolved root causes, i.e., too much unfulfilled organizational principles (science). Built-in problems will be visible for the organization at the start of the interactions, showing that our way of working is not well-functioning, where the symptoms if they are not taken care of, sooner or later will lead to consequences. Consequences are bad emergent properties and bad emergent behaviour, that in turn lead to unhealthy people and in worst case that people become burned-out.
Normal problems are for example the perpetual presence of Murphy, changed prerequisites, or the fact that we humans will make mistakes, even in the best of systems.
By having this division, we are able to divide between organizational problems depending on our own malfunctioning way of working, and normal problems that do not depend on our way of working, where normal problems most probably will occur even more in a malfunctioning. Toyota always improve their way of working, in order to respect their people, so they always can have the best current way of working.

Less important is that we can also show how to build an organisation from scratch, since the root causes of course are connected (root causes are the negated principles) to our total organisation definition with its principles, needed to make any organisation awesome. Why is that less important you think, since that sounds really neat? The reason is that with organisational problem-solving, we can prove that there is no short-cut method or framework, that can fix an organisation’s problems. Because, without asking for the problems in an organisation, the root causes cannot be found, which imply that these methods and frameworks try the impossible of solving symptoms. And if they could get rid of the root causes, they had if we have some second thought, for sure showed that instead of guessing. Because, so far, there has been no commercialized method or framework actually performing well*, since they are not removing the root causes. This was brought up by Ackoff already in the early 1990s when he talked about the non-working manager’s panaceas [2], which of course is connected to his Dissolve a Problem [1], in order to act systemically (and not only talk, like the panaceas do). Further down, it will be shown why Best practice doesn’t work, where Best practice is closely related to Ackoff’s panaceas. A summary of Ackoff’s thinking is:

A method needs to be built on theory from science and not speculation. If the author of the method cannot show why it is working by referring to valid principles, then it is an antisystemic panacea. Don’t use it.

Apart from this, another way for panacea peddlers to try to convince the world about a new fancy method is by using counterfactual conditions, CFs. An example of a CFs is:

If A had happened – which A did not – then B had happened.

which is obviously a false sentence, since A did never happen, which means we cannot know if B had happened. But, of course panacea peddlers, do not write the sentence in this rather clear way, no, they are treacherously mixing and tweaking until it is hard to see through. And if someone is questioning the short-coming, they will often be ridiculed, one of the famous master suppression techniques, or pointed out as negative to this new fancy thing. Finally, people will sadly give up, which is understandable since CFs are like trying to solve symptoms, which is the area where panacea peddlers are in their full flow, which is not a flow for adding value to any organisation.

But, with Organisational problem-solving, organisations can think themselves and get rid of intellectual con men or panacea peddlers, two different ways two state it, as Ackoff put it.

Conclusion
Organisational problem-solving has two important parts, organisations and problem-solving. Before we dig into these two parts, we need to have a common vocabulary with the same interpretations of important words, especially for the problem-solving part. A common vocabulary within an organisation, is a vital principle for any organisation with more than one person. This to have a decent and of course correct communication, in order to achieve the necessary interactions between the people within the organisation. Of course, this also includes not only the employees, but also customers, partners, consultants, etc. If we do not have a common vocabulary, we will have difficulties to even agree that we have a common problem, especially a systemic organisational problem effecting many parts of the organisation in different ways.

Here are some definitions of some important words in order to understand Organisational problem-solving, with the detailed explanation within the brackets, that are the references to well-known dictionaries:

• Principle [3] – a comprehensive and fundamental law, doctrine, or assumption
• Cohesive [4] – united and working together effectively
  (cohesion – (of objects) the state of sticking together, or (of people) being in close agreement and working well together or
  the act or state of sticking together tightly or
  the action or fact of forming a united whole.)
• Coherent [5] – having its parts related in an organized and reasonable way
  (coherence – the situation when the parts of something fit together in a natural or reasonable way or
  systematic or logical connection or consistency or
  the quality of being logical and consistent)
• Analysis [6] – detailed investigation
• Synthesis [7] – the composition or combination of parts or elements so as to form a whole
• Negate [8] – make (a clause, sentence, or proposition) negative in meaning
• System [9] – A system is a number of components (parts of the system) that work together for a common goal (/purpose)***
• System [10] – a set of principles or procedures according to which something is done
• Organization [11] – an organized group of people with a particular purpose, such as a business or government department.
  Note! It is important to state that the all organizations are systems, which makes the purpose common for all the people in the organization, a purpose that they strive for together. Each of the initiative (project) made by the organization on the other hand fulfils only a particular purpose, in order to fulfil the common purpose of the organization, or the organizational purpose. This is why “common purpose” has been used throughout System Collaboration in the definition of an organization.
  Note! All organisations are complex adaptive systems and hopefully successfully synthesised by following organisational principles (see System [10]) to a cohesive**** (like the actual interactions and interdependencies between the parts) and coherent**** (like the structure of all the parts) whole.
• Sub-optimization [12] – a situation in which a business is not as successful as it could be because one part or department works only on its own or only for its own success
  – can also be called anti-systemic
• Context dependent [13] – depending on context
• Context independent – not depending on context, context-free
• Problem [14] – something that causes difficulty or that is hard to deal with
• Narrative [15] – a way of presenting or understanding a situation or series of events that reflects and promotes a particular point of view or set of values

And as you can see for the definition of problem, it can of course mean many different things. A problem can belong to the activities we are doing when we are building our products and services, the WHAT, but also the reactive activities we need to do if we have made something wrong in our products and services. But of course, problems can also belong to our work we are doing to achieve our products, the HOW, which means that we also can have organisational problems. So, we need to start to sort these different meanings out, which is very very important, as you soon will understand.

Art Smalley, a Toyota Production System expert, author and former Toyota employee, states in his recent book “Four types of problems” (2018) [16][17], that problems can be reactive (caused) or proactive (created), where his focus is the manufactured products. Solving problems for products is very different from organizational problem-solving in focus for this blog book, making it impossible to without consideration use the problem-solving methods from finding and solving problems within products. We will go through the different types of problems that Smalley brings up, but as we can understand later, these four types of problems and their different methods for solutions, are made for product problems and not organizational problems. See the picture and the explanation of it, in the blog post explaining why Systemic Problem Picture Analysis – SPPA must be used for organizational problem-solving and not another common problem-solving methods. See also this blog post for the actual method of SPPA.

We have big difference regarding the repetitive manufacturing (always clear) on one side (WHAT equal to HOW) and non-repetitive product development (always complex) on the other side (WHAT not equal to HOW), but both are organizations. This means that there will be organizational problems, even though they operate in different contexts. So, we leave context out of the picture since we want to be able to handle any organizational problem. This means that it is important to add that System Collaboration finds these kinds of problems for any organization. And not only finds the problems, but also solves them, and where all methods and thinking are based on current existing science. Since the Systemic Problem Picture Analysis – SPPA, is an iterative and proactive method for finding the organizational problems before they become incidents, as well as that a malfunctioning way of working is caused by the organization itself, we cannot use the terms reactive, caused or proactive used by Smalley, since it would only be confusing. SPPA together with Systemic Organizational Systems Design – SOSD also makes a better way of working, which means that created is neither proper to use, which is why normal is the term that is used for organizational problems that are not built-in. Built-in is also a term that focus on making our system better, moving away from the thinking that people can be changed to fit the system. The built-in problems are in turn divided into symptoms and consequences, where consequences are very close to incidents, which makes them close to Smalley’s gap from standard and trouble shooting.

Smaller changes for improvement will normally be covered as a symptom in the SPPA, since our people also will bring up when they think we can do something better as a symptom. Here is where we can do continuous improvements, Kaizen, even though these kinds of symptoms normally are found at retrospectives for the teams and team of teams. And we need of course always to be open-minded for future disruptive transdisciplinary innovations (new systems designs) for organizations, and if, and only if, they also are following our organizational principles, they can make our organization better. That is easily judged with SPPA.

If we use Dave Snowden’s well-renowned Cynefin™ Framework, the solution to an activity, the WHAT (for example any activity when we are designing or manufacturing a product), can “easily” be mapped into one of the domains in the Cynefin™ Framework, when we use it as a categorisation model; do we have the knowledge to do it (obvious/simple), can we do some prototypes and get guidance from our experts (complicated), or do we need to explore because we do not have the knowledge yet (complex).

The built-in problems on the other hand have cause(s), meaning they are only symptoms of something deeper rooted. And as we know, symptoms cannot be solved, only their root causes, and root causes as explained throughout this blog book are the negated principles, further explained in the introduction blog post. And since principles are universal like mathematics, physics, logic, etc., meaning that they are valid for any context, organisational root causes are of course universal too, since there is only a negation done as well. Which with some further logic also gives that all symptoms are universal too, valid for any organisation (or product, etc.), which is the reason for the possibility to make a Prefilled Problem Picture Analysis Map. This means that we cannot put built-in problems or their root cause(s) directly in any of the general domains, and since it is not a crisis, not in the Chaotic domain either. But, the Cynefin™ Framework also has another domain, the domain of disorder. And one sub-domain of disorder is inauthentic disorder, where we will be as long as we do not know in which domain the solution(s) to our problem’s root cause(s) are. So, for built-in problems, we always need to ask multiple “why?” on them in order to finally reach their root cause(s), since then and only then, we can do WHAT (an activity (a new systems design)) to dissolve the root cause. Remember that only this WHAT, the dissolving of the root causes, is possible to be put in one of the solvable context dependent (can be placed in a domain in the Cynefin™ Framework), not the actual universal root cause. Finding the organisational (caused) problems can easily be done in a workshop or similar by collecting the narratives (I use the word narrative for the caused problems, many times used in the theory of complex adaptive systems, in order to have a common vocabulary) of the organisation, the good ones, but especially the problematic ones so we can find their root cause(s). If a narrative is presented as a series of events, we need to ask “why?” on every event, to be sure that they are not improperly connected (which is a common mistake) and continue until we find the root causes. And preferably these narratives are written down individually; an individual “yellow notes session” for 10-15 minutes will do the job perfectly, not only to make all voices to be heard, but also to avoid bias and that the facilitator is influencing the result. Then it is just to start to ask “why?” on every event of the problematic narrative to connect a lot of them and also to find the universal root cause(s), our negated principles. Note! Just because we call caused problems for events and narratives, does not change the fact that events and narratives originate from symptoms, meaning that events and narratives still cannot be solved.

Do not fall into the temptation to categorise the organisational problems/symptoms found into organisational units like units, departments, silos, or into other slices of the organisation like quality, leadership, virtual structures on different levels, or as in an Ichikawa (fishbone) diagram; People, Process, Tools, Program and Environment, etc. The reason is that the root causes to organisational problems/symptoms are in many cases common to many slices, and will therefore affect many slices of the organisation. So, any try to categorise the problems/symptoms, will make people think that the solution is to be found in the same frame as where the problems/symptoms were found. And framing the solution, no matter what kind of organisational slice it is, gives sub-optimization per se.

Once again remember that there is no “one size fits all” way of working, meaning that we neither can copy another organisation’s recipe, nor use the same recipe within the different contexts of our own organisation. Once again; context is king, as Dave Snowden puts it. The reason we cannot copy another company’s recipe, can be proved with this picture, same symptom different root causes:

A method claiming “one size fits all”, is normally pointing at common organisational symptoms on a very high level far away from the root causes, meaning the methods do not have a clue about organisational root causes. The picture above shows that the three different companies (A, B and C) can have different root causes to the same high-level symptoms that a method claims to solve. So, when company B, tries to copy company A’s method that successfully dissolved all the root causes for company A, the failure is inevitable with no progress at all, since no one of company B’s root causes are dissolved when using the copied method from company A. When company C, with extreme problems, copies company A’s method, company C becomes a little better, but probably not much, since many root causes still remain. Added can also be that if the method is introduced in the organisation together with other organisational changes that actually are dissolving some root causes, the result can be better than above, but once again only by luck, since trying to fix symptoms are impossible. Remember that the author of the method has no clue about organisational root causes at all, otherwise that for sure had been clearly stated. This is the problem with all commercialised methods so far, no one talks about root causes. Here below is an easy example of the same companies as above, with a picture showing the many different root causes to queues, here is the pdf file, queues of planned activities different root causes.

Many of the built-in problems are normally referred to as wicked problems, or intractable problems as Dave Snowden prefers to call them. And since built-in problems are insolvable symptoms, this means that we can directly neither do safe-to-fail experiments with multiple, oblique or contrary experiments, nor use set-based design, nor focus on extending the problem definitions phase (to avoid premature convergence; note that not even an eternal extension can solve a symptom, meaning indirectly that the convergence is premature anyway ;-)), nor situational mapping to nudge people in the right directions, nor change the constraint structure, etc. And since symptoms are insolvable, they are also uncategorizable (acontextual, i.e., meaning also that no one can be the owner, as Dr. Ackoff stated it) and this indirectly means that there is no method to use for their solution; we frankly need to find the root cause(s) first to be able to categorise and choose method. And all symptoms together definitely give a mess, a system of problems, as Ackoff would have put it. This also means that symptoms for sure will stand the wicked problem characterisation test*****.

Trying to categorise lead us to a catch with both Smalley’s and Snowden’s thinking, since they go directly to categorisation of the problems. But a problem as we have seen above, can never be categorised, since it is only an insolvable symptom that not even rocket science can solve. Cynefin™ Framework’s Confused domain (former Disorder) is of course a good start because we cannot ontologically categorise a problem. Without asking “why?” on it (as we need as stated above), we can therefore never find its root cause(s), meaning we can never find a solution to it. When we instead, by asking multiple “why?”, finally find the root cause(s) to built-in problem, their solutions on the other hand are a new systems design of the organization if it is a built-in problem, see this blog post about the theory behind SPPA and SOSD.

But we still have one thing we first of all need to do when we encounter a problem, even if it is normally easy to understand. We need to be able to distinguish if it is a built-in, a normal problem, or an activity to solve. Fortunately, this is simply to ask “why?”. If it is not a problem, i.e., we cannot find any answer to our “why?”, then it is just to solve it, and when it is a built-in problem, we need to change our way of working as well, to not get the same problem repeated forever.

After we now have defined the word problem properly, it is time for a dive into the word problem-solving in Organisational problem-solving. Here we will use the traditional “why?” questions, used in traditional analyses to find the root cause(s), but not only to find the root cause(s) to a single problem, but instead to connect all different problems within the organization and find the way down to all the current root causes. All the problems and their connection to each other and down to the root causes, gives us a systemic problem picture, and what we have done is a Systemic Problem Picture Analysis – SPPA, see this blog post for a deep-dive. This is also why traditional root cause analysis methods do not work for organizations, due to that they are not focusing on all root causes, instead only one or a few (normally a component that is failing), as well as they have never focus on the organizational principles, the science behind. This means that it is not enough to solve only the root cause(s), since all other organizational principles need to be fulfilled at the same time. It should also be added, that the articles within the System Collaboration Deductions series, also shows that any way of working, always is a systems design, no matter in which context we are operating in, which means that all science need to be fulfilled in our systems design. This makes it the same as when making a product, where all science obviously need to be fulfilled, in order to make the product fulfil the requirements. It shall also be added that since the root cause(s) always appears due to a mal-functioning system, and never our people, this means that dissolving (eliminating) root cause(s) always means a new systems design of our way of working.

The visual problems we can see in our organisations are almost always symptoms, and symptoms means that our visual problems, i.e., caused by ourselves, either built-in or normal problems. In the case of built-in problems, and since we know have the knowledge, this should be no surprise since we made the organisation ourselves, so if it does not work as expected, there is no one other to blame. Problems means that we need to ask multiple “why?” every time we find them to not only connect them to each other, but we can neither stop until we find the root cause(s) to all our visual problems. Since only dissolving of the root causes can dissolve the symptoms, a dissolved root cause is the truth. This also means that if we try to solve symptoms directly, that means indirectly a “lie”, since symptoms cannot be solved. Most probably, the intention of people that convince us that their solution of a problem (symptom) is correct, are (mostly) sincere, but even if they are innocent, the solution is still impossible and therefore a “lie”. In Swedish the expression “killgissa” (literal translation to English is “man guessing” (mansplaining is different)) [18] comes to one’s mind, which means that we are talking about things we actually do not know if they are correct or not. People that are “man guessing” seldom have a second thought or critical thinking, the answer comes to fast and they are very convincing. This means that dissolving root causes is a Walk in the Park, while solving symptoms with a method or framework (panaceas according to Ackoff) is a Walk in the Dark, since it is obviously totally out of Control trying to do the impossible. This is the reason why Ackoff talked about panacea peddlers. Here is a picture describing symptoms, root causes and their relation, and here is the .pdf file, symptoms and root causes:

If we anyway try to solve symptoms, more intractable symptoms will appear, at any time (can also be years later) and anywhere in our organisation. Especially existing root causes that generate symptoms over the whole organisation are really nasty if they remain for a long time, due to people trying to solve the symptoms. Not to mention all time our people are wasting when they are trying to solve symptoms, and most of the time also the same symptoms, but at different places in the organisation. Much ado about nothing.

Sometimes though, we need to take care about people that are stressed or having lost their power, or in worst case are burned-out, which is WHAT to do, and is of course important, even though it is actually not solving the root cause. Wiping up the oil under the car is another WHAT to do, but is of course not solving the actual problem with the leaking oil from the motor. These are incidents that we need to take care of.

Here is an example of a done SPPA, where the smaller boxes are symptoms (some boxes are root causes that are finally found later in the analysis). This is to show how easy it is to have a Walk in the Dark, not knowing what are symptoms or root causes, not to mention all people’s time putting actions on the different boxes. Here is the .pdf file, problem overview.

But, when starting to ask “why?”, as in this picture below, we start to understand on which boxes where we shall not put our power, since that is totally meaningless and only a waste of time, since they are only symptoms. It looks like this, the .pdf file is here problem overview – with why:

The arrows point finally at the root causes. If we add some colours to the boxes it would look like this, with the .pdf file here problem overview – with colours:

The white boxes above are facts, meaning that you need to accept it, for example when you have customer issues that need to be looked into immediately, even though it is interrupting the flow in the team’s sprint.

Note that every symptom and root cause are context independent. It is not until we ask what to do on our root causes, it gets context dependent, since we then are trying to dissolve the root causes. This means that anyone without knowing the organisation’s context can help doing an objective investigation of an organisation’s problems. So, it is not until we actually are dissolving the root causes that organisational knowledge is needed, even though guidance and support most probably is possible, due to the similarity between the solutions.

An organisational root cause and the found Visual problem (symptom) can also be separated in time, in fact by several years. No measurement whatsoever can understand or solve these kinds of problems. Below is from a SPPA done back in 2010 at a big Swedish telco. From the problem found in production to the root cause at product management, the chain is 13 “whys?” long, and it took 1,5 years from the root cause until the problem appeared. And here is the .pdf file, 13 “why?” asked.

But, to have some problems in the organisation, why bother? We humans are adaptive, so we will get some results anyway, right! Yes, we are, but the thing is that unsolved problems do not make us awesome and also give more problems, and at the same time the market is changing. Not to forget that skipping the systems design can be disastrous. The risk, when having unsolved problems is also that we can get into loops like this; is the team stressed because of the bad quality, or is it bad quality because of stress in the team, which is an easy example of a Wheel of Curse. The solution is of course always to make our Problem Picture Analysis, that finds the root cause(s). Here is another, bigger example, that is more difficult to see through, with .pdf file here, the wheel of curse:

With the market getting faster and more uncertain for every year the last decades, the wheel spins faster and faster, making it harder and harder to escape from it, due to less and less time to fix the organisational problems. Everybody in the organisation get more and more busy, and the organisation starts to look like a fire brigade instead. And if our competitors understand how to solve their organisational problems we are in very deep trouble.

Bad flow in the wheel above is only one of the results when having organisational problems. Other purposes****** of the organisation, still from a universal, context independent view, is for example; right product, fast time to market (actually related to flow), right product cost, right development cost, right quality, etc. If we add these to our Wheel of Curse, we can see that all the organisational problems make our organisation go in the wrong direction. Here as a .pdf file the wheel of curse with result:

Unfortunately, it does not stop here. Since root causes can be found far from the original problem, both in place and time, it means that the root cause is easily outside the “problem owner’s” area of responsibility. This means that the last symptom that is inside the “problem “owner’s” area of responsibility, erroneously becomes the root cause. This is a common consultant trick, to frame the problem so it looks like a solution has been found within the frame: But, in turn this instead means that the root cause will never be found, since it is never looked for in the first place. This means a clear sub-optimisation trying to solve the symptom within the frame’s boundary. And trying to fix insolvable symptoms will, yes you are right, give us more treacherous symptoms. And we will not know where they will show up, or when. The consequences due to the existing root causes of today’s organisations can also be seen in job advertisements, where the applicants need to; work well under pressure, have eyes in the neck, be able to juggle with many balls, think out of the box, turn around stones outside reach, etc.  We add consequences to our picture of symptoms and root causes and here as a .pdf file, consequences.

If we add that to our Wheel of Curse, it will finally look like this showing some of the endless consequences that easily occur, making the organisation coming very far away from achieving its different purposes, here as a .pdf file the wheel of curse with consequences:

And here is when Ackoff’s panacea peddlers enters the arena, telling the organisation that they have the answers to all the problems, showing power point slides that even the peddlers believe themselves. I mean, who does not want the following results; better flow optimisation, the right product, more innovations, less cost, etc.? Everybody does, so when you are questioning the logic behind (since they are trying to solve symptoms) to get the result everybody wants, you are easily treated like a negative person, since you have not been swept away by the sweet talk. This is exactly what Mats Alvesson and Andre’ Spicer write about in their book “The Stupidity Paradox: The Power and Pitfalls of Functional Stupidity at Work” [20]. The impossible or even stupid things have become a non-questioned fact, since peoples’ critical thinking and reflexion seem to have been wiped away. But still, trying to solve symptoms are impossible, meaning that not even rocket science can help us here. That is why we put the none-truth like this instead; “Lie”, because it is impossible to see through that the solution presented isn’t a solution, that it is in fact only man guessing. But it is still not the truth, even though it is most of the times not deliberately done, and since it will not solve anything on the wholeness, it is only sub-optimising.

A harder nut to crack, is when some parts of a method or framework is really removing some root causes, but where other parts of it instead increase the problems totally within the organisation. That is why it is so important to ask the following question when we add something new to our organisation; what root causes are we getting rid of, if we add this? If we cannot see any root causes disappearing, we need to be cautious, since it instead most probably will add new problems, we did not have before in the organisation.

Beware also of measurements, since many measurements sub-optimise the organisation, since when done on parts, the success of the whole can never be guaranteed. Also, gaming the measurements are very easy. If we for example measure efficiency, we will for sure instead of doing the right product faster, with high risk suddenly do the wrong product faster. Which most probably was not the intention. The only way to make the right product faster is to dissolve the root causes, and systemic measurements will easily show that. In software product development with Customer Pull, we have complexity and complicatedness within our work, making measurements very tricky. This can be compared with the traditional hardware development projects with Technology Push, having done all the innovation and experimentation before the project started. This meant also that the complicatedness was understood, adding up to some prototypes, but still under control, since output and outcome were pretty much the same.

Now after we have understood the problem-solving part, and why it is needed, we will now examine the word organisational in Organisational problem-solving, which tell us that we need an organisation. And a reminder is needed, to emphasise that every organisation is a (complex adaptive) system, which means that it indirectly will have a system specification or system definition, where the aim for the system is to achieve something, a goal or a purpose. And do not forget that every system is a number of components that work together for a common goal. In our organisations, these components are ourselves and the activities we are trying to solve to achieve the purpose of the organisation. From our definition of organisation in our common vocabulary above, we can make it a little more specific since any organisation will solve activities and will have interdependencies between the activities. We can write it like this below and notice that it is still universal, context independent, which is important since that makes the definition valid for any organisation.

People that interact to solve activities with interdependencies for a common purpose.

But this definition won’t help any organisations to become awesome. Actually, we will go backwards in time a couple of 100 000 years, since our ancestors know a lot about themselves in groups and communities, as well as about the activities they handled and structures that helped them handle complexity. And the science for the last 100 years has explained the reason why our ancestor’s communities, families, tribes, clans, etc, had their size, as well as those activities can be obvious, complicated or complex and many more things. These babies we cannot throw out with the bathwater, so let us instead dig into them and make a definition of an organisation that take them into account. We start with the activity side, the “hard” side, before we dig into the people side, the “soft” side.

Activities cannot be done randomly; we need to follow certain steps. We can complain and say that development according to waterfall is slow, but anyway, certain steps need to be followed, the tests cannot be done before we have written the code, even though we can write the test before the code is written as in TDD/BDD. For sure we shall also incorporate test knowledge into the loop making testing easier, but still, test needs to be done as the last step.

We also need to understand the complexity of an activity. The more complex the faster feedback we need and the more uncertain our predictability will be, a too complex activity may not be solvable in a reasonable time regarding current unknown knowledge. Complicated activities mean that we know that we can solve the activity with the help of experts. Probably we need some prototypes/iterations to get it right and where we get new knowledge after every prototype/iteration. Obvious activities we know exactly how to solve.

The different complexity of the activities, means that we need to have timely Integration Events where we for example integrate, verify and validate our work done so far, to get feedback on the parts, the wholeness and of course also from the customer. Of course, we need to have Built-In quality to as high degree as possible, but we always need to verify and validate the wholeness, since successful verification and validation of each part, does not sum up to a verification and validation of the whole product. Sometimes agile software development tries to skip this last vital step, where especially an erroneously specified system, which can have the most severe errors, never can be found with Built-In quality thinking. Changing the name of the parts of a system from the traditional subsystem or sub-subsystem, to value streams, features and user stories, will not change anything. Built-In quality on the wholeness can never be achieved, and writing a White Paper that states that it is not needed, won’t make the need of verification of the wholeness to vanish just like that. All things done on the parts (optimisations/verifications/ validations, etc.) do still not aggregate to an efficient and effective whole in product development, even though it many times work in manufacturing. Context is always king.

Structure is a leading star for us humans, not only the planning structure, but also the architecture. During mankind, we have also understood that architectures of pyramids, houses, cars, circuit boards, are a good way to handle complexity for us. From Conway’s law [21] we also have that communication structure gives architecture. This means that teams sitting close to each other, not working on parts next to each other in the architecture, have the risk of changing the interfaces in the architecture.

Now over to the “soft” side of the definition of our organisation so far. First of all, we need respect for people on all levels of our organisation. In order to solve the activities within our context, we of course need to have the right specialist competence, commonly referred to as I-shaped competence.

The latest 100 years, the science has shown many different group sizes which we need to follow. We have 5 as the maximum number of people in a Group having the same competence, splitting the same task, to avoid loafing [22]. 15 is the number of trust and sympathy [23] we can have within a group of people, and 150, Dunbar’s number [24], is about a stable social (inter-personal) relationship, the maximum number of people that we can remember name and face on and how they relate to all other persons.

We have Miller’s number 7+-2 [25], which is the maximum number of things we can keep in our short-term memory. So, when the children play the Chinese Whispers game [26], it is not a surprise that for every Child the story passes, the story changes due to the inability to keep the whole story in the short time memory. And the story does not only get corrupted, it takes also long time for the story to pass from the first child to the last child. All this together gives us that we need to keep our chains of interactions as short as possible, otherwise we lose time and information during the chain. Start up and close down of activities are costly, and the smaller activities, the longer the chain of interactions will be for sure, giving a bad flow of the activities through our organisation. Many small activities also give that our employees will be part of many projects, which for certain will give queues of planned activities to our employees, killing the flow totally. Flat hierarchies, especially for the actual work are therefore key, as well as T-Shaped competences, to reduce the chains of interactions and queues of planned activities, both in length and amount. From this it is also easy to understand Go to Gemba, or Go to the Source, that Toyota, or at least the Toyoda family has done for more than 100 years, to avoid intermediates corrupting and slowing down the information.

Back to structure again, where we can see that the above number for different group sizes give us a line structure, where we have control of the needed different I-competences in the organisation, and a virtual working structure where the actual work is done. This setup gives great flexibility to meet the market changes and problems occurring during the work. We can call it to move people to work in a virtual structure, or move work to people in a virtual structure, it is just a play with words, the importance is that we have a virtual structure giving us flexibility.

The purpose in the definition, sets the way of working, since our organisation will perform very different activities depending on if it is product development or manufacturing, complexity or not. Purpose is a context independent constraint, it is always present, or context-free as Alicia Juarrero would have put it [28]. Purpose together with shared understanding and goal is what is called positive context-free constraints.

If we sum up the above, we now know how we can make an awesome universal organisation, so we add that knowledge from science to our definition of an organisation and we get the following:

Respected people with a common vocabulary, working full-time in a flat hierarchy of teams founded on the numbers 5, 15 and 150, also in the light of Conway’s law, with the right specialist competence, and understanding the Cynefin™ framework and Conway’s law, that iteratively and in parallel if needed, interact freely and end to end over the whole organisation in as short chains of interactions as possible, giving them the necessary broad competence to also directly take care of organisational problems as well as do continual improvements, and therefore be able to efficiently and effectively solve, by also exploring in close collaboration with the customer and end user to gain new knowledge, activities with interdependencies, fully planned and under control, to be able to build the system product or service, incrementally if possible, always with the appropriate architecture under control and responsibility and always with timely Integration Events with verification and validation depending on context, to get just-in-time feedback, where also the long-term critical line, activities, interdependencies and Integration Events are fully under control, and visualised as well, to achieve the purpose.

Splendid, right. So, for any organisation we build, we need to follow the above organisational definition, built on currently known science, in order to make our organisation both cohesive and coherent in any part of it, as well as on the total of it, to make it awesome.

As you can see there is nothing about, trust, mindset, values or culture. Isn’t that important, you think? Yes, of course it is, but they are the outcome from the interactions between the people within our organisation. It is the same regarding quality that is an outcome from the organisation and is nothing we can wish for, or set a goal for and then try to close the gap to. This means that putting up the cultural values on the walls won’t help us. And since the interactions are done between our people, the culture cannot be found inside the walls either. But you think, we can find the culture at the breakfast table, eating strategy for breakfast. Sorry, not even there. It is the absence of organisational changes in a “bad” organisation, that can deteriorate any strategy. If one of the parts in the strategy’s aim is to change the culture, without changing the organisation so that the interactions can change, culture won’t change. Or as Dave Snowden states it; “Just as people think they can render a culture into a set of platitudes in a value statement, when real culture is evolved practice over time, not fully understood and never fully articulated.” [29].
The Hawthorne effect [30], that people change under observation, can give some short-term positive effects for easy tasks, but for complex tasks the effect is negative. That is why too much transparency can hamper innovations, since innovation means experimentation, which means many fails, and no one that may fail wants management to observe that. That is “101 anthropology”, as Snowden would have stated it, but unfortunately when organizations fail, they start to measure and control, instead of solving their problems.

Now we have explored both organisations and problem-solving and it is time to combine them. Because, if we fail to achieve one or more of the sciences and common sense above, an organisation will clearly have big problems, due to that our abilities have limitations. We cannot of course explain exactly what problems an organisation will have, but as you now probably understand the root causes will be the non-fulfilled science already discovered. And due to that our definition of our organisation is context independent, the root causes are the same for any organisation. It is not until an organisation tries to dissolve its root cause(s) by SOSD, we are in the Complex domain, redesigning our organisation.

But, hey there someone may say. In complexity theory there is stated to be no cause and effect, how come we can find root causes in our organisation, our complex adaptive system? Remind from what was stated above that these organisational problems are built-in problems, they exist no matter we starting the interactions or not, but we of course need to start the interactions to make them visible. And since they are built-in, there of course will be a chain of symptoms from the root cause to the visible problems, meaning we can ask “why?”, to come back to the root cause(s). But we can also take it from the following angle. We humans are adaptive to be able to solve different problems (built-in or normal), but we cannot change science (our DNA, logic, etc.). This means that no matter what system (including organisations) we make, as long as we use components that cannot fulfil the system’s specification, the system can only work as expected if the components can upgrade themselves. Our adaptiveness will in some cases, if we are lucky, make our “bad” organisation to work improperly, compared to a product with the wrong components that most probably won’t work at all and definitely makes the customer very unhappy. But, an organisation, may still have some, but degraded performance, depending on how (and which ones) many existing organisational root cause(s) we have. For example, in a complex context, like product development the risk for total failure is very high. The misunderstanding is that adaptiveness can make us fixing the limitations within our own DNA, which is impossible. This means that as long as we do not fulfil our organisational definition to the better, i.e., do Ackoff’s dissolving a problem and re-design our system, the root causes will remain. Remind also that narratives that is never in real-time either, play an important role in complexity theory, where a narrative of course can be a problem. This means that a narrative in an organisation is something built up over time and is rather constant, same as problem. And as stated before; a common vocabulary is of great importance for solving transdisciplinary and systemic problems, that organisational problems of course are part of. See this series of blog posts for a deep dive into that matter.

Let’s take an example with an organisational problem. A common problem in agile product development is queues of planned activities on the Kanban board within a sprint. Let us examine that thoroughly. We actually start one step before the queues, when we have bad flow through our organisation. Some organisation does not even ask why they have bad flow, and instead start to control more, more governance, more measurements, etc., which will generate even more and more severe problems, since they are acting on a symptom.

One answer on why we have bad flow is queues of planned activities. This is Agile’s Achille’s heel, since very seldom why we have these queues is asked. Instead WIP Limits are put on the different Kanban board columns in order to decrease the number of work and thereby increase the flow. The problem with this is that the queues hide problems, since the activities that cannot be handled have a reason for that. Another common thing is to decrease batch size, i.e., the size of the feature or user story in order to receive faster feedback. But, as you remember, the thing we really need is timely feedback, which depends on the complexity of the activity; obvious, complicated or complex, nothing else. We need to understand that and not decrease the size randomly just because we do not understand what we are doing, which is obviously the root cause to this behaviour.

Since these queues of planned activities are to people, we have both the soft and the hard side of our original definition of organisation, meaning it should be more than one answer to our “why?” questions. One answer is that we don’t have the right T-shape for our people and the other is regarding planning and can be bad planning of the activities or the dependencies between the teams and/or experts etc. A comical part in agile is when there is an activity on a Kanban board column, but no one there to solve it, since agile make fun of the traditional resource optimisation problems. An activity with no people there to handle it, is really bad flow, but good resource optimisation.

Here is a picture describing the above, that also goes into more details regarding the planning and here is the .pdf, symptom example – queues of planned activities with consequences:

For more explanation about the variability chain of symptoms, please see this blog post for a thorough deep dive.
Measurements as in the picture above is many times really contra productive. In the same way as inspections will not make the quality of a product better, the same goes with measurements. When you measure, it is already too late, you cannot get faster or get the right product by having measures, especially not the latter. Instead, measures are treacherous since they easily sub-optimise, meaning bad side effects, and/or is easy to game. One example is to measure number of features delivered in a certain amount of time. The risk is then that the features are made shorter and then it will look like that there is a great progress.  And if someone erroneously think that smaller batches are always better since feedback is faster as described above, they think that a better measure and smaller batches is the perfect match. An objective question is then; why didn’t you have a smaller feature size from start? And don’t forget the risk of sub-optimisation when user stories and features repeatedly get smaller, since in product development, reduction and aggregation has never been valid as in production. And will never be neither.

Instead of measures we can follow Toyota thinking, doing continuous problem-solving and Continual improvements on the parts and wholeness, but only measures on the whole factory. They know that any problem-fixing or Continual improvement on the parts/teams or the whole factory, is the one and only way to make Toyota better on the whole factory, so why measure the teams’ efficiency. By measuring on the whole factory, Toyota avoids both gaming and sub-optimisation, where the latter is harder to do in production compared to product development.

If we now start to think of our root causes, we realise that we have a big problem. Our only root causes are limitations within ourselves, or that activities need to be done in a certain order, or the that we need to understand complexity. And we people are the one we are, people. We simply cannot solve the root causes we found, because we cannot change ourselves. And this is exactly what Dr. Russell Ackoff meant when he talked about the concept of dissolve a problem. We simply need to change the system (organisation), our way of working instead. And as you also realise, change the organisation is exactly what many methods have tried the last 70 years, but no one of the commercial ones has been successful, which Ackoff calls manager’s panaceas as described earlier in this blog post. And as you can see in the example above, there are some organisational hiccups in Agile too. So, what do these methods do wrong. Let’s try to explain it with a picture, here as a .pdf file, no analysis – no design – false synthesis. The way of working in the organization can never be built up of the wrong components, since we people are what we are, that is the black boxes. People can of course make mistakes, but they are never wrong. A red box means a failing organization and a green box means success.

The picture above is only the final picture, so here is some further explanation. From start we thought our organization was in the top right corner, but actually we were in Chaos according to the Cynefin™ Framework, so the initial start condition is a red box in the right corner and all other boxes are black. We always start in the top left box if we make an analysis, as if the people in the organization have caused the problem ourselves. As you can see in the picture, methods seldom analyse, and almost never deeply enough, an organisation’s problems (since they never even ask for the problems within the organization), and therefore cannot find the organisational root cause(s). And without finding the root cause(s), we have no new input for a systems design of our organization that eliminates the root cause(s) and still fulfils all other organizational principles. We can therefore only make a random synthesis (not an integration, only an aggregation in this case, since no systems design is made) on chance of our components (ourselves) in the organisation. This means we are once again making a system that is not working, but this time we know that it will not work, so we are from now on in the right bottom box. This means a Walk in the Dark, where we can loop for eternity, the box will remain red. This means that the top right box also will remain red forever, since we are trying to do the impossible, to solve symptoms. Instead, we need to do according to the below picture, heading for the root cause(s), the reason for an organisation’s problems. Here as a .pdf file, analysis – design – synthesis with SPPA and SOSD.

The picture above is only the final picture, so here is some further explanation. From start we thought our organization was in the top right corner, but actually we were in Chaos according to the Cynefin™ Framework, so the initial start condition is a red box in the right corner and all other boxes are black. We always start in the top left box with any analysis, as if the people in the organization have caused the problem ourselves. And this time we start with our proper problem picture analysis, which makes it possible to find the root cause(s), and we understand that our system was wrong and no mistakes had been done, which puts us in the right bottom box. So, now we make our systems design and synthesis (integration) to eliminate the root cause(s) and of course still fulfil all other organizational principles. This makes us ending up in the top right corner, making it green as well, since now we have a new successful way of working. This is the only way to do it, to re-design the system, i.e., Dr. Russell Ackoff’s Dissolve a Problem, which instead will give us a sunny Walk in the Park.

Do not forget that our adaptiveness as humans, makes our organisation a complex adaptive system, which means that we will always get some degraded outcome from even a low-performing organisation with many problems. But, at the same time our adaptiveness can of course never solve our organisational problems (symptoms) because it is impossible to solve symptoms. But, our adaptiveness can neither remove the root causes, since the root causes are limitations within ourselves, so we need to redesign our organisation. This means that every time our organisations do not fulfil our organisational definition, we have built-in organisational problems (symptoms), that only will get worse if we try to solve the symptoms directly. These organisational problems will for sure give us narratives, which are really easy to grab at any occasion.

We can, as stated before, also build an organisation from scratch, since we have the definition of our organisation. Already now I think you understand that a good organisation will be a true mix of agile product development, Lean product development and the traditional organisations with projects, the first good at the soft people side and the last good at the hard activity side and scaling, and the middle is good at both. And it does not matter if we build the organisation from scratch, or by organisational problem-solving, both are terrific ways to make an awesome organisation.

And as you were promised from start, no rocket science in sight, only this:

Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought.

– Albert Einstein

Summary with reading proposal
Below is an explanation of the details of this blog book and a Reading proposal how to best attack the parts at your interest.

Apart from the introduction blog book post, the common sense series is the starter, since everybody can relate to common sense. With the explanation of our organisational changes during history, human science and also Toyota (Lean) thinking, our common senses are really backed-up of reasons for the needed change of our organisations through the history, as well as how the limitations of us humans have affected the historical organisational changes. The limitations of our human cognitive ability have become very visible when the organisations try to follow the market of today that is fast, flexible and with products requiring more complexity handling to achieve. A big difference between us humans and (most) other animals is that we can intentionally or mainly subconsciously, in our organisations, violate our own cognitive abilities. This will then give us organisational problems, where this violation is the root to the problems. These problems can therefore only be solved by fulfilling the cognitive abilities again, even though he only stated that methods were anti-systemic and therefore could not work.

Dissolving problems combined with the principles regarding the limitations of our human cognitive ability are the top insights of this blog book, meaning also that our organisational problems are really easy to dissolve. This is because the root causes are our negated principles, meaning indirectly that any problem that we do not understand why we have, is complex (organisational or product), since it is only a symptom of the original root cause(s), and it is therefore impossible to directly solve. This also means that all root causes are always very easy to dissolve, and when we are lacking root causes, we experiment to gain knowledge. But, in our case, we have our set of principles since the needed human science for problem-solving already is there. As soon as we violate one of more of these principles, we will have organisational problems we cannot get rid of, they will remain year after year; no situational mapping, no continuous improvement can help us, since these methods are operating live in the complex domain with a real time organisation where the former do intervention’s, leading to even more unintended consequences that cannot be understood, and the latter are trying to indirectly solve symptoms by experimentation. The only thing that can help is to fulfil the principles, or dissolving the problems, by dissolving the root causes to them.

As already stated, these principles have a strong connection to our common sense, things we already know, like basic understanding. Respect for people is the number one common sense, closely followed by the need to solve our organisational problems. But organisational problem-solving is directly related to Respect for people, because if do not listen and not try to solve the organisational problems our people bring up, we show disrespect indirectly. Problem-solving (Jidoka) is one of the pillars for Toyota, and they know since more than half a century that if they fail taking care about their people’s suggestions to make Toyota even better, they will fail the Respect for people pillar. But problem-solving can never ever be mixed up with Continuous Improvement and doing so for product development instead means that we create a mess for ourselves through sub-optimisation of the parts.

Another insight is that we need a common language on the top level of every discipline, and not some discipline specific language when we mean the same thing. Without this common language on the top level, we can never work transdisciplinary. Of course, we need specific and detailed language when we dig into the respective discipline, but not on the top level.

There are many other insights as well, some more contrary to today’s thinking, than others. For example, unknown unknowns with friends have due to extensive reasoning and logic been reshuffled within the domains of the Cynefin™ Framework. Also, the top insights above those organisational problems will not go away if not the principles are fulfilled, is not what complexity theory is proclaiming. This is since its theories for complex adaptive systems for three decades or more, clearly states that in a complex system there is not any cause-and-effect chains. The problem with that statement is that it only regards live (real time) systems, not systems with inherent problems from start within the organisation definition (dead system). Here instead, the effect and cause chain (backwards) for organisational problem, by asking “why?” on the effect, easily can be found all the way to the root cause(s). Of course, only backwards to the root causes since we do not know the future. But, most probably we can understand the doomed future with more and more inefficiency and ineffectiveness and unhealthy people (due to our human adaptability to try to get the job done anyway) within the organisation, if the principles are not fulfilled.

The last important insight to mention is the tight connection between resource and flow efficiency. And the term resource efficiency we need to rethink and understand as an efficient use of our resources not just filling their time with work. This means that we need to look if they are adding value, and not only doing administrative stuff, in the same way as we are defining flow efficiency; are the flow units in a queue or are someone working on them. By having the same definition with adding value or not, it is easy to see that they are tightly connected; a queue of activities waiting for people to handle them, or a queue of people waiting for handling activities. Specialisation in product development will always give long queues of activities for the specialists, or many specialists need to handle every activity. Specialisation is not only a major problem in traditional silo organisations, just look at today’s queues of activities on the Kanban boards in Agile development, where the latter queues also are due to tremendous planning problems in Agile development, which is the other root cause to queues of activities, next bad T-shaping (specialisation).

The way forward for your organisation can be found in the System Collaboration tree hierarchy, since you should present the same knowledge as you now have yourself, all to get an exponential speed-up of the transformation:

The tree hierarchy connects the different series and blog posts with a main track and a deep dive/example track. The .pdf file also has the links to be clicked on to access the respective series and single blog posts directly. The tree hierarchy has two main tracks and that is finding the principles (to the left) respectively finding the root causes (to the right). With these two different perspectives, we will in the end understand that they really mean the same, that the root causes only are non-fulfilled science. The principles are found from co-evolving of organisations and the market, which lead to tasks we need to do in our way of working, and the root causes from the fact that organisational problems have root causes.

The granularity is very important, since we people are made for collaboration in our system (organization, society, family, etc.). This is the reason for the system definition “People that interact to solve activities with interdependencies for a common purpose.” for an organization. With the granularity of people and activities it is not only domain independent for any organization with this definition of an organization, but it is also context independent, as long as we are not setting the context. System Collaboration are focusing on making a system where the people can thrive, and we are not digging into how people are as individuals, which we never should do, i.e., it is always the system to blame. We need to keep Deming’s word in mind all the time; “A bad system beats a good person every time.”, which means that we cannot recruit neither “the best people”, nor “the people with the right mindset”. The former because in a bad system we do actually not know what competences to recruit, and the latter because a bad system will deteriorate any mindset to become the wrong one, i.e., we can never put the mindset “rules” on the walls. Regarding the activities, we only need to know the complexity of them, not actually the domain of them, when making our way of working. The more complex context we have, the more of our organisational principles will be activated, which regards both the principles for us humans and for the activities, and therefore will be added to our system definition for the context (i.e., different system definitions for different context). This indirectly means that fewer solutions for our way of working will be available the more complex the context is, in order to be able to fulfil the organizational principles, which are also concluded in System Collaboration Deductions. A good image or parable to have in mind, is the many and very different solutions that are possible for boats, from canoes to the enormous container ships, and the few very similar solutions we will have for moon rockets. But remember that solutions for any context for our organizations, only are on the granularity level of humans and activities, following our organizational principles and the deductions made in System Collaboration, which means it is overarching and not more prescriptive than necessary. This gives plenty of room for the organisation themselves to make the details of for example the different team constructs, when we are entering the domain of the organization, which of course the organization itself also knows the best.  A general rule is that the more complex context, the more non-prescriptive we can be regarding the interactions between our people, which is one of the reasons for the need of a virtual delivery structure to avoid sub-optimization. Reducing complexity always means to find new knowledge, which means that we never can specify our people’s interactions in advance, but where a clear context can be very prescriptive since it is all about repetition. Another conclusion that can be made is that this means that a system definition always includes the organisational principles for the context, but where the system definition for a specific context still is domain independent.

Below follow some guidelines on how to achieve the change or transformation, discussing from the point of view of Kotter’s 8 steps for change. Remember that Kotter has built his steps agnostically on implementing any method. This means that there is seldom focus on what problems an organisation has and asking why the organisational problems exist. This agnosticism also means that, if transforming to something completely new, no one is asking if the new method or framework will actually work for the organization at all in their context, as well as domain.

This means that the first step about urgency is not needed in the same way, since by understanding not only that the organisational problems exist, but also how they easily can be solved and that no method or framework is pushed on the employees. That will make the vision and the strategy well connected to the organisational problem-solving and the needed organisational changes, meaning they will be attractive and understandable for all employees. We have achieved a Pull from the employees, instead of a Push of a method we cannot fully explain to them, on them.

Of course, HR also have a big role in these early steps since salary, bonus, knowledge, competence, careers, etc. need to be changed, and to be proactive and explain these changes in advance for the employees, will build trust all over the organisation.

To explain the why is the main focus of the coalition put together for achieving the change. This means that there is also another vital difference compared to Kotter’s steps and that is that this time the coalition is focusing on educating, mentoring and coaching the organisation to understand themselves how to make the change or transformation. The coalition will of course guide the organisation’s different parts how to implement their respective solution in their own contexts, but it is important that they as soon as possible can coach themselves to a great extent. By securing that the whole organisation understands the why, means that they understand themselves what changes to do, meaning that the coalition can stay small. Unfortunately, introductions of many methods and frameworks today, instead requires more coaches due to not taking care about the organisation’s original problems, and in fact introducing more problems. Adding more and more coaches or coordinators at the end of the transformation, should be a warning flag for any organisation.

By just doing their work after the changes, the employees will automatically fulfil the vision, due to the tight connection between the vision, strategy and the actual changes done in the transformation.

Short term wins can be seen directly all over the organisation, since the transformation can be done all over the organisation at once. This is due to that root causes are removed, meaning we know that it will be better, i.e., we have not copied someone else’s method, framework or way of working.

Sustaining the change is also easier, since everybody has understood that organisational problem-solving is vital, it is really common sense. What is important to understand is that we have changed the system by dissolving the problems within it, meaning that the culture will change to the better automatically at the different contexts within the organisation. There is therefore no need to push out (and must not be) values of how people should be. These value statements (on the walls) are also easily gamed by the employees, which means that it will take even longer time, and more people will be employed that learnt the game, until it is understood that it did not work this time either. The new system with its new ways for people to interact will give the new culture automatically over time depending on context, most probably a short time, the easier the context is.

With this organisational problem-solving thinking, there is not many more guidelines that can be given, since every change depends on context. The educators, mentor and coaches secure that the different parts of the organisation understand why the change is needed. And understanding that respect is vital, but also that ignored organisational problems, easily leads to disrespect, and that the organisational problems then are never solved either.

Everything has an end, and so does also this blog book have now when it is finalised after 121 blog posts. But it has been an exciting journey over almost three years 2017-2019 and +5 000 hours of research (full time), not to mention the pre-research done that equals another +10 000 hours of theory, but mainly practice during the Lean Product Development pilot at Ericsson 2011-2016.

I guess I will continue to update the blog book continuously with small changes, probably sometimes also add a new blog post or two, since I still have a lot of unpublished material and answer comments if there are some.

But now, since the research have come to an end, I have more important things to do, since I am starting at a new employment 2019-08-19.

With what?

Transformation of course, so the research is more than appropriate for that :-)!

My final words, summarising this blog book regarding the achievement of flourishing system collaboration for your organisation, is:

There are only sub-optimising methods and frameworks to buy,
and that is a dead-end path,
no matter how convincing con men and panacea peddlers are.

So, you can only help yourself with your organisational problems.

But now you also know that it is actually easy.

And apart from that it is the only way forward, it is also for free.

 

C u around.

 

*Toyota(/Lean**) Product Development, is not commercialized, but it is truly systemic, following our total organisation definition almost perfect.

**since all methods and frameworks in agile product development that is referring to Lean, is actually not (even close) to follow the Toyota principles, the usage of Lean has really been abused. The real Toyota principles take care of the wholeness, the set of principles are systemic, so there is no possibility of cherry picking among the principles, or picking some low hanging fruit. Here is a series of blog posts, going through Toyotas set of principles.

***an example of a system definition for an agriculture system can look like this;
“An agricultural system is an assemblage of components which are united by some form of interaction and interdependence and which operate within a prescribed boundary to achieve a specified agricultural objective on behalf of the beneficiaries of the system. ”
http://www.fao.org/3/w7365e04.htm

****cohesive and coherent can be seen like this. The line (static) structure is the coherent part of the organisation that keeps the organisation together and the virtual (and flexible) organisation, like a project or another working structure, need to make the interactions between the people cohesive. From this we can understand that in production cohesive and coherent are very similar since the HOW is equal to the WHAT in each process, as well as that the hard part in product development companies is to make the organisation also achieve cohesiveness (same as cohesion), especially at scale.

*****Thus, wicked problems [27] are also characterised by the following:

1. The solution depends on how the problem is framed and vice versa (i.e., the problem definition depends on the solution)
2. Stakeholders have radically different world views and different frames for understanding the problem.
3. The constraints that the problem is subject to and the resources needed to solve it change over time.
4. The problem is never solved definitively.

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

References:
[1] Ackoff, Russell Lincoln. Biography. Link copied 2018-12-15.
The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem. Such a design incorporates common sense and research, and increases our learning more than trial-and-error or scientific research alone can.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/

[2] Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 1.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995.
The list at 03:30 min, the national surveys at 03:40, and the explanation at 04:48 min. Link copied 2018-10-27.
https://www.youtube.com/watch?v=_pcuzRq-rDU

[3] From Merriam-Webster. Link copied 2020-01-25.
https://www.merriam-webster.com/dictionary/principle

[4] From Cambridge. Link copied 2020-01-12.
https://dictionary.cambridge.org/dictionary/english/cohesive

[5] From Cambridge. Link copied 2020-01-12.
https://dictionary.cambridge.org/dictionary/english/coherent

[6] From Lexico. Powered by Oxford. Link copied 2019-11-24.
https://www.lexico.com/en/definition/analysis

[7] From Merriam-Webster. Link copied 2020-01-12.
https://www.merriam-webster.com/dictionary/synthesis

[8] From Lexico. Powered by Oxford. Link copied 2019-11-24.
https://www.lexico.com/en/definition/negate

[9] Wikipedia (Swedish). Link copied 2019-11-25.
https://sv.wikipedia.org/wiki/System

[10] From Lexico. Powered by Oxford. Link copied 2019-11-25.
https://www.lexico.com/en/definition/system

[11] From Lexico. Powered by Oxford. Link copied 2019-11-25.
https://www.lexico.com/en/definition/organization

[12] From Lexico. Powered by Oxford. Link copied 2019-11-30.
https://dictionary.cambridge.org/dictionary/english/sub-optimization

[13] Psykologiguidens psykologilexikon (Swedish). Link copied 2019-11-24.
https://www.psykologiguiden.se/psykologilexikon/?Lookup=kontextberoende[

[14] From Cambridge Dictionary. Link copied 2020-01-04
https://dictionary.cambridge.org/dictionary/english/problem

[15] From Merriam-Webster Dictionary. Link copied 2020-01-25.
https://www.merriam-webster.com/dictionary/narrative

[16] Smalley, Art. Four types of problems: from reactive troubleshooting to creative innovation. Lean Enterprise Institute (2018). ISBN 978-1934109557.

[17] Youtube. Art Smalley. Four types of problems. Link copied 2021-12-09.
Webinar with Art Smalley- Four Types of Problems – YouTube

[18] Wiktionary. Killgissa. Scientific research about why it is done in [19].
https://en.wiktionary.org/wiki/killgissa

[19] Science in Swedish. “Why men are man guessing”
Resume: Added testosteron for men in a mathematical test that needed second thoughts, gave higher rate of man guessing (20% more wrong answers).
https://www.sydsvenskan.se/2017-04-30/forskare-darfor-killgissar-killar

[20] Alvesson, M, Spicer, A, The Stupidity Paradox: The Power and Pitfalls of Functional Stupidity at Work, IPS Profile books. ISBN: 978-1781255414.

[21] Conway, Melvin. Link copied 2018-09-14.
https://en.wikipedia.org/wiki/Conway%27s_law

[22] Ringlemann, Max. Link copied 2018-09-14.
https://en.wikibooks.org/wiki/Managing_Groups_and_Teams/Social_Loafing

[23] Snowden, Dave. Link to blog post copied 2018-09-14.
http://cognitive-edge.com/blog/natural-numbers-networks-communities/

[24] Dunbar, Robin. Link copied 2018-09-14.
https://en.wikipedia.org/wiki/Dunbar%27s_number

[25] Miller, George. Link copied 2021-10-25.
The Magical Number Seven, Plus or Minus Two – Wikipedia

[26] Chinese whispers. Link copied 2018-09-14.
https://en.wikipedia.org/wiki/Chinese_whispers

[27] Wicked problem. Link copied 2020-01-05
https://en.wikipedia.org/wiki/Wicked_problem

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

[29] Snowden, Dave. Blog post. Link copied 2021-06-26.
In uncertainty lies resilience – Cognitive Edge (cognitive-edge.com)

[30] Snowden, Dave. Blog post. Link copied 2019-06-04.
https://cognitive-edge.com/blog/of-effects-things/