The Myths of Innovation
(O’Reilly Media, 2007)
Sketching User Experiences: Getting the Design Right and the Right Design
(Morgan Kaufmann, 2007)
Brilliant! Shuji Nakamura and the Revolution in Lighting Technology
(Prometheus Books, 2007)
Dreaming in Code: Two Dozen Pro-grammers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
(Crown Books, 2007)
Joseph Schumpeter, the eminent 20th-century economist who famously described entrepreneurship as a form of “creative destruction,” proffered a lesser-known, pithier epigram for 21st-century innovators. “Innovation,” he wrote, “is ultimately not an act of intellect but of will.”
If only it were that straightforward. Invariably, seemingly fundamental truths about innovation turn out not to be true; yet somehow even the most disruptive technological innovations end up reaffirming the hoariest innovation clichés. To CEO and entrepreneur alike, it’s painfully unclear whether intellect, will, or plain dumb luck will end up playing the starring or the supporting roles when enterprises innovate.
Three excellent books about innovators and innovation in 2007 happen to be written by authors who come from the world of software development: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software, by Scott Rosenberg; The Myths of Innovation, by Scott Berkun; and Sketching User Experiences: Getting the Design Right and the Right Design, by Bill Buxton. The Japanese electronics industry is the setting for another worthwhile read, Brilliant! Shuji Nakamura and the Revolution in Lighting Technology, by Bob Johnstone. Collectively, these books do a comprehensive job of capturing what innovation means at this moment. Each book has a profoundly different sensibility and serves a specific business readership — from software programmers to industrial designers. However, all of them are compelling for general management consumption, and their rhetorical similarities are as serendipitously compelling as their differences.
One Day at a Time
Smart, talented, and determined people often “obey” only their own vision. That makes for great stories, albeit unhappy ones. Dreaming in Code is just such an unhappy tale, well told. Its lead character is Mitchell Kapor, who founded the Lotus Development Corporation, recruited software developer Ray Ozzie (now Microsoft’s chief software architect) and co-created with Ozzie and others the Lotus 1-2-3 software spreadsheet in the 1980s.
Kapor has always wanted to be a different kind of “infopreneur.” He has an eye for software talent and a fascination with the challenge of organizing personal information in novel ways. Taking aim at the global business culture of “proprietary software” development, Kapor helped launch the Open Source Applications Foundation, with a sensational team of programmers who set out to out-Google Google and out-Apple Apple in the design and development of a personal digital assistant product. Code-named “Chandler” (as in Raymond Chandler, the crime fiction writer), the project was intended to solve problems of personal information management that users didn’t even know they had. Chandler would allow individuals to organize and improvise all manner of personal management tools and effects, such as calendars, files, photos, and address books.
The project’s ambitions and plans were always a moving target, which is where its troubles began. Chandler’s likable cast of creative characters became foils for Scott Rosenberg’s examination of the painful software design trade-offs that were involved in Chandler’s complex innovation agenda. As a journalist “embedded” in the project, Rosenberg, a cofounder of Salon.com, the San Francisco–based online magazine), was witness to every meeting that mattered as this band of talented coders, hackers, programmers, and designers tried to rapidly reinvent a software genre. But as page after remorseless page of Dreaming in Code documents, these folks blew every deadline they set for themselves. You can almost feel Rosenberg’s sickening realization — and revulsion — as the project he’s decided to Boswell sinks deeper into the gooey tarpits of delay. As Frederick P. Brooks Jr., the IBM software architect who authored the classic memoir The Mythical Man-Month: Essays on Software Engineering (20th-anniversary ed., Addison-Wesley, 1995), once rhetorically asked, “How does a project get to be a year late?” His chillingly simple answer: “One day at a time.”
Dreaming in Code is a one-day-at-a-time narrative of despair that Rosenberg cleverly transforms from yet another classic software team innovation story into a morality tale about the importance of humility in the creative process. For example, he does an excellent job of recapitulating the history of postwar software development as a guide to the Chandler team’s missteps. Practically every one of the most painful design issues, problems, debates, and delays confronted by Kapor’s clever developers was anticipated in, believe it or not, a NATO Software Engineering summit in 1968.
Yet Rosenberg doesn’t indulge in schadenfreude as he observes how the Chandler folks slowly but surely repeat all known pathologies of the software innovation process. Rather, he marvels at the sheer absence of historical knowledge, perspective, and discipline. “The participants recorded their frustration with the lumbering pace and uncertain results of large-scale software development and advocated many of the remedies that have flowed in and out of fashion in the years since,” Rosenberg writes. The prescriptions included calling for “feedback from users early in the design process” and “doing something small, useful, now.”
Cruelly, but not unreasonably, Rosenberg describes Linux founding father Linus Torvalds — a man who has successfully overseen the introduction and evolution of an immensely important operating system worldwide — as a Cassandra who is respected but ignored. Torvalds admonishes, “Nobody should start to undertake a large project” because “you’ll just overdesign” and be overwhelmed by your vision. “So start small and think about the details. Don’t think about some big picture and fancy design.”
Still, there’s no false dichotomy between Kapor’s grandiose aspirations and Torvalds’s studied “smaller is better” innovation heuristic. In the grander scheme of things, Torvalds is every bit as ambitious as — if not more so than — Kapor and his Chandlerians. More important, though, the Chandler team’s ambition did not make it the victim of hubris, arrogance, or egomania. These were smart, levelheaded, hardworking people. Their problem was not a surfeit of pride but a shortage of humility, at least at the outset. Over the course of the project, the team humbled itself through repeated failure: busted deadlines, broken code, and a chronic inability to manage expectations cost-effectively. If Kapor and his team had brought even 20 percent of Torvalds’s wisdom into their innovation world view, the Chandler software — and Rosenberg’s book — would have been written rather differently.
Although you won’t find it in the book’s index, humility is also the de facto theme of Scott Berkun’s The Myths of Innovation. Baked into the book’s premise is the assertion that we think we know more about the meaning, media, and mechanisms of innovation than we really do. Formerly an interface designer on Microsoft’s Internet Explorer team, Berkun now writes and lectures on creative problem solving at the University of Washington. Myths does have an occasionally annoying “everything you know about innovation is wrong” tone, but Berkun has effectively synthesized much of the traditional literature on the subject and ruthlessly debunks the rubbish.
Students and practitioners of innovation will be familiar with many of the myths Berkun pops. But his accessible writing style makes reading the myths again a pleasure. And this is one of those books where the footnotes are as important, and as enjoyable, as the text. His chapter headings neatly summarize each of the myths he eviscerates, for example: “The myth of epiphany,” “We understand the history of innovation,” “There is a method for innovation,” and “Good ideas are hard to find.” He dismisses much of what the business press (and many academics) celebrate as common sense or best practice as anecdotal foolishness. Businesses serious about value-added innovation need to disabuse themselves of the notion that they’re simply one good idea — or a good methodology — away from success.
Innovation is hard, and sustained innovation even harder. That’s one essential reason that great confidence and competence need to be leavened by humility. How much humility? Without tongue in cheek, Berkun’s book calculates the probability of successful innovation:
As a back-of the-envelope sketch of innovation difficulty, let’s assume there’s a 50 percent [chance] of succeeding at each [previously discussed] challenge (which, given the data, is generous). Because success at one challenge is dependent on the previous, the probability of overcoming all challenges is low:
50% X 50% X 50% X 50% X 50% X 50% X 50% X 50% = .390625%
That’s less than 1 percent. Of course, if your innovation requires only convincing your friends to try a new poker variation or your boss to run meetings differently, you might face two (and not all eight) challenges and odds improve based on your skills, experience, and teammates. It’s safe to say that the smaller your ambition the better the odds. But dreams and passions, the saving throw against probability, might fade. And, as Han Solo said, “Never tell me the odds.”
That successful innovation seems so dependent on contingent probabilities seems both obvious and unfair. Yet, as Myths and Dreaming illustrate from radically different perspectives, very smart people consistently ignore the obvious and behave as if luck were on their side. As probability and history both affirm, they do so at their peril.
Playing the Game
Nevertheless, the innovation process, much like poker, is often as much a test of skill as of luck. The best poker players, like the best innovators, know how to manage risk, play the odds, and read the table. In Brilliant! Australian technology writer Bob Johnstone does a brilliant job of describing how well and how persistently an unsung Japanese scientist, Shuji Nakamura, played the innovation game in the electronics industry. You’ve likely never heard of Nakamura, but this engineer was able to solve technical problems that had stumped top electronics firms for more than two decades; he created, for example, the last piece of technology needed to manufacture solid-state white lights known as light-emitting diodes, or LEDs. In his own way, Nakamura’s discovery may prove as high-impact as those of high-tech entrepreneurs such as Intel’s Bob Noyce or Google’s Larry Page and Sergey Brin.
Johnstone’s profile of Nakamura builds on his fantastic book, We Were Burning: Japanese Entrepreneurs and the Forging of the Electronic Age (Basic Books, 1999), a sociocultural industrial profile of Japan’s electronics entrepreneurs and enterprises. Shuji Nakamura was one of the last and most innovative scientist/inventor/innovators Johnstone described in that book, and Brilliant! starts where Burning ends. In Brilliant! Nakamura is almost a caricature of the obsessed creator. He is simultaneously a scientist, a craftsman, and a revolutionary. Think of him toiling away in obscurity but growing more frustrated with his inability to have his innovations compete in the global arena.
But Johnstone offers up more than the standard bio of a lone scientist who triumphs in spite of seemingly insuperable odds. What he has written is the economic sociology of an innovation network, with Nakamura at its hub. What Nakamura does with lighting surely rivals the Bardeen, Brattain, and Shockley invention of the transistor in terms of potential. Just as Edison’s lightbulb redefined illumination in the last century, so Nakamura’s lasers and LEDs may do for this one, producing more light in more places at less cost and with less energy usage than the incandescent bulb. Edison would be envious.
What role does humility play for scientist/entrepreneurs who are intent on changing the world? In Nakamura’s case, he is a scientist so fluent in the materials he manipulates that his colleagues and students — both in his lab and in the worldwide “invisible college” of fellow innovators — are effusive in their expressions of respect for him, and single out his humility. Johnstone, quoting one of Nakamura’s students, writes: “What he showed us was how to do quick tests on our devices…. We assumed initially that you had to slap on your contacts before you could get any feedback, and that’s usually at least a half day’s work. He showed us a way to get feedback in essentially five minutes after the growth. Things like that, you know the man’s been in the lab himself and tried out these things.”
Note at the core of that quote the essential idea: the willingness and ability to design for accelerated feedback. In other words, Nakamura constantly seeks to swiftly test the validity of his innovation hypotheses. That humility facilitates the transformation of a technically interesting material into a patentable and profitable optical device.
Design for Innovation Handbook
Bill Buxton’s Sketching User Experiences is a lush, beautiful, and high-bandwidth book. It’s filled with photos, sketches, and notes laid out in a visually stimulating and inviting format. If you want to understand how your innovation ideas can slide seamlessly from sketches to animation to prototypes, it’s all here.
Buxton, now a Microsoft researcher but formerly a chief scientist at Silicon Graphics and Alias Wavefront and professor at the University of Toronto, has put together a handbook about design for innovation that is also intensely personal. Buxton himself is an idiosyncratic designer with good taste and strong opinions. There’s plenty to disagree with. However, one cannot read this book in good faith without constantly thinking, “Hmmm…could I use this…there…?” Sketching is filled with case studies, examples, tools, and boldfaced aphorisms. As demonstrated in this passage, Buxton also energetically — almost aggressively — defines what he means by having humility in the design process: “People on a design team must be as happy to be wrong as right. If their ideas hold up under strong (but fair) criticism, then great, they can proceed with confidence. If their ideas are rejected with good rationale, then they have learned something. A healthy team is made up of people who have the attitude that it is better to learn something new than to be right.”
He concludes: Design is compromise.
Much of Buxton’s appeal comes from his willingness to mix the rigor of technique with the need for an open attitude. What Buxton has done is link design innovation and design tools with the organization’s need for accessible product and process innovation. For me, the most charming element of the book is not its rigor of thought or clarity of expression but Buxton’s authentic respect for researchers and designers in academe and industry who bring user-oriented discipline to design. He takes attribution, acknowledgment, and history very seriously.
Any organization that is looking to design or designers as the key to differentiating the value of an innovation will treat this book as either a bible or a useful provocation. This book may be better for a business unit leader than for the CEO, but any company that has a vital innovation culture would surely benefit from having its chief marketing officer and intrapreneurs referencing Buxton’s text.
Although Buxton’s lavishly illustrated Sketching User Experiences reads like an idiosyncratic memoir-cum-design-handbook, it will enjoy a happily dog-eared existence on the desktops and nightstands of people sincerely looking for more innovative ways to be innovative. Because it goes beyond narrative and vignette to provide a well-designed and — yes — innovative innovation tool kit for business, it has earned its spot as the best innovation book of this year.
Of course, each book succeeds on its own terms while offering its own proprietary slice of innovation analysis. Each superbly captures the perennial role of failure in the dogged pursuit of success. All the books highlight the importance of luck, both good and bad, in shaping innovation decisions and outcomes. But, for me, the starkest theme is this: Far more than confidence and expertise, humility is the essential ingredient for innovation success.
It’s not unreasonable to ask whether this review’s emphasis on humility truly reflects the centrality of themes presented in these four books or instead is some psychological or rhetorical dysfunction of the reviewer. The politically correct answer would be “both.” The reality is, if you read only one or two of these books, the humility issue is intriguing but not essential. If you happen to read all four — and have a good command of the innovation literature and personal experience — avoiding the humility challenge is intellectually dishonest.
Schumpeter was surely not wrong to point to intellect and will as essential to entrepreneurial innovation. But he was a good enough student of capitalism, socialism, and democracy to know that humbling the ambitious makes markets. No one will come away from reading these books believing that confidence is more important than humility in innovation success. However, everyone will come away recognizing that quality of character matters even more than the quality of the idea.
Michael Schrage (email@example.com), formerly codirector of the MIT Media Lab’s e-Markets Initiative, is currently a senior advisor to the MIT Security Studies Program. He writes frequently on innovation topics for strategy+business and is the author of Serious Play (Harvard Business School Press, 1999).