March 15, 2007

...Learn TDD with Codemanship

Flawed Innovation Advice

This morning a pamphlet dropped into my in-tray designed, apparently, to encourage software developers to innovate. It contains the following advice on how to innovate:

* Always keep your goal in sight
* Ensure you have the appropriate maps and guides
* Work together
* Explore - but don't get lost
* Take one small step at a time, and don't miss any important steps out
* Don't wander off without permission
* Learn from where people have been before
* Take appropriate risks when required
* Communicate new paths which lead to dead-ends to your colleagues so we can learn from our failures
* Remove any blockages from the path so other people can follow the same route
* Keep in touch with base camp, so we can co-ordinate our expeditions

Now, I don't know about you, but I genuinely believe that there is some very bad advice among all that. I don't believe we innovate - not really innovate - by sticking to the path, following the map and following other people. Much research suggests that the most valuable innovations happen by accident. If Alexander Fleming had "always kept his goal in sight" I suspect he would have thrown away the culture of penicillin he had accidentally grown whilst trying to solve another problem, for example.

I've argued strongly before that the better, faster, cheaper school of innovation can lead to a reduction in a company's adaptive capacity, and in markets where there is unpredictable, discontinuous change your ability to change direction quickly (I think we have a word for that that begins with an 'a') can be a critical property of your business.

The type of innovation they're talking about here is exploitative innovation, which is how the process of evolution usually works. There's nothing at all wrong in that, provided you don't become so lean and mean that when the weather suddenly turns, you're not so well-adapted to your present circumstances that you freeze or starve to death. Sometimes we need to make intuitive leaps in order to survive sudden changes in our environment, and the incremental, plodding and risk-averse pace of exploitative innovation is little help in those situations.

My advice, if they'd have asked for it before they printed their pamphlet, would have been to balance the evolutionary approach with a decent amount of exploration. Google allow every developer to devote 20% of his or her time to their own projects - giving them permission to "go and play" for one day a week. Google employees seem largely unfettered by the kind of chains that most managers would seek to wrap them in, and their burgeoning product portfolio - rampant with cool new ideas - is a testament to the success of that approach.
Posted 14 years, 4 months ago on March 15, 2007