How to boost your organisational problem-solving ability – part 1/9 – Introduction

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.

This series is for you that have been thinking around something 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 tries to solve a problem locally within the organisation, but isn’t that in most cases only sub-optimisation you wonder.
  • If your organisation asks why the problem exist, the problem-solving is still very shallow and stops before 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”.
  • When introducing a new way of working, external experts are summoned to change your way of working, which they do not have a clue about and without knowing anything about your business as well. Is that really the right way to do it?
  • When introducing a new way of working, many of your questions cannot be answered, and many times there is not even time for asking questions to the experts, 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, this means that you need to RTFM, where you think that you never find any answers to your (eternally) postponed questions.
  • 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 transferred without or with very little 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 nowadays, with formulas and graphs, something that was never an issue in the past.
  • 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.
  • 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 the same problems; too many meetings, too many people at the meetings, too many people in the projects, too many emails – frankly too much of everything which in turn will have the negative consequence of losing time and that too many people are stress 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 “same” problems.
  • 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?
  • Finally, you may also wonder why there is system responsibility for your products and services, but not for the organisation itself, since your feeling is that the organisation is much more complex than your products. Isn’t it risk for sub-optimisation of the parts, if there is no one responsible for the total?

This series will answer all above questions 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 [1], 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 and 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*[2];

A root cause is easy to solve, because it is not rocket science.
But, not even rocket science can solve a symptom.

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 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 difficult, 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. Now the acceptance level for some of you has been pushed to the limit, or maybe already been passed, 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 true solution, the what, is easily understood, meaning that making an implementation of the how then is 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 how to change the way of working to become awesome.

But the above quote does not imply, that the root causes are easy to find, especially if no one ever asks the question why, to find them, which as stated before, has been unrevealed for more than half a century. This will also be further elaborated on later in the series.

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. But many times, in organisations, unfortunately, only the symptom is taken care of, meaning that the person will not get long-term healthy and more people will get burned-out.

This series has a great connection to these words of the pre-complexity guru Dr. Russell Ackoff in the 1990s [3], 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.

 

*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] Cambridge English Dictionary, “crash course”. Link copied 2019-04-02.
https://dictionary.cambridge.org/dictionary/english/crash-course

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

[3] Ackoff, Russell Lincoln. Biography. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/

Leave a Reply