Definition of systems thinking

Perhaps the most successful learning technique we are taught as we are growing up is the method of analysis by decomposition, in which we break complex things down to the level where we can understand the individual parts. This works for many things, but for dynamic systems, particularly those that involve humans, the usual effect is to squeeze out some of the most important features.

Systems thinking is an approach that draws attention to connections among the parts, particularly focusing on how the elements of a system feed back to one another, both creating extraordinary patterns of growth (amplifying feedback) and providing ways to control the system (regulating feedback).

When Fred Brooks was charged with managing the development of OS 360 (a computer operating system), a large initiative at IBM, he learned that as the project got behind schedule his bosses responded by providing him with additional programmers. They imagined that by increasing the number of programmers, more time would be spent on designing and programming so that more of the programme would be completed, eventually getting them back on schedule.

In fig.1 below, known as a cause map, the arrows represent the effect of one factor (at the tail or an arrow) on another factor (at the arrow’s head). A ‘+’ sign means that when the first factor changes (say “Time behind schedule”) the second factor (“Number of programmers”) tends to change in the same direction.

Fig. 1

cause map - fig 1

Click here to view fig. 1 cause map

That is, when you are behind schedule, management hires more programmers, when you are ahead of schedule, some of them may be laid off. When you are able to proceed from one factor, through others, back to the original factor, you have a cycle, known as a feedback loop. The four arrows in this diagram define such a feedback loop. There are two kinds of feedback, negative (regulating) and positive (amplifying). The former can be identified by an odd number of ‘-’signs; the latter by an even number.

The diagram above, with its odd number of minus signs, contains a regulating loop. Such a relationship among the parts brings the system into balance. It was anticipated that by adding programmers, the project would become stable again.

It was only years later that Brooks understood why, rather than functioning as anticipated, added resources only made the situation worse. In fig. 2 below, the diagram  shows an amplifying loop that produced positive feedback (an even number of minus signs).

Fig. 2

cause map - fig 2

Click here to view larger version of the above fig. 2 cause map

As new programmers were added, more time was required to bring them along. This, in turn, reduced the amount of time experienced programmers had to spend producing code. As they completed less of the program, the time behind schedule and the demand for more programmers grew, and still more time was consumed by education and communication. This dynamic is now known as Brook’s Law:

“Adding programmers to fix a delay, only makes it take longer.” [1]

FT Articles & Analysis

No articles are associated with this term