One of the first topics covered in all the systems dynamics discussions I've seen is the correct use of the word "feedback." As Sterman states:
In common parlance the term "feedback" has come to serve as a euphemism for criticizing others, as in "the boss gave me feedback on my presentation." This use of feedback is not what we mean in system dynamics. Further, "positive feedback" does not mean "praise" and "negative feedback" does not mean "criticism." Positive feedback denotes a self-reinforcing process, and negative feedback denotes a self-correcting one. Either type of loop can be good or bad, depending on which way it is operating and of course on your values. Reserve the terms positive and negative feedback for self-reinforcing and self-correcting processes, and avoid describing the criticism you give or receive to others as feedback. Telling someone your opinion does not constitute feedback unless they act on your suggestions and thus lead you to revise your view.
Tonight I tweeted the following:
Businesses seek to stimulate positive feedback loops. Engineers try mightily to avoid them. Essence of the IT/business divide?
This tweet was asking for trouble, and I got it:
@maidenelk: @CharlesTBetz Not sold. Agile seeks short feedback loops and is generally championed by engineers.
@adrianpomilio: @CharlesTBetz @steveburnett not a fair statement. Breakdown on both sides. The "blame engineers" line doesn't wash anymore.
@adrianpomilio: @CharlesTBetz @steveburnett engineers that I know want useful and continual feedback And short feedback loops.
It's pretty clear my respondents weren't using the same definitions as I was. What did I mean by my initial tweet?
A positive feedback loop is amplification. It is self reinforcing. Positive feedback, often of the exponential variety, can be seen in nuclear chain reactions, epidemics, overpopulation, economic bubbles, and similar negative scenarios. Bridges fall down because of positive feedback. Negative or "balancing" feedback is the opposite, tending to make systems stable through ongoing self-correction.
In computing, a positive feedback loop, unbounded, will result in the system running out of resources. Cascading faults, runaway processes, out of control memory leaks - all might be caused by positive feedback within the system. Negative (i.e. balancing) feedback can be found in the various monitoring and control mechanisms that have evolved to ensure system stability.
In software and systems engineering, some common dysfunctions can be characterized as positive feedback loops, such as Fred Brooks' truism that adding more people to a late project makes it later. (See Madachy's Software Process Dynamics for a rigorous modeling of this dynamic.)
Hence the assertion that for engineers, positive feedback is usually a Bad Thing. At least, it needs to be carefully understood, tuned, damped, and controlled. This is not blaming engineers.
In business, positive feedback also can be dangerous, but I think the difference here is that most businesses are trying to provoke a form of virtuous positive feedback: the creation of a compelling product that creates market demand that enables the further development of the product resulting in further demand and so forth. The network effect is a corollary dynamic. All the great success stories that pervade our business mythos are based on these effects.
Engineers deal with bounded systems and limited resources, while the entrepreneur -- the person seeking to trigger a network effect -- in general is doing so in an unbounded context, at least for the time being. (At some point antitrust laws and other limits kick in, but such remote system boundaries don't usually dissuade the fledgling entrepreneur.) There may be any number of reasons why they don't succeed, but their efforts don't start from a position of "positive feedback is dangerous."
What about Agile? "Agile seeks short feedback loops." What is meant by that? This is first a statement about frequency, and not whether the loop is balancing or positive. Agile feedback loops are primarily a balancing mechanism, I believe - they seek a stable cadence of delivery through ongoing course corrections.
And hence the original tweet. Engineers seek balancing feedback, and are inherently concerned with the risks of reinforcing feedback. Entrepreneurs may be aware of vicious cycles as well, but are distinct from engineers in that their raison d'etre is to create a special form of reinforcing feedback. Is this perhaps a cause of, or at least contributory to, the notorious "IT/business divide"?
So, apologies for trying to pack too much perhaps into one tweet. Hope this clarification is somewhat helpful. After this, I think that I may stick to the less charged terms "reinforcing" and "balancing" feedback, as some in the systems dynamics field advocate.
Of course this is mere late night conjecture, food for discussion, and nothing more rigorous. I suspect it's also well trodden territory for experienced systems dynamicists, of which I am not yet one.
PS thanks to Peter Kretzman (@PeterKretzman) for prompting me to blog on this.