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.
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.
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.
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.
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?
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:
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.
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 200+ more in the comments and there is additional commentary here.