First Understand Status Quo
My earlier article discussed a key practice in applying systems thinking: first, understand systemic behavior with Behavior Over Time (BOT), and then explore the systemic structure with Causal Loop Diagram (CLD) to explain that behavior—because structure drives behavior. I have been teaching this in my systems thinking workshop. This article will demonstrate how to use this approach to gain fresh perspectives on leading organizational change.
A common challenge in change initiatives is the "rubber band" effect: when you push a change, it moves forward for a while, but the moment you stop pushing, the system snaps back to exactly where it started. Repeatedly, this results in a recurring cycle of push-and-regress.
Explore the system dynamic
To understand why change fails this way, we first draw the following BOT graph, which shows two distinct periods in each push-and-regress cycle.
Period 1: The Push
In this period, a push for change prompts the system to shift toward a new state as the change goal. This behavior is typically driven by a balancing loop (B1), where the push for change works to close the gap toward the intended goal. The core idea is that some impetus moves the current state away from the initial status quo. Consequently, this shift could also be caused by a linear relationship or a reinforcing loop that alters the actual state.
Period 2: The Regress
In this period, the push stops, then the system begins to regress. This behavior suggests a balancing loop (B2) that aims to restore the initial status quo. There is an unseen force dragging the system back to its original state.
The systemic structure in CLD is depicted below. Gap 1 represents the difference between the change goal and the actual state, while Gap 2 represents the difference between the status quo and the actual state. A shift in loop dominance is observed over time, with B1 being dominant in Period 1 and B2 taking over in Period 2.
The "Period 0" Insight
Wait, period 1 is actually NOT the first period in the BOT; we have overlooked period 0! With a little thought, we can see that the equilibrium in period 0 is also driven by B2. B2 is the true "master" of the system.
The status quo is not a state of rest; it is actively maintained by the system's internal forces. Without identifying the forces that sustain this equilibrium, any attempt to change the system will be ineffective, as the system will simply return to its original state. Therefore, change efforts are futile unless the status quo is first understood.
Identify the forces behind status quo
In order to change the push-and-regress behavior, we must change the systemic structure. This requires a deep understanding of the forces behind the status quo. Rather than simply pushing the change, we should first identify the underlying forces driving the status quo then address the constraints tied to them. Let me elaborate with two examples.
Camera-On
In this example, our current situation is that most meeting participants typically keep their cameras off. We demand that everyone must keep their cameras on during all meetings. One of the forces that drive the camera-off status quo is the desire for privacy.
In the following CLD, I replace the general status quo with a specific force of privacy. Gap 2 is not any more the gap in camera-on time, but the gap between the actual felt privacy and the desired privacy. Consequently, unless the core privacy concern is addressed, the system will inevitably revert to the state of camera-off.
Frequent Integration
In this example, our current situation is that most developers only integrate their work once a week on average. We demand that everyone will integrate their work into the trunk at least daily. One of the forces that drive the weekly-integration status quo is a lack of capability in developing in small batches.
In the following CLD, I replace the general status quo with a specific force of development capability. Gap 2 is not any more the gap in integration frequency, but the gap between the required capability of developing in small batches and the available capability. Consequently, unless we build the capability of developing in small batches, the system will inevitably revert to the state of weekly integration.
When to address constraints
The logical starting point for change is to identify the forces driving the status quo and address their related constraints. If you possess the necessary insight and experience regarding these forces, you can proceed directly with this strategy. Otherwise, you have to pilot the change initiative to gain that understanding through a process of inspection and adaptation.
Interestingly, Scrum appears to advocate a different strategy. Instead of first addressing the forces behind a waterfall status quo, Scrum immediately imposes Sprints. The intent is to surface all forces that impede running effective sprints, such as weak development practices or flawed organizational design. The organizations adopting Scrum are supposed to solve those weaknesses as they are revealed. However, many organizations fail to do that. While they may still call it Scrum, these organizations have effectively regressed into their waterfall status quo.
Therefore, regardless of which strategy you take, either address constraints first or let the change surface them and act later, I suggest first grasping an understanding of the status quo.
A final note: The push-and-regress cycle discussed here is distinct from the Limits to Growth archetype. While both involve balancing loops, Limits to Growth describes movement toward a new status quo governed by new limits, often seen as an S-curve in the BOT graph. Conversely, the push-and-regress cycle is defined by the system actively reverting to its original status quo.
