I have recently finished reading Thinking in Systems by Donella Meadows. It’s a classic book that has influenced the worldview of most of its readers. And I am not an exception. I got equipped with a powerful systems lens. A lot of ideas that were previously intuitive for me have finally found their solid explanations.
In this post, I want to share two insights from the book. These insights are only a small part of a long list of my takeaways. But these two have affected me the most.
Impact of changing parts of a system
Systems consist of elements, interconnections and purpose (or function). Changing each of these aspects of a system has a different impact. Changing elements has the lowest impact. Changing interconnections has moderate impact. And changing purpose has the highest impact.
Imagine a small technology company. Its elements would be its employees - engineers, designers, product managers, executives. Interconnections are the processes and the communication flows between various teams. The purpose of this system is to deliver a valuable product to the market to generate profit.
Now let’s see what is the impact of changing each aspect of this company. Say we change employees on specific positions by hiring more experienced professionals. There is reasonable expectation that the company will perform better. But if the only change is the change of employees - existing inefficiencies in the company will not go away. The company will operate in the same way.
If we change interconnections - the rules and processes in the company - we can improve on a much greater scale. The same engineering team trained to work with the best agile practices can significantly outperform themselves.
And finally we see the largest impact when we change the purpose. Say the company decides to sacrifice its profitability for a period of time. It uses this time to produce a new technology. That technology can later help it achieve profit incomparable to the one it started with.
All my examples were examples of a positive change. But, the same is true for the negative impact. In the book, there is a great chapter which goes into details of various leverage points in systems. The chapter compares 12 different places to intervene and it is full of illustrative examples for each case.
Events, behaviour, structure and mental models
”System structure is the source of system behavior. System behavior reveals itself as a series of events over time” - Thinking In Systems
This insight is at the core of a famous systems thinking model known as the Iceberg model.
Events are the visible part of the iceberg. They are usually the most accessible signals for us. And unfortunately quite often this is the only level on which we think about problems. In this section I will use a DevOps example to illustrate how using the iceberg model can help us.
Say we received an alert that our website is down. A quick look into the alert details reveals the reason. The website is down, because the database has run out of memory. We link these events and a quick solution emerges - we need to reset the database. But it doesn’t guarantee that this problem will not repeat in future.
Let’s go to the next level of the iceberg. The first underwater level is knowns as Patterns of Behavior. This is where we start noticing trends and recognise patterns in what we observe.
In our example, we review our alerts for the last 3 months and notice that most of the alerts caused by the database memory issue occur on Fridays around 5am. With this knowledge we can automate database reset around that time each Friday. This will prevent the problem and will spare us from urgent alerts.
This sounds like a solution, but without understanding the cause - it is will not be a reliable one. Whatever causes the problem each Friday can be rescheduled to Tuesdays - and our preventative Friday database reset will become useless.
A much better solution emerges when we go to the next level of the iceberg, which is System Structure. Understanding the structure means understanding the elements of your system and interconnections between them.
In our case, knowing the structure of our platform we can look into what happens each Friday at 5am. We find out that there is a data import script that runs at this time. This script writes all its logs into the database. And this causes the database to run out of memory. We can solve this by writing logs into a logging service instead. With this solution we can be confident data import script will not overload the database again.
One the last level of the iceberg we have Mental Models. These are beliefs, assumptions, values that shape the system.
Going back to our example - we plan and organise a retrospective to discuss the problem that we have detected and solved. During that meeting we explain the benefits of using a logging service instead of a database for writing logs to our team. By sharing this knowledge we shape a belief that will prevent similar issues across our platform in future.
As you can see thinking and acting on deeper levels of the iceberg helps you achieve more impactful changes. It is worth developing a holistic understanding of the system to make fundamental improvements.
We can sum up both insights and visualise as one graph where from top to bottom changes have less impact:
Complex systems are all around us - in nature, politics, economics, languages, organisations. We ourselves are complex systems. I hope these two takeaways will inspire you to read the entire book, which has so much more to learn from.