Managing For Innovation

Watts Humphrey is best known for his work on software process at the Software Engineering Institute. His first book, Managing the Software Process [2], and his subsequent writings on that subject, are likely among the most significant works in the field of software engineering, and that work on process has been at the heart of most important discussions of software engineering topics for at least two decades.

Two years before his first process book, Humphrey wrote another book, Managing for Innovation [1]. This earlier book attracted almost no attention over the years, and yet in many ways it may be just as important as the better-known one. It was republished in 1997, as Managing Technical People [3] and—to the best of my knowledge—that version 2.0 book remains as little-noticed as the earlier one.

The subtitle of the innovation book is "Leading Technical People" (it is interesting that this subtitle graduated to the title of the version 2.0 Managing Technical People), and the idea behind both books is that people matter a lot in building software products. The books are about innovative technical software people and the role of managerial leadership in enabling that innovation. That makes the books a fascinating juxtaposition with Humphrey’s later process work, since in that later work he has taken the position that process (not people) is the key to software success.

But back to the earlier Humphrey book and its successor version 2.0. What is the relationship between innovation and creativity? Humphrey—quoting Theodore Levitt—puts it very succinctly: "Creativity is thinking up new things. Innovation is doing new things."

Humphrey goes on to add, "While innovation requires creativity, it also involves a great deal of hard work."

The book is about both creativity and innovation, although Humphrey is clearly more interested in the latter, because it is in the "doing"—the so-called "hard work"—that management’s role comes to the fore.

What does Humphrey have to say about the intricate relationship between management and the creative technical person?

Regarding control, he reports findings from the literature that "managers who tightly control the way their people work generally get significantly less creativity than those with a looser and more informal style."

Regarding management technical knowledge, he reports other findings that "when the manager’s ability was limited, innovation was highest when the group was given the greatest freedom."

"When the manager was highly skilled in administration, personnel, and technology," Humphrey went on, "the results were mixed; sometimes freedom helped, but sometimes it did not." Humphrey concludes with an old saying: "If you don’t know what you’re doing, then stay out of the way!"

Looking at the matter from a different point of view, Humphrey examines studies of successful and unsuccessful groups. "In the most innovative, the managers personally involved themselves in the work and maintained close technical contact with their people. For the least innovative, the managers were less active and more remote."

Is there a lesson to be drawn from this material? Perhaps it is "the most innovation comes when (a) the manager has technical skills and involves himself or herself in the group’s work, while (b) maximizing the amount of freedom given his technical people."

Is technical creativity the most important factor in successful innovation? According to Humphrey and the studies he cites, the answer is no. In fact, the "persistent tendency of technical people to confine themselves to the laboratory and not to seek a detailed understanding of the user’s needs" is one of the foremost reasons for research and development failure, he says.

What is the alternative to the laboratory-confined technologist? "Successful product development depends more on market astuteness than on technical competence," he says, quoting a University of Pennsylvania study. The most innovation, in fact (according to another study), comes "when the users were technically competent." That is, users, understanding the application problem to be solved, are more likely to produce innovation than computer technologists, who understand only the computing problem to be solved. Humphrey goes on to cite another study that found "75% of all innovations … came from market sources, but the highest percentage of technically driven innovations given by any single study was only 34%." That is, customer need, rather than technological progress, determines whether an innovation is likely to be successful or not. (Sounds familiar, doesn’t it? It’s a new variation on the old theme, "necessity is the mother of invention.")

An interesting aside in the book deals with the issue of how age affects creativity. Although there is a common belief that creativity and innovation peak at a fairly early age (it has been cited as being anywhere from 21 to 29), Humphrey says there is an increasing body of evidence that points the other way. In one study, the researchers found that performance peaked at an early age but declined very slightly thereafter. The precise point at which this peak occurred depended on the technical field; it was earlier in the more abstract fields of mathematics and theoretical physics and later in such pragmatic specialties as biology and geology. The initial peak fell in the mid-30s, but a later peak was also found in the mid- to late-50s. This double-peak phenomenon occurred in all the groups of engineers and scientists studied, and the dip between these two peaks was not very significant.

Humphrey summarizes with an encouraging thought (at least for older readers): "For creative people, the late 30s and early 40s is a highly stressful period. Once they pass this hurdle, however, many engineers and scientists will continue their creative work for many years…many of Thomas Edison’s 1,100 inventions were produced late in his 84-year life."

From the point of view of managing for innovation, then, good leaders must know that any of their people, of any age, may contribute creativity and innovation.

These Humphrey books on the importance of people in the software process should be considered of equal significance with Humphrey’s better-known process work. Both practitioners and academics will be enriched by reading either of these people-focused books—practitioners will see the books as an acknowledgment of their contribution to software process success, and academics will come to a better understanding of what constitutes successful practice.

Back to Top

Back to Top

Back to Top