Historian Arthur Schlesinger spoke of the balance between the need for heroes and the problems with hero worship when he said the following:

To say that there is a case for heroes is not to say that there is a case for hero worship. The surrender of decision, the unquestioning submission to leadership, the prostration of the average man before the Great Man – these are the diseases of heroism, and they are fatal to human dignity. History amply shows that it is possible to have heroes without turning them into gods. And history shows, too, that when a society, in flight from hero worship, decides to do without great men at all, it gets into troubles of its own. [1]

This article discusses how organizations can use heroes to support process improvement efforts and how processes can help alleviate some of the problems created by dependence on heroes.

One of the basic ideas in the Capability Maturity Model^® Integration (CMMI^®) is that organizations move away from an atmosphere of ad-hoc or even chaotic processes towards an atmosphere where structured processes are in place and everyone looks for ways to continually improve.

An organization operating at an initial level or Level 1 typically has few processes in place. The success of the organization depends on the individual effort of key people or heroes. The Software CMM^® states the following:

Success in a Level 1 organization depends on the competence and heroics of the people in the organization and cannot be repeated unless the same competent individuals are assigned to the next project. [2]

This kind of atmosphere puts a lot of stress on both the heroes and the organization. Low maturity organizations are very dependent on the talent of their heroes. As a result, they are poorly equipped to deal with talent shortages. The heroes are asked to do more and more while others in the organization are asked to do less or given minor assignments. This sets the organization up for potential failure if highly skilled individuals leave. By not establishing processes and involving more members of the organization, it limits its ability to improve performance.

This is especially true as software projects become more complex. In “The Art of War,” Sun Tzu said, “In ancient times, those known as heroes prevailed when it was easy to prevail” [3]. The same can be said of software projects. It was easy for heroes to rule the day when software projects were relatively simple and customers were not as demanding. Now that customers have become aware of the capabilities of software systems, they are more demanding. The requested products are more complex. As projects become more complex, the reliance on a small group of heroes to develop the software brings more risk. To alleviate that risk, more people need to be able to contribute to the development effort.

In 1968, Alan J. Perlis told the NATO Science Committee:

We kid ourselves if we believe that software systems can only be designed and built by a small number of people. If we adopt that view this subject will remain precisely as it is today, and will ultimately die. [4]

The development of software systems has changed a lot since 1968; however, some organizations continue to depend on a small group of heroes in their development efforts. If organizations continue to view software development as an art form practiced by a few individuals, Naur’s prediction of doom may come true in terms of unhappy customers and lost business.

The problem with heroes does not rest only with the heroes. Managers may encourage unhelpful behavior by relying too much on their heroes. It is easy for managers to rely too much on heroes to complete complex projects. However, if those projects are left solely in the hands of the heroes, the organization misses an opportunity to build a stronger workforce. The reliance on heroes can make an organization weaker in the long run. By handing complex projects to a hero, an organization can create a single point of failure if that hero is unavailable or if the hero leaves the organization. The days when a small group of experts could be successful by controlling thousands of lines of spaghetti code are long past. Managers create their own problems if they establish such a situation.

The best example of the hero syndrome was told to me by an individual who worked for the Air Force. One of the main systems used by the base where he worked was written, maintained, and completely understood by one individual. Unfortunately, that individual was in a bad car accident, hurting his back, and would be out of the office for a few months while he recovered. No one else knew what to do with the system he maintained. This was before the days of remote connectivity, so the organization had to set up a special terminal and arrange for him to be transported in on a gurney for several weeks so he could show what he did to someone else. It doesn’t have to be a major car accident – it could be job turnover or a winning lottery ticket. By placing too much control into the hands of too few people, an organization sets itself up for a potential crisis.

Heroes often hoard information and create a number of potential problems. They can be an impediment to completing work because development activities come to a halt if they are not available. If they hold too much knowledge, others are unable to complete work unless they get the information they need from the heroes. In extreme cases, an organization can find itself held hostage by its dependence on its heroes. In one situation, a hero was given control over an organization’s configuration management system. The hero would change other people’s code without their knowledge. The original developer was unable to fix any defects that were identified because the final code did not match what was originally written. The hero had to come in and save the day. Of course, the hero was saving the organization from problems of his own creation. Management rewarded that behavior, which only exacerbated the problem.

To avoid this situation, managers need to coordinate the creative work of their developers so they support rather than interfere with each other. The knowledge and understanding of the system and the processes used to develop it must be spread out across a larger number of people to enable an organization to better deal with complex situations. Heroes can use complexity to their advantage. By making a system so complex that only the heroes understand it, an organization can find itself at risk. The pieces of such complex systems need to be compartmentalized for easier understanding and construction. In such a situation, an organization can use its heroes’ expertise and concentrate their attention on the architecture of the system. Getting the heroes focused on the way the system is constructed will enable that organization to leverage its knowledge to more easily maintain pieces for the rest of the development staff.

In his book, “Managing Technical People,” Watts Humphrey gives the example of jazz musicians to illustrate the importance of people working together [5]. Individual musicians study at a conservatory to hone their skills through rigorous training. They learn the discipline of playing instruments until a flawless performance is routine. It is only when those musicians come together that beautiful music is created. Jazz musicians have mastered their instruments and techniques to the point that when they play together, they can improvise on a theme to create something truly special. In terms of software development, the discipline of process takes care of the mundane performance issues by establishing routine. With those issues addressed, the process enables more creative work.

This is not to say that heroes and key performers must go away. They exist at every maturity level in the CMMI. The role that heroes play in an organization changes as the organization becomes more mature in process terms. At the lower maturity levels, heroes drive the completion of the work either through their own efforts or by serving as an example for others. Most heroes are successful for a reason. While some are undisciplined, many have developed intuitive processes that they routinely follow. An organization can use their informal processes followed by their heroes as the basis for formal processes that will guide the work of others.

In my own organization, estimating was a constant problem. The heroes on one project were called upon to estimate all of the change requests. It was discovered that they all followed a similar intuitive process in creating estimates. The heroes were brought together and their intuitive processes were committed to paper. Values were assigned to the variables they considered in their mental process to create an estimating formula. The heroes bought into the process because they had some structure to fall back on when estimating that matched their intuition. With the formulas in place, management could now task others with deriving estimates, and the heroes had more time to concentrate on development work. By documenting the intuitive processes used by the heroes to be successful, an organization can free up creative time for their heroes because they will not have to answer as many basic questions and others will be able to take some of the more routine work. At the higher maturity levels, heroes are free to become their organization’s innovators.

When processes are improvised by the heroes to react to a crisis, it’s difficult to maintain process discipline. Processes are often thrown out to deal with the issues of the moment and success is dependent upon the heroes. In this situation, managers have a difficult time understanding the status of their projects because they are reacting to today’s crisis. In low maturity organizations, managers can unknowingly abdicate their responsibilities to their heroes in order to get things done. Managers need to stop rushing from fire to fire and take control of their projects by sticking to the established processes. This means controlling the heroes’ natural instinct to jump in and save the day. There are times when heroes need to save the day, but those times should not be the norm.

Successfully implemented processes should reflect how the work is being done. The heroes play a role in documenting the processes that will be followed. As mentioned earlier, those processes may come from the successful approach already followed by the heroes. Another way to involve the heroes in the process definition efforts is to cast them in the role of devil’s advocate. Since many of the heroes have an understanding of better ways to do things, they can be used to find flaws in the processes being developed. Some heroes may resist change, but using them in the devil’s advocate role can engage them in the process improvements. As processes are documented, management needs to ensure that the processes are followed. By establishing and enforcing the use of processes, an organization can reduce some of its dependency on heroes by elevating the performance of the rest of the staff. The heroes can then turn their attention away from fighting fires since fewer fires will exist.

Heroes like challenges. By giving the routine work to others in the organization, managers can channel heroes to more challenging work. With established processes in place, the heroes can be moved to work on other critical projects and the process will survive. The project will not collapse because the single point of expertise is gone. Knowledge is shared throughout the project and the people remaining on the project continue on without loss of quality or understanding. The organization must be sure that the heroes are not left alone to work on the next complex project or the problem situation can happen again.

The establishment of processes allows people in an organization to develop their potential more quickly. Most importantly, new people are able to become more productive more quickly because the infrastructure is in place to support them. The status of the project is better understood because the process and the infrastructure are in place. Status does not depend upon the knowledge of the heroes. If change is brought into the organization, there is a better chance that it will be successful because the process discipline is understood. Change and the possible improvement it brings are not dependent on whether or not the change matches the heroes’ preferences.

Once again, Sun Tzu says it well when he points out the following:

Good warriors seek effectiveness in battle from the force of momentum, not from individual people. … Therefore, when people are skillfully led into battle, the momentum is like that of round rocks rolling down a high mountain – this is force. [3]

Heroes can be brought into process improvement efforts and used to establish the processes and help the other developers in the organization. The key in using heroes for the good of the organization is management’s willingness to change the way they view heroes. Managers need to leverage the good qualities that heroes bring and minimize the hero worship that can create dependence on their worst tendencies. While individual people are important, it is the momentum built by preparing them for whatever task is at hand and giving them the discipline and tools they need to be successful. Then, the leadership can leverage the discipline to build momentum and generate the force Sun Tzu mentions.

1. Schlesinger, Arthur M. “The Decline of Heroes.” <www.quoteland.com>.
2. Paulk, M., et al. The Capability Maturity Model: Guideline for Improving the Software Process. Boston: Addison-Wesley, 1995.
3. Tzu, Sun. The Art of War. Trans. Thomas Cleary. Boston: Shambhala, 1988.
4. Naur, P., and B. Randell. “Software Engineering: Report on a Conference Sponsored by the NATO Science Committee.” Garmisch, Germany: 7-11 Oct. 1968.
5. Humphrey, Watts. Managing Technical People. Boston: Addison-Wesley, 1997.

Paul Kimmerly has 20 years experience in software development for the different incarnations of the United States Marine Corps Technology Services Organization in Kansas City (TSO-KC/KGB), Mo. A member of the Software Engineering Process Group (SEPG) since 1993, he has served as the group’s lead for the past 12 years. Kimmerly is an authorized Standard CMMI Assessment Method for Process Improvement Lead Appraiser. He presented at the 1997 and 2000 Software Engineering Symposiums and the 2004 National SEPG conference, and has contributed several articles on process improvement to CrossTalk .

TSO-KC/KGB
1500 E 95th ST
Kansas City, MO 64197
DSN: 465-5364
Phone: (816) 926-5364
Fax: (816) 926-6969
E-mail: paul.j.kimmerly@dfas.mil