Archive for June, 2007

  • By Scott Berkun on June 28th, 2007
  • No Comments »
  • Myths of Innovation

Interview with Guy Kawasaki

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.

Ten questions with Scott Berkun, by Guy Kawasaki.

Interview on The Well: your questions wanted

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

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

bomb.jpgOne 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.
Bouncing bomb, from wikipedia

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

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?

  1. 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.
  2. 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

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.

Scott's Bestselling Books
  • Confessions of a
    Public Speaker
  • Provocative and funny secrets from a veteran speaker, you'll laugh as you learn.
  • Buy now at Amazon Book Details
  • The Myths of Innovation
  • The classic bestseller on how amazing lessons from the past can help you innovate today.
  • Buy now at Amazon Book Details
  • Making Things Happen
  • The classic and bestselling handbook for any project leader, packed with tactics and stories.
  • Buy now at Amazon Book Details
Photos from Recent Events (view flickr stream)

You're reading Scott Berkun, All rights reserved unless noted. You can subscribe here Blog RSS Comments (RSS)