Learning When to Stop Momentum

Teams that fight wildfires have much to teach business managers about preventing complex and dynamic problems from spiraling out of control.

Image courtesy of Flickr user Lou Angeli.

In May 2000, events overwhelmed a fire crew working to burn out an overgrown 300-acre area at the Bandelier National Monument in New Mexico. A tiny patch of flame, which kept flaring up every time firefighters thought they had put it out, eventually escaped and grew into the Cerro Grande wildfire, one of the most devastating in our nation’s history and the cause of $1 billion in damages to the city of Los Alamos and the adjacent Los Alamos National Laboratories. Eighteen thousand people were evacuated; and two weeks later, by the time the fire was finally stopped, some 47,000 acres had been consumed and 300 homes and laboratory buildings destroyed.1 Like most disasters, many factors contributed to Cerro Grande. But an important one was what we call “dysfunctional momentum,” which 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. What happened to the firefighters in New Mexico is not unusual. Dysfunctional momentum arises daily in organizations, and sometimes with dreadful results. The members of a project that spiraled out of control look back and wonder: How did we get there? How did we miss the cues that might have signaled huge problems ahead? Or, if they did see the cues: Why didn’t we change course?

The Leading Question

How does dysfunctional momentum come about and what can managers do to prevent it?

Findings
  • When engrossed in an action, we tend not to notice small problems that may grow into large ones.
  • To overcome dysfunctional momentum, we have to be interrupted or create an interruption ourselves.
  • Practice ‘‘situated humility.” As no one person can solve the problem alone, diverse input is essential.

Business disasters, like many wildfires, often start out small, with little problems that managers notice but don’t worry about too much.

Read the Full Article:

Sign in, buy as a PDF or create an account.

References

1. K.E. Weick and K.M. Sutcliffe, “Managing the Unexpected: Resilient Performance in an Age of Uncertainty” (San Francisco: Jossey-Bass, 2007), 2.

2. C. Perrow, “Complex Organizations: A Critical Essay,” 3rd ed. (New York: Random House, 1986).

3. C. Perrow, “Normal Accidents: Living with High-Risk Technologies” (New York: Basic Books, 1984).

4. S. Fiske and S. Taylor, “Social Cognition: From Brains to Culture,” 2nd ed. (New York: McGraw-Hill, 1991).

5. D. Vaughan, “The Challenger Launch Decision: Risky Technology, Culture and Deviance at NASA” (Chicago: University of Chicago Press, 1996), 124, 141, 143, 179.

6. B.A. Turner, “Organizational and Interorganizational Development of Disasters,” Administrative Science Quarterly 21, no. 3 (September 1976): 378-397.

7. K.E. Weick, “The Collapse of Sensemaking in Organizations: The Mann Gulch Disaster,” Administrative Science Quarterly 38, no. 4 (December 1993): 628-652.

8. A. Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly 44, no. 2 (June 1999): 350-383.

9. J. Dewey, “Human Nature and Conduct,” 2nd ed. (Mineola, New York: Dover, 2002), 178.

10. Weick, “Managing the Unexpected Complexity,” 161.

11. R.L. Daft and R.H. Lengel, “Information Richness: A New Approach to Manager Information Processing and Organization Design,” in “Research in Organizational Behavior,” ed. B.M. Staw and L.L. Cummings (Greenwich, Connecticut: JAI Press, 1984), 191-233.

i. K.M. Eisenhardt, “Building Theories from Case Study Research,” Academy of Management Review 14, no. 4 (October 1989): 532-550.

3 Comments On: Learning When to Stop Momentum

  • WILLIAM HARROD | April 2, 2010

    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.

  • dvtent | June 18, 2010

    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

  • David | May 3, 2011

    > 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

Add a comment