Everyday Reflections

Everything is a system

I am starting to write book reviews as a new section on my site and happened to pick the first one as Thinking in Systems, by Donella H. Meadows. It is a great way to understand the business methodology called systems thinking. Systems thinking isn’t just for business or manufacturing geeks but can be applied to smaller or broader set of system design , behaviors and processes.

Just like the Theory of Constraints, it’s a powerful principle that can be applied to work, life, or just about anywhere you want to level up. Sharing some insights , which I have been reading and trying to see how they apply while designing architecture and software systems.

The book is a good read to get a grasp of conceptual tools that help solve complex problems. Most of the times you may feel that you have come across the concept but what is important to know and understand is how can you proactively look at using them and solving some of the problems around you. The scale of application from Donella’s point of view is governance , society at large and expansive problem statements that revolve around policy formation but if you re-apply it to smaller problem set , it gives you ideas to devise possible ways to solve , iterate and pivot.

Before we talk about how to apply this theory, here are 3 core principles to understand:

• Everything is a system: a product, team, market, process, habit, personal routine — even an elephant.
• To understand (and improve) the system, you have to understand each part, and how the parts connect. Clearly, an elephant is much more than a trunk, legs, and a trumpeting cry.
• If you can’t see or experience the full system, you need to create models to put it all together. It’s the only way to know your elephant.

Interestingly, she talked about these archetypes as “system traps” and described some ways out of the traps.

Policy resistance. Any change we make seems to have a short term effect on the system but the long term sees the system return to the same behaviors we were trying to change before.

Meadows’ suggestion is that this may be a “let it go” moment – adding more control isn’t going to help, rather find ways to understand and meet the goals of the actors in the system. We often find ourselves in this loop. When you look at engineering metrics or bringing change in ways of working , they all see drag effect after certain point in time. Putting more checks and balances to maintain initial outcome does not help and one needs to let the system respond with lesser policy control and better maturity levels.

Tragedy of the commons. This is a classic where over-use of a common resource ends up destroying the resource.

While you would see many real life examples of this starting from coffee consumption , traffic jams and many other related environmental impacts ,specifically in product development, if we look to engineering as a shared resource, we see that we have a lot of people using this resource somewhat independently. You have marketing making requirements, you have the executive team, you have manufacturing that has needs that are brought to engineering, and customer support also gives input to engineering addressing market issues. Each of these resources looks to optimize the use of the resource and this drives the system archetype of the Tragedy of the Commons where engineering ends up being overburdened and as queuing theory says it’s efficiency drops off dramatically. Therefore controls have to be put in place as antidote that help prioritize and lay down iterative vision that does not lead to this problem. Focus and what is coming next , making use a bounded problem is important. Nothing is infinite !

Drift to low performance. This isn’t as familiar to me, but the idea is that we keep changing performance expectations based on what happened before – and that we see successes as outliers, pushing us to lower and lower targets.

A⁺ to A⁺⁺ you would see this come up alot in engineering , how to we become a high performing unit. The problem with the drift is that you do not see it happen and move into a defensive mode with people wanting to protect themselves from damage if they are held to their commitments. Instead of being protectionist , one needs to start accepting the next uncomfortable level of operating and then use that discomfort to up performance to newer benchmarks. Remember if we make up the system and create a drift towards low performance then the whole system will be under-performing.

Escalation. This sounds like the opposite of drift to low performance but is described in the context of two entities, where as drift is about one entity. The classic is a price war or an arms race.

As with drift the best way seems to be not to engage. Difficult to do when you are in the middle of it! but handling escalation and negotiating your way out of it is the best way to handle this aspect within a system. If we create a spiral like some of the other macro situations where escalations have led to large scale conflict , the ability to destabilize the system remains very high . Acknowledging early and remediating is the best way to handle escalations.

Success to the successful. The winner takes all – and then goes on winning. This is why countries have rules about monopolies.

Systems should be designed to always keep flow of talent from engineering point of view. Competition is a good thing for the larger system, even if the competitors are driving to “win.” as it avoids the drift , creates a behavior of active response.

Addiction (shifting the burden to the intervenor). Another classic – if one is good, then one hundred must be better. Another trap where those inside don’t see a way out. Another trap best avoided by not getting into it.

Consider employee performance. Manager is made to provide solution .Necessary training of the employee is made to happen but this leads to growing dependence on manager and decreasing confidence on the employee this compromising self-reliance. Our system design should help propel people towards building capability and strengthen core spine to self-assess and self-correct through de centralize feedback loops.

Rule beating. This felt like a repeat of some of the traps above. Or maybe an example of what happens in sub-systems when operating in these larger archetypes. We have all seen these kinds of situations: I have to do X to get around Y, which causes the system to respond with more Y, so I have to do more X. How many times have I heard clients talk about their favorite workarounds and then their frustration when the rules change under them and their workarounds no longer work – until they find new ones.

Does it remind anybody of tech-debt 🙂

Seeking the wrong goal. This is a familiar trap – “show me how you measure me, I will show you how I will behave.”

The fix is to align the measures with the goals. Not always obvious, but much more valuable. “Be careful not to confuse effort with result or you will end up with a system that is producing effort, not result.”

The book itself offers many feedback loops and archetype that can be put into perspective and definitely recommended for developing a systems view from a mind space perspective. Read more here The System Thinker