In preparing to read and review O’Reilly’s The Myths of Innovation, I had the chance to interview its author, Scott Berkun. Scott worked on Internet Explorer for Microsoft back in the mid-1990s, is the author of The Art of Project Management, and currently teaches “creative thinking” at the University of Washington. In this interview, Scott Berkun answers some questions about innovation at Microsoft and in the open source software world.
You used to work for Microsoft. Could you provide some examples of good and bad methods of innovation that you experienced there?
Scott Berkun: The best method by far is avoiding the i-word (innovation) altogether. Focus on solving a problem. If it’s a good, important, hard problem to solve, you’ll be plenty innovative without ever having to say the word. You’ll be so focused on solving a problem that you’ll invent and create as a secondary need to solve the problem, and that’s the best, most common method of innovation I’ve found in history. Da Vinci, Edison, and Tim Berners-Lee didn’t use the i-word much, and neither should anyone else. In fact, innovation is over-rated anyway; be good, be useful, be reliable, and you’ll beat the pants off your competitors. Doing those 3 things alone is beyond 90% of what’s out there now.
The most successful innovative teams I worked on at MSFT were the early days on Internet Explorer, around 1995-1998. We just picked very clear, but hard problems, and had managers that supported individuals taking initiative in trying to solve them. Internet Explorer has a muddied reputation today given its abandonment from 2000 to 2005, but back in the 90’s we were paving new ground in every single release in a back and forth war with Netscape. The secrets were clear goals, smart people, and high trust in each other.
The worst thing in the world is to throw the innovation word down — innovation teams, innovation task forces, etc. That tends to put people in ivory towers instead of helping them run low to the ground, where customers and real important problems are. Successful innovation depends on understanding people and their problems more than it does the ability to create technological wonderments.
In your book, you mention that Internet Explorer is the dominant Web browser design, though it is aging and other browsers like Firefox and Opera are taking more risks and being more innovative. Since Opera doesn’t make any money from desktop PC Web browsers, and Firefox is owned and controlled by a not-for-profit foundation, what do you suppose the motivation is for innovation in these projects? Are people naturally impelled to innovate regardless of financial reward?
SB: Creators have always had personal motivations – very few creative minds throughout history got paid well for pursuing their ideas (talk to Van Gogh, Mellvile, Wittman, Guttenberg, etc.), so it’s not surprising that many programmers are willing to volunteer their time. I think creatives live to see their ideas used by others, and open source development excels at providing those kinds of opportunities.
About Firefox: While I’m a very happy Firefox user, its core design — certainly at the user experience level — isn’t far from the early Mosaic/Netscape/Internet Explorer designs. It wont make the innovation history books as the beginning of a new generation of browser design. It’s certainly a better browser, but there’s not enough fundamental change to call it an innovative browser. Opera is way more deserving of that title, although Opera has so much creativity going on its design, that from a user experience perspective it could do with less innovation.
It is generally believed in the open source community that the “benevolent dictator” approach of software project leaders like Linus Torvalds is the most successful method of attracting innovative changes from a large body of contributors. Is this true, in your experience, or would it be better to take a more democratic approach?
SB: First, the honest, but cop-out answer: There is no single answer to this — it depends heavily on both the culture of people involved and the goals that they have. Anyone passionately advocating an approach without studying the terrain is a fool.
More troublesome is the popular confusion of democracy with equality, a comparison which has always been false. Sure, everyone gets one vote, but in all democracies some votes are way more influential than others (true for Greeks, Romans, Americans, etc.). It’s natural for any large group of people to have a small group of leaders at its core — people who are more committed and invested than others, and whose opinions carry more weight. If you want rapid change, you do want more centralized authority, as the number of approvals needed for change is smaller and the pace is faster. But if you want sustainability, you need checks and balances. Finding the balance is the central challenge of management and it’s an intuitive, experience-based skillset. Wise leaders in open source projects, or any “people herding” type activity, can learn much from studying political science and sociology, as the pattern language of success here has little to do with technology — it’s group dynamics of human beings.
You might shoot me for this, but I’m skeptical that open source draws more innovative changes from contributors than other systems of software development draw from theirs. Open source certainly attracts contributors, and increases the pool of people involved, but most contributions are so isolated in scale, and in impact on users, that it’s hard to consider them “innovations.” Perhaps open source as a model can be called an innovation, but most of the development work, bug fixes, and feature additions involved are relatively ordinary development work, just like on any other software project. Most open source projects have locked trees, which means if a big innovative change is going to make it in, it’s the choice of the gatekeepers, not the democratic masses: which is the same story in a non-open source environment. Apple is perhaps the icon of innovative engineering in 2007, but their model is about as far from open-source as possible. The gatekeepers in both cases drive how much innovation goes out the door, so I always look to the gates. Whoever is standing there is the real story of innovation.
Do you think that being able to see and modify a program’s source code is a good method of innovation?
SB: Sure. Understanding how things work is the fastest way to learn and gives people who come later reusable, proven methods for doing things. But at the same time, it provides sets of assumptions that are more efficient to follow than to reconsider or reinvent. So depending on what level of innovation we’re talking about (a feature? a product? a line of products? a paradigm?) access to source code has different levels of value. And there’s also the value of mystery — sometimes a locked box forces people to be more creative since they have to invent their own approach. Being angry at that locked box and wanting to figure it out can drive people to innovate who’d be bored if they had permission to take it apart and see the source (as the legions of hackers and reverse-engineers out there can attest).
What’s the question I didn’t ask? What would you say to software developers that you didn’t say in your book?
SB: Software engineers are super bright, but suffer from their education – we’re taught (I’m a CMU computer science grad) a myopic view of not only our world, but even the history of our field. I wrote The Myths of Innovation as a concise, funny, crash course in the history of how we got here, applying relevant history to explain the patterns of innovation we see today. That kind of foundation is essential to improving the odds of progress, and its absence is the greatest liability of would-be inventors, creators and programmers everywhere. Whether people get that piece of innovation knowledge from me or someone else, it’s critical to their goals to get it. I’d love for programmers to kick ass and live up to their dreams of changing the world, but they need tactics derived from innovation history to make it happen.
Discuss this article or get technical support on our forum.
Copyright 2007 JEM Electronic Media, Inc. No reprints without written permission.