← DolphinUniverse Body of Knowledge

Self-Organization 1/3 - why managers should know more about it - a short introduction

Wolfram Müller · 2019-09-19 · 9 min read
Self-Organization Critical Chain Project Management Self-Organization 1/3 - why managers should know more about it - a short introduction

self-organized growing ferns - iStock photo

Self-organization - why managers should know more about it - a short introduction

September 19, 2019

I don't want to talk about it for long - many managers wonder why their team or their department always behaves so "strangely" - quite differently than expected. The problem is that even if we think we have something to say as managers (and especially as consultants), in the end, they are self-organizing systems. And if you don't know how these self-organizing systems "tick," then something different comes out than you expect.

Attention: most of the systems we are dealing with are also complex - that means that there is no 100% certainty that something will happen. But if you ignore self-organization, you can be sure that it will go wrong.

Note that this is the first of three parts on self-organization. At the end of the article, you will find links to part 2 and, soon, to part 3 (but there is a link to an equivalent speech from 2019-09-25 that will fill the gap).

What is self-organization?

As is so often the case, there are probably 100 definitions - I refer here to the more scientific approach of Haken and Schiepek, "Synergetik" [1].

"Self-organization is a mechanism that enables almost sudden changes in the states of order in open systems consisting of autonomous subsystems!"

It may now be natural that this definition does not correspond to what one understands by self-organization - so I wrote this article.

And what is the concrete meaning of that?

When we think about our work, we often have to deal with teams/departments/areas - these are open systems. Something flows in - ideas/suggestions/concepts/inquiries/orders/projects - and something flows out, namely, hopefully, results. Furthermore, they consist of autonomous subsystems - departments/teams and, above all, people. And, no matter what someone claims, people are autonomous. No matter which instruction a person receives or which processes are defined - in the end, every person decides anew every day whether they will stick to the instruction or the process. And if we are honest - in practice, we humans often only do what makes sense to us. We love our autonomy!

Insight #1: "Almost all systems in professional life are self-organized!"

If this is the case, the second part of the definition, "systems can assume new states of order almost by leaps and immediately," is also correct. And this is exactly what managers/consultants and, interestingly enough, most of those involved want - fast and successful change processes. A state of order (or the technical term, order parameter) can also be a good thing - if the work flows, much is achieved, and it serves a common goal. This is also called "flow" - a very desirable condition.

Insight #2: "Change processes can, in a self-organized manner, run very fast and achieve good results."

The question remains: how does this work?

Here in this article, I can only describe the main features - to state the essence - and provide an introduction. At the end, there are bibliographical references that provide further details.

At the core, however, there are only two (three) things you "have to" do in order to achieve a change of order in a self-organized system:

  1. Set the control parameter correctly - so that the autonomous subsystems have room for maneuver and can orient themselves in new directions.
  1. Generate a signal and thus build a feedback loop that helps the autonomous systems do what makes sense for each individual and serves the superordinate goal - i.e., install an order parameter.
  1. Give the system an impulse to change.

And what does that mean in concrete terms?

The control parameter is usually quite simple (but not necessarily easy). In work systems, the control parameter is typically the work in process (WIP) - the amount of work loaded. In order to judge whether something is a control parameter (which has little to do with control), the following thought experiment helps: "How does the system behave if I change something about it?" For example, I have a team that can handle 10 projects per month well. What happens if I double the number of projects (i.e., the WIP)? Sure - hewing and stabbing, multitasking, fighting for resources, frustration, and fluctuation. This is also a state of order - a well-known one - but not a particularly satisfying one. Or the other way around - instead of 10 projects, there is only 1. Then there is panic - fear of losing one's job, security measures, knowledge monopolies, hidden knowledge, and no cooperation to be seen. This is also not a desirable state of order. But if the WIP fits, then nobody is overburdened - and nobody is underloaded either - and there are reserves available to work on the system. Change can happen.

The easiest way to set the WIP correctly is to learn from E. Goldratt's Theory of Constraints. As a physicist, Goldratt simply realized that there is only one constraint in every system. You have to find it and never overload it - then all the rest fits. More about this can be found in his book "Das Ziel / The Goal" [2] (which, by the way, Jeff Bezos described as one of the three "must-reads" for all managers ;-).

The order parameter, or signal, is a bit more exciting. The signal must be generated from the element that flows, e.g., a project, order, story, or ticket, and it must be operationally useful and make sense to everyone so that they voluntarily subordinate themselves to the signal. But beware: the signal must not be generated by a single person - it must somehow be related to the overall goal and be created based on "measurements."

For projects or agile releases, we usually use the fever curves from the "critical chain project management" world of E. Goldratt [3]. Simplified, this is nothing more than buffer management - every project or release always has a bit of buffer. We pull these together and place them as one buffer shortly before the end of the project or release. Every day, a short check is made to see how much progress has been made and how much of the buffer has been used. If the progress is greater than the buffer consumption, then it is "green." But if the buffer usage is greater than the progress, it is "red." In between, it is a bit "yellow." That makes sense, doesn't it?

A selection of Critical Chain Fever Curves of agile and classic projects

Picture - Fever curves from all over the world - agile and classic!

But it only really makes sense if you do something with it! The fever curve signal is therefore made available to everyone in the company - everyone - really everyone. The question then is: what would be the greatest benefit for everyone from this signal? It's also clear - they get help when their project is "red"! So the signal makes sense if you get support (without begging). It also makes sense, if you are "green," to help those with a "red" one, because you know it can affect you too. So it makes sense to distribute the resources according to the simple (and only) rule, "red before yellow before green" - totally logical.

It's like traffic lights in traffic - of course, nobody likes red traffic lights - but everybody knows that if they stick to red and green, they'll make faster progress than if they just drive into the intersection. This is the essence of a good signal for robust self-organization.

The third point, "the impulse," is then often nothing more than a clear declaration of leadership intent - not to overload the system anymore (to set control parameters correctly) and not to interfere with operational priorities anymore (to let the order parameter do its work). The management is then "only" there to provide support and can concentrate on strategy again.

And in practice ...

... everything goes really fast. For small teams (up to about 15 people), one day is enough to make the jump and a few weeks to stabilize it. A project organization takes a few days more, and if it involves more than 500 people - then you have to reckon with a few weeks.

Examples and details can be found in our agile book, "Management 4.0" [4], and on the internet (just search for "Critical Chain Testimonials").

And what does the new order state bring?

Here are just a few quotes from employees who have experienced it:

And what does it do for the organization?

Nobody believes that anyway - so don't read on! Project times can quickly be halved. But you can only do that by solving overlapping process problems - but this also happens in a self-organized way. If you suddenly solve a process problem together - then the output often increases by +30 to +50% and, from time to time, significantly more!

Why should one now deal with self-organization?

But beware: the whole thing needs to be well prepared. But more about this in the next article ... ask me or read directly in the book "Management 4.0."

Links to the other parts of the series ...

Part 1 - "Self-organization - why managers should know more about it - a short introduction" ... you just read this article - but feel free to send it to friends - maybe they will thank you ;-)

Part 2 - just continue reading - how to prepare such a change: Self-Organization 2/3 - The middle management is not the "paralysis layer" but the "power layer"

Part 3 - what it looks like in practice: Self-Organization 3/3 - Why self-organization changes are cool for top managers and everyone else!

Literature:

  1. H. Haken/G. Schiepek, „Synergetik in der Psychologie: Selbstorganisation verstehen und gestalten“, 2010
  2. E. Goldratt/J. Cox, "The Goal" - or „Das Ziel: Ein Roman über Prozessoptimierung“, 1984
  3. E. Goldratt, "Critical Chain" - or „Die Kritische Kette: Das neue Konzept im Projektmanagement“, 1997
  4. A. Oswald/W. Müller, “Management 4.0: Handbook for Agile Practices”, Release 3, 2019