Welcome to this series about organisational problem-solving, also covering problem-solving in general. Organisational problem-solving is also one of our principles, which makes the exploration of problem-solving in this series natural, to not say necessary since it is the principle to start with when we have problems.
This series is for you that have been thinking around some of the issues regarding problems within your organisation and the way your organisation is handling different problems. Here are some examples:
- You have the feeling that when your organisation is tackling a problem, the question why the problem exist, is never or seldom asked, instead the part of the organisation (group, team, silo, department, etc.) where the problem arose tries to handle the problem directly themselves.
- You have the feeling that the SCQA (Situation – Complication – Question – Answer) technique always to frame the problem and tries to solve the problem locally within the organisation, but you wonder if the problem really can be locally every time? You also have the feeling that it maybe is not a coincident that the money is locally too?
- You have the feeling that the MECE* technique also perform framing, by dividing the problem into small pieces and tries to solve them separately, without asking why one single time why the problem exist, so you think it must be very far from the real deeper-rooted cause.
- If your organisation asks why the problem exist, the problem-solving is still very shallow and stops when you are outside your manager’s area of responsibility, or the department’s, the silo’s, your team’s, your train’s, etc. – with the comment “it isn’t our responsibility”.
- You have the feeling that the consultants selling methods and frameworks, indirectly (or maybe deliberately) tries to remove experience, competence, knowledge and skills about product development from the table, and substitute that with a method or framework that has all of this intrinsically. How is that even possible you wonder?
- When introducing a new way of working, external experts are summoned to change your way of working, they do not have a clue of our problems (since they do not ask), and have no clue about and the business as well. You wonder if they have never seen Deming’s quote; “To copy is to invite disaster.”, or why they do not listen when you bring it up.
- When consultants are introducing a new way of working (framework), many of your questions cannot be answered, and many times there is not even time for asking questions to the consultants, instead you get the answer “because this is the way it is in this method/framework” and your questions are postponed. Reading between the lines, you understand that this means that you need to RTFM, where you know you (or them) will never find the answers either, since your questions are about your current problems, which they never asked about.
- You think that there are too many different problem-solving techniques that are very similar. Do we really need them all?
- You think that many problem-solving techniques are adopted without adaptation or with very few changes from the repetitive work in production to complex product development, two very different domains. How can that even be possible?
- You have been wondering why there is so much fuzz about queues of activities (user stories/features/etc.) nowadays, with formulas and graphs, something that was never an issue in the past for hardware product development. Have software product development introduced more and longer queues, or what?
- You have been wondering about the tremendous increase of measurement nowadays, especially on team level, and once again something that was never done in the past. Can we really measure small parts, and sum it up to the whole?
- You have the feeling that in whatever bigger company you work for, or if the company is very big, in whatever sub-organisation you work for, there are many problems in common; too many meetings, too many people at the meetings, too many specialized people working on the same part, too many emails, too many small parts in queues, etc. – frankly too much of everything which in turn will have the negative consequence of losing time and that too many people are stressed and many of them get burned-out. You think that these problems must have something in common, it cannot be a coincidence that all companies have so many of the “same” problems above.
Contrary you also think that it is strange that small companies do not seem to have the problem of having too much of everything equally the big companies. How come? - You may also wonder why there is system responsibility for your products and services, but not for the organisation’s way of working itself, since your feeling is that a well-functioning way of working is the key to a well-functioning product. How can that come?
- Finally, you also wonder that if we ask why on the problem we have, doing an analysis to find the root cause(s), when do we know that we found a root cause, maybe their are infinite root causes?
And your wonderings are legitimate.
The above wonderings are a mix of sub-optimisation, symptom-solving, divide and conquer strategies, manipulation, master suppression techniques, delete common sense and “no problem-solving at all”. And these “methods” do not work. At all. Let’s quickly go through the list and see which items match the different “methods”:
Sub-optimisation (symptom/effect-solving): 1, 2, 3, 4, 8, 14
Divide and Conquer strategies: 2, 3, 8, 10, 11,
Manipulation and Master suppression techniques: 5, 6, 7, 8, 9
Trying to delete common sense (the transformation is the goal, no questioning please): 5, 6, 7, 8
No problem-solving at all: 8, 12, 13
And as you can see, sub-optimisation and trying to solve symptoms means actually the same thing. Sub-optimisation means that you are trying to solve “your” problem, but since sub-optimisation does not work, it is clear that “your” problem is not a root cause, since otherwise you can solve it. Therefore “your” problem can only be a symptom.
This series will answer all above wonderings and many more and if you are a CEO, software engineer, an executive member of the board, working with HR, service engineer or any other position within the organisation does not matter, since it will really be a deep dive into any kind of problem-solving. But the main focus is, as stated before, on organisational problem-solving. This is an area left for its own free growth in the Wild West for over half a century which has led to thousands of tools, methods and different kinds of way of working and how this could happen will also be explained throughout the series.
For readers that are only skimming text, I need to start to say that this is not a crash course in organisational problem-solving. And the reason for this is that according to Cambridge English Dictionary [2], a crash course is; “a course that teaches you a lot of basic facts in a very short time“. This series is instead a deep dive into organisational problem-solving in order to find these basic facts, the corner stones and foundation of any (organisational) problem-solving. This means neither that it necessarily will take long time to read it, nor to understand it. The hard part will instead be to accept the implications of it, since it is a game-changer for organisational problem-solving. The reason is that it is contrary to our current believe about organisational problem-solving that is built on the engineering metaphor, reduction and aggregation. This quote is apt;
Without changing our patterns of thought, we will not be able to solve the problems we created with our current patterns of thought.
— Albert Einstein
And the acceptance is really the difficulty of this series, since the implications of the easy parts will be hard to accept, and for many of us it requires a change of our patterns of thought. This yields even though the text does not consist of any difficult words, complicated pictures, or blurry arguments due to consequences of earlier (once again blurry) arguments. Blurry arguments are treacherous and unfortunately very common today, and can survive due to a sufficiently long chain of consequences due to earlier consequences of a symptom, that will make it so complex, so it finally fools anyone, including the inventor (Sic). Here is a more thorough explanation that is easy to understand and probably also to accept**[3];
A root cause is easy to solve, because it is not rocket science.
But, not even rocket science can solve an effect.
This is the reason to ask the necessary and important why many times, when we have any problem, organisational or not. Since if we do not find and solve the root cause(s), we have symptoms that we cannot foresee not even with products that are “only” complicated, but especially not in an organisation, since it is a complex adaptive system. This is the reason to the “(Sic)” above, because a method, best practice, or any improvement technique that is trying to solve organisational symptoms, can never work, meaning that the explanation of the inventor consequently must be wrong***.
And the quote above also gives us the following; since the root causes give all the symptoms, it implies that the true solutions are easily understood, and if they are not, they won’t do the job. So, watch out when someone comes with a solution that is trying to solve a problem without asking why the problem exist, since this directly leads to sub-optimisation, and here the MECE technique is a good (read: many times a bad) example. Now the acceptance level for some of you has been pushed to the limit, or maybe already passed it, meaning that it is hard times, since your patterns of thought need to be changed. But do not worry, I will guide you gently through this series, moving your acceptance level bit by bit, but sometimes passing it without you sensing it. And do not forget that the solution of the true what, is easily understood, meaning that making an implementation of the how is then straightforward for any company, knowing already its own business best. Think carefully about this, since the implications are mind-blowing when any company is fully in charge itself of understanding why and how to change the way of working to become awesome.
But the above quote does not imply, that the root causes in the organizations are easy to find, especially if no one ever asks the question why, to find them, which as stated before, which means enormous unrevealed potential for our organizations to flourish.
Now you have the understanding why it will be easy to understand this series, since it will go for the root causes, nothing else. Of course, we sometimes, as will be explained, need to consider taking care about the symptoms as well, since they are already a fact and the easiest example is that we need to wipe up the oil under a leaking machine. In organisations for example, people that got sick from stress is one symptom that need to be taken care of as well, not only the root causes for it, since without knowing the root caues(s), the risk is high that next person put at the same position sooner or laste also will get sick. But many times, in organisations, unfortunately, only the symptom is taken care of, meaning that the person will have problems to recover and probably get long-term unhealthiness, and more people after that will get sick too.
This series has a great connection to these words of the pre-complexity guru Dr. Russell Ackoff in the 1990s [4], where he is denying the obvious things that people do not want to prove. Here is one of them:
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.
This goes for any problem, organisational or not, and the connection will be further explained throughout the series, with a twist at the end to put everything together in the light of human science.
Throughout the series there will be many different examples of problem-solving, not only organisational, and many of the later blog posts will continue and build on examples started in earlier blog posts, often with a twist later on in the series. So, hang on if you find an example to easy or stupid, the twist you did not expect, will come later in the series.
This was the introduction to this series, c u tomorrow for the next part.
*MECE [1] – Mutually Exclusive and Collectively Exhaustive. MECE is a method for separating a set of items into subsets, that are mutually exclusive and collectively exhaustive. Applied at wrong circumstances makes it highly anti-systemic, since the method does not consider that a symptom is impossible to solve, no matter if we divide the symptom or the solution space, see this blog post for a deep-dive.
**but be aware of the implications, since an acceptance of these simple statements about symptoms and root causes most probably requires a change of your patterns of thought later in the series…
***beware of the implications of this, so you don’t think I cheated you when you come to the end of the series…
References:
[1] Wikipedia. MECE principle. Link copied 2021-10-30.
MECE principle – Wikipedia
[2] Cambridge English Dictionary, “crash course”. Link copied 2019-04-02.
https://dictionary.cambridge.org/dictionary/english/crash-course
[3] Wikipedia, root cause: “Those signs can be widespread, multitudinous, and convoluted, whereas the root cause leading to them often is a lot simpler. “. Link copied 2019-05-25.
https://en.wikipedia.org/wiki/Root_cause
[4] Ackoff, Russell Lincoln. Biography. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/