Teams that fight wildfires have much to teach business managers about preventing complex and dynamic problems from spiraling out of control.
Dysfunctional momentum” occurs when people continue to work toward an original goal without pausing to recalibrate or reexamine their processes, even in the face of cues that suggest they should change course
In the authors’ study of firefighting teams as a metaphor for business organizations, where dysfunctional momentum arises daily, they found that it has at least five possible causes: (1) an overemphasis on action and decisiveness, which often precludes meaningful assessment along the way; (2) evaluating people, processes and outcomes against plans rather than reevaluating the plans themselves; (3) the cumulative effects of small changes that can ripple and grow throughout the organization; (4) the tendency to ignore or co-opt disconfirming evidence; and (5) deference to authority even when leaders are not especially in the know
To overcome dysfunctional momentum, the authors conclude, we have to create interruptions–points at which we can ask: What’s the story now? Is it the same story as before? If not, how has it changed? And how, if at all, should we adjust our actions? The people in charge need to stop and reassess what is happening around them.
Two interconnected factors tend to be instrumental, say the authors. First, individuals have to recognize their own inability to understand fully and predict the unfolding situation by themselves–they have to develop “situated humility.” Second, they must actively create or seek out disruptive information–they have to accept interruptions so that people may reevaluate the story they are maintaining in their minds.
3 Comments On: Learning When to Stop Momentum
This article elegantly captures a fact we often see in complex projects – teams dedicated to deliver to plan, whilst missing key evidence that the plan needs to change. The best teams build in the ‘interruptions’ described in the article, or opportunities to step back and evaluate progress against the current environment, rather than the original plan.
More value can be gained from the interruptions by using an independent/objective evaluation at key points in the delivery cycle.
This article provides many interesting insights into dysfunctional momentum. Having been involved with the rescue of many high-visibility business initiatives, I would like to offer a few observations along the same line of reasoning. Usually there are multiple reasons that business failures occur including, poor communications, poor planning, refusal to abandon a poor plan, unrealistic expectations, myopic leadership, and ignoring the warning signs. There are always warning signs: budget overruns, missed schedule milestones, people bailing out….
Having rescued many technical projects, I find that technical managers are generally poor communicators and place technical excellence above managerial excellence. And, compounding this, the company or client may have unrealistic expectations about when a product can be delivered and at what cost. Teams many times tend to be overly-optimistic about what can be accomplished in a give time and scope. And, finally, I cannot stress enough the importance of planning. Too many times, people want to start implementing with the concept. However, it has been my experience that time spent planning is usually recovered during implementation–it is well worth the time spent. And, lastly, I find that teams tend to ignore or minimize potential problems. Many times, teams can learn to anticipate problems and develop mitigating solutions rather than wait for those end-of-project surprises. Hope this helps.
David Tennant
Atlanta
> Too many times, people want to start implementing with the concept. However, it has been my experience that time spent planning is usually recovered during implementation–it is well worth the time spent.
@David Tennant: Too right. I’ve been part of a few tech projects that needed rescuing and the problem is usually planning, and being too keen to get the coding (or other implementation) done before the project has been properly analysed and scoped.
Great article by the way.
David