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 its 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 term. 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.5

​

    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 lateparts 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.

​

    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.