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
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
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 firstname.lastname@example.org