Winning the Battle, Losing the War?
by Pat Craig 

From the Spring 1998 issue of the Complexity Management Chronicles 

In today's world, heroes are often thought of as role models or saviors. The "savior syndrome" is touched upon in the book, Built to Last. Given that most software develoment involves teams, we wonder about corporate cultures that encourage heroes. Do these cultures help or hinder software development capacity - both in the short and long term? Can certain tactics, such as relying upon heroes "win the battle" by shipping a specific software release date on time? But, can those same tactics possibly "lose the war" by reducing development capacility in the long term? In reflecting upon the business need for heroes, we gathered data from various sources: past client experiences, conference materials, and books. This newsletter summarizes our thoughts.

Certainly a company in crisis mode often requires a hero to save the day. But management should ask, "Has depending upon heroes become routine?" Management should also look for the source of the crisis by asking, "Was this crisis create artificially so that someone could look good?" G. Roth and Al Kleiner, published in the Harvard Business Review last fall, call people who create crisis (so they can solve them), "Fire fighting arsonists." We have witnessed numerous fire fighting arsonists at client sites. For the sake of brevity, we will provide only one example here. At a third party software client company, a key developer delayed producing tangible software until practically the day he had promised it to clients. Then, he "rescued" the product by working around the clock.

In The Fifth Discipline Fieldbook, the authors mention that the long-term unintended side effect of heroism is that people realize that if they want to be recognized for accomplishments, they'll have to be "heroes" too. Gradually, the company ends up with more and more "heroically" created crisis.

We have worked with two teams who have done well without heroes. One team, an imaging group, contained personnel representing all facets of software development. Each team member took the lead for a specific phase of software development (requirements, build, test, train, and implement). At last year's Association of Quality and Participation (AQP) conference, they spoke about the need for each team member to be able to lead at times and to  follow at other times. So it was with the imaging group.

Another team, a telephony group, had a very complex product that received input from 76 sources. Because of the complexity, the group's manager insisted that the entire team review all major work specifications. The manager reasoned that the collective intelligence of many minds would create better solutions than just one or two minds. The group took review sessions seriously; members came prepared, focused on the topic, and offered suggestions in a helpful way. These meetings seldom took longer than an hour and a half, and achieved impressive results. (F. Brooks, in his revised version of The Mythical Man-Month, reiterates his belief that a major stumbling block to break through software productivity gains is software complexity). By participating in these reviews, we have witnessed the power of collective intelligence.

We have concluded that employing heroism to get things done, such as ship software, endangers short-term and long-term capacity. In the short-term, a hero culture is risky because success depends on one person. In hero cultures, the other members of the organization begin to see that a "Winner Take All, (Win-Lose) situation exists. Once they realize this, many will seek opportunities outside the company. Some adopt a passive-aggressive stance where they stay put, but turn-off mentally, offering only grudging compliance, and morale suffers. Others become fire fighting arsonists so that they too can become heroes. All in all, development capability suffers.

©Complexity Management 1998
Somerville, Massachusetts
Located in Metropolitan Boston 


Complexity Management Chronicles, a newsletter for software quality assurance professionals, is published in print form four times a year. Send your name and snail-mail address to the e-mail address below if you would like to be on the mailing list - at no cost to USA mailing addresses. 

Return to Complexity Management Home
Contact Pat Craig at