top of page

Systemic Complexity

In the following, I posit that while our products are complicated, the cultures which develop those products are complex. (Peter Senge's book, The Fifth Discipline, refers to this as 'detail complexity' and 'systemic complexity' respectively.)

Trying to develop complicated products in complex culture often results in scandal, and the solution lies in systems thinking; a more encompassing topic than is systems engineering.


Systems Thinking and the Beer Game

The online Sim called "The Root Beer Game" is provided by Harvard Business School and is based on a board game version which was developed by MIT in the 1960’s to help in understanding supply chains. But I use it as a learning device in Systems Thinking, based on the book "The Fifth Discipline" by Peter Senge. The purpose of the simulation is to recognize that the actors in the simulation are "prisoners of the system" to which they belong. He discusses the sim as “a microcosm on how organizations function”, and that it “reveals that problems originate in our basic ways of thinking and interacting”.


As an instructor, rarely does life so quickly reaffirm an abstract concept that I cover in class, but I teach mostly automotive engineering managers near Detroit, and just two weeks after we ran the simulation in my 2021 class, their auto factories shut down due to a lack of integrated circuits. This was just a few months after the great toilet paper shortage of 2020, and just before the supply chain challenges seen in response to the COVID pandemic. Pandemics are tragic, but we need to learn from them, and this lecture is a small step in that goal.

If you’re a student in my class, this is an in-class assignment early in the semester. Do the sim with the class first, and then come back to this lecture… you’ll just get more from the learning experience.

Decomposition Creates Dysfunction

Developed for a Gate4SPICE ASPICE even hosted by ZF, based on a previous lecture at the PLM Road Map & PDT Fall 2021 (

Idea in Brief:

Systems Engineering techniques based on decomposition follow a Blind Men and the Elephant paradigm, where we assume (wrongly) that if a group of people thoroughly understand the components of a system, that they can also understand the system itself. To understand complexity, Systems Engineering is not enough, we must adopt Systems Thinking.

In the following lecture, I cover how the very human decisions which led to hundreds of deaths and billions in losses in the GM Ignition Switch Recall, and the Boeing 737 Max Groundings were each due to the cultural and economic pressure to achieve revenue goals, and a lack of information or occasional recognition of seemingly unimportant information, which does not coalesce into systemic understanding. To understand systems, we must enable collective learning, but this is antithetical to the business models of the past century, which focuses on divisions, departments, and componentry. Long form articles on GM and Boeing can be found here. Scandalous Product Failures (

I have had concerns for some time about the viability of autonomous vehicles (AVs) for passenger travel, and the week I gave the ASPICE lecture GM's Cruise Division pulled all of their vehicles off the road due to recurring safety concerns. I speak briefly on this here, as it seems to be a continuation of the GM and Boeing use cases.

Finally, I pose three hypotheticals, and would love to hear your response:

  1. Is there a Limit to Growth in the number of safe and effective lines of code which can be embedded into a vehicle?

  2. Should the AV manufacturers compete on the safest vehicle? (Safest to pedestrians?) If so, should any vehicle which is not the safest be allowed to operate?

  3. Is it possible for individuals to add components into a system such that the system is impossible to comprehend, and if so, what is the likely result? What is the Limit to Growth in Complexity?

Systems Thinking Archetypes

Many in my audience are familiar with Systems Engineering (and that is my own background) a potentially more important topic is Systems Thinking, which is distinct from its Engineering.

I leverage in particular, The Fifth Discipline - Wikipedia by Peter Senge, and it forms the core of my teaching, speaking, and writing. While Systems Engineering emphasizes a decomposition approach (which I posit results in dysfunction), Systems Thinking looks at feedback loops, specifically:

  • Reinforcing feedback: in which growth encourages even more growth, and

  • Balancing feedback, in which growth either generates a counteracting force, or simply runs out of resources.

Combining the feedback loops into meaningful archetypes is very useful in understanding system behavior (e.g., in 2020, as COVID became a pandemic, I realized I was predicting the news by anywhere from 18 hours to 18 months.) I cover three important archetypes here:

  • Limits to Growth: in which reinforcing growth is limited by a balancing loop, and we saw this in the growth and eventual decline of COVID-19

  • Shifting the Burden: in which we over-rely on what turns out to be a symptomatic solution, rather than a more time-consuming and costly fundamental solution. An example of this is the supply chain collapses seen beginning in 2021.

  • Tragedy of the Commons: In which independent actors optimize their own reinforcing growth, without recognizing that they are consuming a common supply of resources. (This is analogous to the other dysfunctions found in decomposition approaches.)

All of these archetypes are useful in understanding how we may be impacting the climate around us, and the lecture makes comparisons between the archetypes and climate change.


Other Stuff

Digital Enterprise Society Podcast

Interview on this topic with Craig Brown of the DES. 141: Solving Complex Problems with Systems Thinking - Digital Enterprise Society.


And this is a fun video on how pendulums will synchronize through systemic reinforcement, and towards the end of the video discusses the limitations of "Reductionism" (which is analogous to "Decomposition") in understanding complexity.


bottom of page