Skip to content

Using Systems Thinking to Analyse Different Viewpoints

Introduction

We’ve all experienced moments where two people witness the same event but explain it in completely different ways. Maybe you and a friend watched the same movie and each had a very different take on why the plot fell flat—or why it was brilliant. Or perhaps you and a coworker disagree about what caused a project to go off-track.

Why do these differences happen? It’s not necessarily that one person is wrong and the other is right. Instead, we each look at events through our own “lenses,” guided by our experiences, goals, and what we’re responsible for. In other words, our point of view determines the fixed central point of reference around which other relevant factors revolve.


Systems Thinking

In order to gain a holistic perspective that is not governed by one specific point-of-view, we can use systems thinking.

What is Systems Thinking?

Systems Thinking is a way of structuring and analyzing complex problems by recognizing that everything happens within a “system.” A system can be anything: a workplace, a computer program, a city road network—any environment with its own rules and boundaries.

Why Does Systems Thinking Matter?

Systems Thinking matters because each system is designed for a specific purpose (like roads for cars, or an operating system for running software), the system naturally views some events or people as “insiders” (its main priority) and others as “outsiders.” Therefore when two different systems overlap—like pedestrians (pavement system) and vehicles (road system)—they might see “causes” for the same event in very different ways.

Consider the following example:

The Pedestrian and the Car

The Event

A man steps off the sidewalk (pavement) and is hit by a car on the road. At first glance, this seems like a straightforward incident. But was the primary cause (the main reason it happened) that the man left the pavement? Or was it that the car didn’t stop?

Pavement (Human-Centric) Perspective

  • Primary Cause: The man left the pavement—his protected space.
  • Secondary Cause: He was struck by a car.

From a pedestrian-focused system, the pavement is designed for people’s safety. The moment the man steps off into the roadway, he’s left the system that’s meant to protect him. In that view, his action (stepping off the curb) is the key event that led to the accident.

Road (Car-Centric) Perspective

  • Primary Cause: A physical object (the man) appeared in front of a moving car.
  • Secondary Cause: He got there by stepping off the pavement.

From a vehicle-focused system, the road is built to help cars move freely and efficiently. Anything on the road that isn’t a car—be it a stray object, an animal, or a person—risks getting hit if it appears suddenly. The driver sees the immediate cause as “There was someone in my path,” while the reason that person got there feels secondary.

Why the Cause “Switches”

If you’ve never thought about it this way, it might sound like we’re contradicting ourselves. Which is it—did the man cause the accident by leaving the curb, or did the car cause it by not stopping? Systems thinking tells us it can be both, depending on which system’s purpose and boundaries you focus on:

  1. Boundaries: Who “belongs” here?
    • On the pavement, pedestrians belong. On the road, cars belong.
  2. Purpose: What is this system designed for?
    • The pavement is there to keep walkers safe. The road is designed for car travel.
  3. Assumptions:
    • Pavement mindset: “Stay here, and you’re safe.”
    • Road mindset: “Cars won’t stop unless forced to—by traffic lights, or if they see a clear obstacle.”

These different viewpoints explain why each side labels something else as the “primary cause.”


More Real-World Examples

It is easy to look around and see many cases where primary and secondary cause are switched, depending on your viewpoint.

Software Ecosystems

  • System A (Operating System): A crash happens primarily because an application made an invalid request.
  • System B (Application): The crash happened primarily because the operating system failed to handle an unexpected state.

Each sees the other system’s behavior as the root cause.

Supply Chain Interruptions

  • Manufacturer’s Perspective: “Production halted because suppliers delivered parts late.”
  • Supplier’s Perspective: “Delays happened because the manufacturer changed specs at the last minute.”

Each party blames the other, highlighting how system boundaries shift our view of who’s at fault.

Organizational Budget Overruns

  • Finance Department: “The project manager overspent by ignoring budget guidelines.”
  • Project Team: “Overruns happened because finance released funds too late, forcing costlier workarounds.”

Again, two systems—finance and the project team—both see the other’s action as the primary cause.


The Core Idea: Boundaries and Objectives

In all these examples, there is a common principle:

  • Each system has a job to do (like keeping pedestrians safe or keeping cars moving).
  • Each system views factors inside it as routine and manageable, while anything from outside is treated as an “intruder” or complication.
  • Events that occur at the “edges” of a system—like a pedestrian stepping into a road—often look very different depending on which side of the boundary you stand.

Bringing It All Together

It is evident from the above discussion that to truly make sense of cause and effect, we have to look at things from both the original and the reversed perspective—the viewpoint we might usually ignore. This means looking at the “other side” of any incident system, where the “primary cause” might appear as a “secondary cause,” and vice versa. If we can’t logically flip our explanation to the other viewpoint and still have it make sense, we haven’t fully explored the situation.

Why This Matters

  1. Logical Clarity: By testing how an event looks from all sides, we avoid jumping to premature conclusions. If our explanation only works from one angle, it’s not truly comprehensive.
  2. Data-Driven Insight: Once we’ve considered both viewpoints, we can gather real-world data to see which perspective better aligns with the facts. This helps us pin down the actual root cause rather than just making a convenient guess.
  3. Conflict Resolution: When people see that their viewpoint has been given genuine consideration—and that others’ viewpoints are also valid depending on the system boundaries—finger-pointing often decreases.
  4. Better Outcomes: A thorough perspective check leads to more well-rounded solutions, whether it’s safer sidewalks for pedestrians, clearer software interfaces, or smarter organizational policies.

Conclusion

Different people or groups often see the “same” event in completely different ways, and that’s normal—we each look through our own lens shaped by our roles and responsibilities. Systems thinking gives us a framework to recognize and formalize these different perspectives. We see this in everyday life: from a pedestrian stepping into traffic, to software crashes, to supply chain disruptions.

Understanding how these boundaries shape what we label as “primary” or “secondary” causes can be powerful. It helps us grasp why others see things differently, and how to address problems in a more balanced and effective manner. Only after we examine both sides logically can we use real data to pinpoint the genuine cause. This is how systems thinking broadens our lens, sharpens our reasoning, and guides us toward sustainable, practical solutions.

5 1 vote
Article Rating
Subscribe
Notify of
guest

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Dan
Dan
2 days ago

Nicely done.

1
0
Would love your thoughts, please comment.x
()
x

Discover more from Fleeting Swallow

Subscribe now to keep reading and get access to the full archive.

Continue reading