The Berkun Blog
Management, design, and the making of good things.
Interview with Guy Kawasaki
June 28th, 2007
This is a twist - as much as you’d think I should be interviewing him, Guy is a fan of the Myths of Innovation and interviewed me for his site.
Interview on The Well: your questions wanted
June 27th, 2007
This week I’m being interviewed on The Well by Scott Underwood of IDEO and other Well members about The myths of innovation.
You can read the conversation as it develops here and also submit your own questions and comments by e-mailing inkwell at well.com - just mention my last name in the subject line.
More on asshole driven development
June 26th, 2007
Hey folks - apologies if you’ve had problems accessing the site. The last blog post on asshole driven development was a hit. I’ve had more traffic on that then anything I’ve written in history.
If you want more commentary and painfully funny methodologies there are additional comment threads on the three major drivers of traffic: Digg & O’Reilly Radar, And Reddit.
Tiff Fehr has put together an analysis of the different methods and comments to date. Worth a look.
There are still about 120 comments in the queue (out of almost 400 total) - if yours doesn’t get posted, please don’t call me an asshole :) Many of them were redundant, bizarre or beyond my level of comprehension. They’ll all get read, but at 100+ comments I’ve got to filter some stuff out.
Not sure which of you got the run going, but thanks to all who passed my writing around.
Innovation history: the bouncing bomb
June 19th, 2007
One highlight of my research in innovation history is the story of Barnes Wallis and the bouncing bomb of WWII.
In short: The Allies needed a way to destroy Nazi dams and no ordinance of the time was sufficient for the purpose. Barnes developed a way to drop a bomb, on water, several hundred yards from the dam, and have the bomb, weighing several tons, bounce (that’s right) it’s way on the surface until it reached the dam wall.
It’s an amazing story of technology, inspiration, frustration, politics, persistence and eventual success.

I watched it first on the PBS Special Secrets of the Dead, but you can watch parts of the Dangerous Missions series about the bomb on Google Video here. There’s also a feature film from 1954, and rumors of an upcoming Peter Jackson produced remake.
How to write a rude Q&A
June 19th, 2007
One handy technique I learned at Microsoft was the Rude Q&A. A Rude Q&A is a list of questions you don’t want to hear about whatever it is you’re working on. What would the meanest, nastiest, but smartest people in the world grill you on when you show your work? That’s what goes in a Rude Q&A document.
Why do this?
- Preparation. If you do hear a tough question you want to be ready. A RQA runs you through the unpleasant things you might hear, and increases the odds you’ll handle that situation well. A good RQA raises confidence in tough meetings or presentations.
- Revision. If you have lots of good RQA questions, but don’t have good answers, it’s a red flag that your plan / design / pitch needs more work.
How to create a RQA
Find your nastiest inner cynic. Some people are naturals at this task and enjoy coming up with the rudest, most confrontational questions the world has ever seen. If this isn’t you, find your co-workers or friends who are and ask them to hold nothing back: go for the toughest, most confrontational, cut to the core questions. You might be offended or hurt by what they come up with, but that’s ok - better to be offended/surprised in an RQA than in a demo, pitch meeting or public setting.
If you have trouble starting, do this: imagine the devil incarnate, working in partnership with your biggest competitor or rival, doing a mind-meld with Bill O’Reilly, asking you questions on live TV. What do you imagine getting asked?
Make sure to include questions that are unfair or based on erroneous information. Reporters, clients, and the public all have their share of unfair questions and erroneous information, and you want to be ready for them.
The answers take more time as the responses need to be more polite and mature than the questions. They also need to carefully refute assumptions in the questions without being dismissive.
Examples
Here are some from my own rude q&A about my new book:
- You were at Microsoft for years - Microsoft! - what makes you think you know anything about Innovation?. Since college I’ve been a student of innovation and invention history, and my experiences working on early versions of Internet Explorer (1-5), during the birth of the web as a mainstream phenomenon (1994-1998), gave me perspective on how new ideas, products and innovations actually happen. I worked with many of the first search engine and web companies and played a role in defining what web browsers would become.
- There are dozens of books on innovation. Why should anyone care about yours?. The Myths of Innovation focuses on great stories - it uses stories to explore what we believe, separate truth from myth, and offer advice based on what innovators actually do. This approach is unusual as it’s very approachable, free of jargon and hype, and makes for an easy read that focuses on the questions that history supports as most essential.
- Your first book was about managing teams and projects - but your new book talks about the uncertainties of managing innovation. Aren’t you contradicting yourself? The philosophy of both books dovetail. The same challenges occur on all projects, but if innovation is the goal the risks are higher and the uncertainly is greater. While the Art of Project Management does have chapters on managing change and designing new things, it’s a handbook so those are parts of the book, not the focus. The second book however is exclusively about ideas and how to bring them to the world.
- Creative thinking is rare and inborn. What makes you think you’re qualified to teach people to be more creative?. I believe anyone can get better at anything. They might not become rock stars or Mozarts but if they study and work hard they’ll get better. The book offers solid grounding in creative thinking, true brainstorming and the psychology of creativity, using well supported claims about how creativity happens. A huge part of being more creative is separating myths from the truth and that is, as the title explains, the focus of the book.
Some of this is spin, for sure, but these are in essence good questions - and if I want to do well in interviews or talks, I have to be ready for them. Responding to Rude questions is largely about finding the core, valid nugget hidden inside, and responding to that, instead of the distracting rude bits.
As a matter of practice, preparing for any launch, demo, or presentation should include making a Rude Q&A.
Asshole driven development
June 19th, 2007
The software industry might be the world’s greatest breeding ground for new systems of management. From Agile, to Extreme Programming , to Test Driven Development (TDD), the acronyms and frameworks keep piling up. Why?
Some say it’s immaturity: that software is still a young industry and all the change is the path to some true fundamentals. Others say it’s because software people like making things up and can’t help themselves. Well I say this: if we’re going to have dozens of models we may as well have some that are honest, however cynical, to what’s really going on much of the time.
(There is a happy list of these I’m sure, but this is the cynical one).
Asshole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.
Cognitive Dissonance development (CDD) - In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself.
Cover Your Ass Engineering (CYAE) - The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame.
Development By Denial (DBD) - Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor. The worse things get, the more people depend on their denial of what’s really happening, or their isolation in their own small part of the project, to survive.
Get Me Promoted Methodology (GMPM) - People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go. This includes allowing disasters to happen so people can be heroes, writing hacks that look great in the short term but crumble after the individual has moved on, and focusing more on the surface of work than its value.
I’m sure you’ve seen other unspoken methods at work - what are they?
(Update: There are about 60 more in the comments) and there is additional commentary here.
Management by fire: Bourdain on leadership
June 14th, 2007
A great interview with Anthony Bourdain about managing and leadership. I mention Bourdain’s book, Kitchen confidential in The art of project management. But this interview goes all out on the similarities between how pro kitchens work and how teams work.
“Every kitchen has one evil genius who’s tolerated—someone you turn to when all else fails—a rule breaker, a scamp who’s willing to make a hard and sometimes unlovely decision for expediency. There’s actually a name for this person—the débrouillard, the person who gets you out of a jam.”
Management by Fire: A Conversation with Chef Anthony Bourdain
Social software applied: Pathable
June 13th, 2007
I experienced an innovation doubleheader last week. First, the inaugural Bizjam event in Seattle, where several hundred independents got together to learn and network, jam and mingle. First conference I’d ever seen aimed at this crowd and it went really well - Kudos to Dan, Lara and all the biznik folks.

But one particular bit of cleverness was their hiring of WaggleLabs to create custom conference badges using their Pathable system.
Now mind you, I hate conference badges. They make me feel like a 12 year old in a self-help group, and they’re often so big, ugly and annoying to wear that I often hide them in my pocket - Really, I can introduce myself and meet people without them. But this was new, fun, easy and it worked. Here’s the rundown:
- Fill out a short form. Could do this online before or at the event. Took about 3 minutes.
- Pick up the badge. This took another minute or so.
- Talk to people about their badges. Each badge lists tags, and two groupings: people you have high affinity (Most similar), and low affinity with (Most opposite), based on your answers.
The effect was obvious: it gave everyone something easy to talk about, even if just to compare colors, or to ask people if they knew any of the people on your list.
They had a projector up in one hall listing all of the groupings the colors represented, and I had several conversations with people about that alone.
Myths of Innovation: $14.99 on amazon
June 12th, 2007
It’s still a mystery how amazon.com sets its pricing, but the Myths of Innovation is at an all time low at $14.99 (Lists at $25) - this is 40% off the cover price.
No idea how long it will last - they don’t tell the authors these things.
Interview & review at DigitalWeb
June 12th, 2007
Digital Web magazine has both a great review of The Myths of Innovation and a short, funny interview with yours truly about innovation, writing and more.
How to innovate on time
June 12th, 2007
I’ve taught the tutorial How to innovate on time a few times now, and the big takeaway for most is the need to carve out time for failure. That’s right, failure.
Plenty of notable innovation quotes talk about the need to fail, for example:
If you want to succeed, double your failure rate. - Thomas J. Watson
Failure is the gateway to innovation - Ashley Ball
Whoever makes the most mistakes wins - Ralph Keyes
But few know how to convert that into action. How do you guide failure towards innovation?
The answer is 3 things:
- Make interesting failures. An interesting failure is when you learn something through failure you could not have learned any other way. Scientific experiments are attempts to fail in interesting ways: the thing doesn’t work, but why it doesn’t work reveals a new set of interesting questions. This is different from a mistake: a useless, avoidable failure than isn’t interesting and doesn’t teach you anything you didn’t already know.
- Budget time for experimentation. If you want new ideas, you have to give people time to find them. Google’s 20% time, an upgrade of 3M’s 10% rule, builds in experimentation at the individual level. But nothing prevents a manager from doing the same thing at the project level. Instead of the generic Design, Implement, Test style scheduling, shown here:

Divide time into quarters instead and reserve part of the schedule for experimentation, prototyping and interesting mistake making.
Even if you don’t budget 25% of the project time, you can still offer a week, a day, a half-day, for individuals to experiment and try things out without requiring anyone’s approval. Even small windows of time are better than none (Also see hack day, for putting experimentation at the corporate level). Once the design phase starts the risk taking declines, but all decisions now benefit from the interesting failures during experimentation.
- Pick specific areas for innovation. If you have a schedule commitment, you can’t risk big changes across a project. Instead leaders have to decide on specific areas where more risks (e.g. more innovation) is warranted, and ensure that the rest of the project will be managed conservatively. Just like how a smart general doesn’t fight wars on several fronts, a wise leader doesn’t innovate on several different areas at the same time, especially when under schedule pressure.
Slides from How to Innovate on Time tutorial (4MB PPT).
More reviews for Myths
June 6th, 2007
“This is a perfect book for managers all the way up the chain. It documents everything about the creative field that those in it know, and those who manage people in it have been conditioned to forget. If there is one book you pick up this year, pick this one up, read it, give it to your manager, and have him give it to his manager.”
- Bieber Labs
“While taking on the role of myth-buster; Scott provides insights into how innovations really happen and more important how they gain adoption. Like his first book The Art of Project Management (O’Reilly, 2005), Scott witty style makes the book easy and enjoyable to read. There’s much in the book that makes you rethink and question the common views of innovation.”
- Construx Software
“The Myths Of Innovation is an entertaining book that is easy to read and easy to understand. It makes you think before you assume. Although he debunks and destroys many myths, Berkun actually creates a set of insights that will help you come up with ideas…”
- BlogCritic.org




