If you want to innovate more effectively, you need to iterate faster. Robert Scoble cites Oracle’s Larry Ellison as having a recipe for increasing efficiency in an unproductive team (by successively reducing headcount) and offers this as a way to keep a team small enough to iterate rapidly.
Eric Ries is getting serious attention for his idea that innovation requires the feedback cycle to be almost unimaginably short. ‘Issue it, get feedback, update it, reissue it’ needs to happen at breakneck speed, not just to be on schedule, or to be first, or even to keep users happy, but simply because doing things this way produces results which massively outperform any other approach, at a significantly lower cost and a much lower risk of failure.
It also turns out that Fred Brooks ’s Mythical Man Month’s ‘deterioration of software development productivity as headcount increases’ looks like it applies directly to the ‘capacity to iterate fast enough’ in terms of mandating a minimal team size. Ok, so there’s the theory, here come the questions.
Does this need some serious research to be done in order to confirm it, or does it all sound too sensible to be wrong? Is it so easy, low cost and low risk to try, that ‘just do it’ is all you need to think about? Does this approach apply exclusively to software development, or even just to online services? A university computer science department should attempt some experimentation to answer some of these questions.
Discoveries about appropriate team sizes for optimising iteration could have broad implications for almost any field of innovation. To me, the research sounds as if it could also be turned into the basis of a game. The first ‘resource reduction game’ that comes to my mind is musical chairs. Any ideas?
