Thinking in Systems introduced me to systems thinking many years ago, which changed how I saw the world and shaped some of my perspectives on problem solving. This mentality goes beyond the typical use of “systems” as a noun familiar to software engineers in programming or distributed systems contexts.
Earlier in my career as an engineer, this pushed me to model the connectedness of inputs and outputs from my engineering team as a part of a larger system, composed of an engineering org, an engineering function, a cross-functional development division, a company, and an economy. It made me think about the likely reactions to scarcity-imposed constraints, where cross-functional failures were likely to occur, or how incentives and outcomes reinforced behaviors across functions in the development organization.
From Systems:
How to know whether you are looking at a system or just a bunch of stuff:
A) Can you identify parts?
B ) Do the parts affect each other?
C) Do the parts together produce an effect that is different from the effect of each part on its own?
D) Does the effect, the behavior over time, persist in a variety of circumstances?
This mindset promotes a kind of curiosity about all events and circumstances I experience in my work. It pushes me to think about the first, second, third-order effects, and beyond, of decisions or changes.
For example, it’s often the case that engineers come across “bad code”, and hastily conclude that the bad code was produced by a “bad engineer”. A systems thinker, however, might probe further:
Why was bad code committed? (The producing team was under pressure to ship quickly)
Why did the team decide to cut corners rather than push back on the timeline and uphold standards? (The team lost all its senior engineers)
Why did the team lose all its senior or experienced talent? (They felt a lack of trust because their attempts to push back in the past were overruled)
Why didn’t the organization listen to, or trust, its senior engineers? (The director in charge of the organization has failed to deliver on commitments for multiple quarters)
Why has the organization failed to deliver? (Too much technical debt and “bad code” makes it hard for teams to iterate in the codebase)
And so on. These questions can lead to surprising answers, such as “the organization’s scope is unattractive for experienced engineering directors”.
Some readers will liken this thought process to the 5 Whys investigation technique, often used for incident root cause analysis. RCA is a practical application of systems thinking which tries to uncover a singular cause of disturbance in a system. Again, from the book:
The interactions between what I think I know about dynamic systems and my experience of the real world never fails to be humbling. They keep reminding me of three truths:
1) Everything we think we know about the world is a model
2) Our models usually have strong congruence with the world
3) Our models fall short of fully representing the world
This quote helps explains why even senior and experienced engineers can be caught off guard by large software system failures, resulting from root causes seeming trivial at the onset.
Learning about, and adopting this mindset helps build an appreciation for the larger set of circumstances which affect of your work, and helps you understand the connectedness of your work to the world.
