TABLE OF CONTENTS

§ What Is Systems Thinking?
§ What Is a System?
     Collections Versus Systems
     Defining Characteristics of Systems
     The Importance of Purpose
§ Putting Systems in Context: "The Iceberg"
§ What Do Systems Do? A Close Look at Systemic Behavior
     Fun with Feedback
     The Building Blocks of Systemic Behavior: Reinforcing and Balancing Processes
     Looking for a Sign: Loops and Labels
     The Good, the Bad, and the Ugly: A Closer Look at Balancing Loops
     Delays: The Hidden Troublemakers
§ Putting It All Together: Two Examples of How to Manage Systems
     Managing Product Quality at FitCo
     Fixes That Backfire at DevWare Corp.
§ Working on the System, Not in the System
§ Appendix: "Acting" in Different Modes
§ A Glossary of Systems Thinking Terms

ABOUT THE AUTHOR

Daniel H. Kim is co-founder of Pegasus Communications, Inc., and co-founder of the MIT Center for Organizational Learning. He is also a trustee of the Society for Organizational Learning. Daniel is a leader in helping managers apply the power of systems thinking to tough organizational issues. As an international public speaker, teacher, and facilitator, he has worked with dozens of companies in developing their capabilities to become a learning organization. Daniel has a Ph.D. from the MIT Sloan School of Management and a B.S. in electrical engineering from the Massachusetts Institute of Technology.

EXCERPTS

Fixes That Backfire at DevWare Corp.

A lot of managers expend energy trying to "fix" things. If sales are too low, we do something to get them higher. If yields are too low, we try to get the team responsible for yields to improve performance. If profits are down, we cut costs to boost the bottom line. We may be quick to congratulate ourselves when conditions improve in the short run. But, in many cases, the problem eventually returns to the same level as before—or gets even worse. We end up having the odd sensation that our supposed "fixes" are backfiring on us.

To illustrate, let's look at DevWare Corp., a hardware-development company. DevWare is facing an all-too-common situation, in which managers' well-intentioned actions produce the exact opposite of what they wanted. One day, Toby, a manager in the company's product-development program, notices that the number of parts behind schedule is alarmingly high. If this continues, he decides, the team won't be able to launch the product on time. His conclusion: that the engineers need tighter supervision and a review of all parts in order to get the message that the number of parts behind schedule has to come down.

Sure enough, once Toby focuses his attention on the parts problem, the late parts start moving briskly through the pipeline. But after a while, the parts problem returns. And when Toby focuses on it once again, things improve again—but not as fast as before. Over time, the more attention Toby places on the problem, the worse the problem becomes. What's going on?

Well, Toby's attention to the late-parts problem came in the form of requiring more review meetings to check the status of parts—especially parts that were running late (see "The Problem with Review Meetings"). All those meetings took time away from actual engineering work. So, rather than reporting problems with their parts as they arose, the engineers began waiting until they already had solutions to the problems. This meant that other engineers would find out about changes affecting their parts much later than they used to (see the R loop). As more and more engineers withheld information, more parts fell behind schedule—a situation that reinforced Toby's belief that he needed to continue "helping" the engineers. The end result—a steadily worsening problem of late parts—was something nobody in the system wanted. Yet both Toby and the engineers were unintentionally colluding to create this very situation.

A higher-leverage solution in this situation would be for Toby to take a very different kind of action than the review meetings he had been imposing. For example, if he had encouraged the timely reporting of problems—and promised not to "penalize" the engineers with more reviews or brow beatings—the engineers would have gladly reported problems sooner. Eventually, the number of late parts would have fallen dramatically. (However, this would have happened only after the problem got worse first. This "worse before better" outcome is a classic example of how complex systems behave. Once again, delays are the culprits in this dynamic.)

As you may have begun sensing in the FitCo and DevWare examples, everything really is connected to everything else. Yet no matter how narrowly we choose to define a system, that system ignores our arbitrary definition and responds to all the relevant interconnections. As a result, there are many unintended consequences of our actions on a system, in addition to the intended consequences. Indeed, the issue is never whether our actions will have unintended consequences, but rather to what degree and what kind of consequences they will have. Mapping the possible unintended as well as intended consequences of our actions in causal loop diagrams can help us anticipate and address problems before they arise.