Perhaps the real “innovator’s dilemma,” Professor Hargadon observes, is the danger that true inventiveness poses to an engineer’s employment status when organizational insecurity and controls overpower the Dionysian spirit.
“The early Apple portables were huge hits, for instance,” he says. “Everybody loved them. But internally at Apple, they were basically career-ending failures for some of the people who worked on them.” The innovative process that leads to the kind of insanely great products that Apple is known for has, along the way, false starts, experimental mishaps, and perceived failures that can reverberate adversely on individuals’ reputations.
Much of Professor Hargadon’s work focuses on the reasons companies tend to spend their time holding back the flood of learning for fear of being swept up in a breakthrough wave. He further argues that companies are often better off with only a small amount of innovation: Many of the most successful companies intensively focus on balancing freedom and flexibility with absolute operating efficiency. Intel, for example, restricts its innovation to a few technological domains, and practices fierce control otherwise; once the company is happy with the design of a wafer fabrication plant, it will “copy it exactly” in its other locations, says Professor Hargadon, “down to the paint on the wall.”
Climates of Creativity
In conversation, Professor Hargadon veers back and forth between his two innovation imperatives: connection and control. Although he has a naturally sunny temperament, you can occasionally see flashes of the curmudgeon within, as he grimaces at those who would take lightly the many challenges of building an innovation culture.
Professor Hargadon himself is an open source supporter. “Where did Disney get its start?” he asks rhetorically. “From Steamboat Willie, which was an adaptation of an older Buster Keaton story. Beauty and the Beast, Cinderella, and Sleeping Beauty were all in the public domain.”
But Professor Hargadon doesn’t regard open source, or any generic policy or practice, as a panacea for innovation in itself. Instead, he keeps referring to the culture of the organization — the subtle, informal practices that add up to a corporate ethic and climate.
Professor Hargadon first became interested in the nature of innovative cultures during his time at Apple. His background then included a master’s degree in mechanical engineering from Stanford, and a stint at the celebrated Palo Alto–based innovation design firm IDEO. He had studied then-leading academic books on the subject, such as Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality (Free Press, 1992), by Steven C. Wheelwright and Kim B. Clark. But, as he put it in a recent conversation, “All that stuff about how innovation is in the hands of leaders and the way you structure the organization, well, it just didn’t jibe with the life I was living.”
Take brainstorming, for instance. In the early 1990s, prevailing academic thought was that brainstorming didn’t work. When researchers formed brainstorm groups (typically of undergraduates), the sessions were dull and lifeless. Yet at Apple and IDEO, Professor Hargadon had experienced breakthroughs emerging from brainstorming. He only gradually realized the reason: Whereas students had nothing at stake, technologists used the brainstorming sessions as status-seeking opportunities. These were the opportunities, as Professor Hargadon later put it, to “impress other people with the creativity of their thinking.”
However, even though brainstorming intrinsically promoted innovation, other aspects of engineering culture subtly killed it — by making it a status-degrader. For example, like many technology companies, Apple had unconsciously enshrined a rule that engineers should never raise a problem unless they already had the solution. Problems were assigned a letter grade: A for “must-fix,” B for “should-fix,” and C for “might eventually get around to solving.” A true innovator, Professor Hargadon realized, would benefit from having a dozen or so “A” problems listed: This was an invitation for fertile, collaborative experimentation aimed at figuring out workable solutions. But in the Apple culture of that time, having “A” problems was a sign of incompetence. Engineers worked so hard to avoid public mistakes that they suppressed many new ideas rather than risk showing up with half-baked solutions to problems or, worse, no solutions at all.