Small steps versus theorizing, Reboot7
Lot of interesting posts and presentations coming from last week’s Reboot7 conference in Copenhagen. The attendees are predominantly involved with new internet applications such as blogging, tagging, peer-to-peer, voice over IP, social software, and collaborative development, all of which are new, fluid, evolving, and somewhat incompatible with existing business and social models. Progress in new and evolving fields can sometimes get bogged down in “Vision” or “Strategy”, so I’m happy to see this observation about the need and value of small steps from Johnnie Moore:
A theme that seemed to run through Reboot7 was the advocacy of taking small steps over theorising. David Heinemeier Hansson, who built web application Ruby on Rails, stressed the advantage of getting something basic up and running fast. In a presentation on The Skype Brand, Malthe Sigurdsson talked about getting out frequent, small revisions.
Along similar lines, Scoble writes:
I’m stuck with some images coming out of the Reboot conference last week: the power of being small.
Lots of people were talking about the shipping power of small teams. Mostly due to Jason Fried’s talk.
He’s turning out to be one influential developer. Why? Cause he, and two other coworkers, are churning out new features at a torrid pace. Here’s an example of his thinking about development teams: don’t write a functional spec. Whoa. I love his idea for what to do instead: write a one-page story.
In a emerging, largely undefined area, taking small, concrete steps (albeit sometimes at a rapid pace) in a general direction can often uncover more “ground truth” more quickly, with less resource, than a fully investigated, heavily staffed program. Unfortunately, it’s often easier to explain a more comprehensive program, even though the size and overhead of the activity may place a fundamental handicap on it, making it less likely to succeed. There’s also a tendency to want to systematize everything at the outset, to try for the “grand unified theory of everything”, which can become crippling (the early days of XML and CORBA comes to mind). In a new or emerging market, the “Great” can easily become the enemy of the “Good”, or “Useful”. Bear in mind, if it really is new, there’s a good chance it’s not going to be right on the first few tries, so best spend your resources wisely rather than making a wild bet that you’ve found the One True Answer.
Within various corporate R&D and business planning settings, I’ve repeatedly seen that small, motivated teams (1-10 people) can often make substantial headway in new business areas by finding equally motivated customers and solving their needs quickly, frequently without official support (or oversight) from their management. These efforts are often crippled when they do gain “official” status, thus adding the need to be externally explainable in the team’s decision making process, and sometimes also gaining a requirement for a roadmap for world domination. If they survive this stage, most of these small, fast teams are crushed by the subsequent addition of dozens or hundreds of new people and the associated management overhead, organizational empire building, and huge burn rate, all added in an effort to staff up and implement the premature plan for world domination. The team is no longer fast and burns through huge resources committed to an inflexible and obsolete plan in an emerging market space. Oops.
See also: Seth Godin’s Small is the New Big
Caveat: Established markets really do need scale and structure. Sometimes Big is the New Big, too.
Update 2005-06-16 10:16: Great Enough! (more from Seth Godin)
If you don’t ship, it’s not really worth doing. More important, we’ve only got a finite amount of time and resources to invest in anything (thanks, Chris Morris). The real issue is this: when do we stop working on something (because it’s good enough) and work on some other element of the offering.