27 June 2006

Small (relatively speaking)

This has got to be my all time favorite comment from the press:

"The autonomy of this relatively small division allows Microsoft programmers to cut loose and design the best software they can imagine… Microsoft's Mac offerings are routinely credited as being more innovative, elegant and robust than its mainline PC products" – Terril Yue Jones, Los Angeles Times, September 2005

There's a lot of energy out there in defense of the small, the startup, the two or three in a garage, and I don't want to take anything away from that, I am a romantic at heart. There are wonderful times to be had by all and room for everyone, but to perhaps add some balance to the discussion, there are some very good reasons for "big". Consider Six Apart the makers of some very successful blogging software. Two founders with a company that has been on the blogging wave from the beginning, the perfect poster child for small and agile. And yet Mena Trott president and a co-founder of Six Apart, writes a post entitled: In Defense of Big (relatively speaking) She writes:

An underlying theme over at Signal vs. Noise is the concept that smaller is better -- smaller in terms of start-up capital, company size, development teams and even hardware. As part of a two-person team that created the initial versions of Movable Type and TypePad, I certainly understand the logic in encouraging small and nimble teams. The eighteen months that Ben and I spent in our spare bedroom coding was probably our most productive for bare-bones software development. Of course, during this same time, we were afforded the luxury of not having to do anything much more than coding and designing -- our project management was done via (what felt like) telepathy.

A long time ago (well, maybe not that long ago -- it just feels like it), Ben and I were at a fork in the road where we had to decide whether we wanted a small, niche company that would serve as a nice lifestyle business or try to be something bigger and take a gamble that Six Apart could make a serious impact on blogging. (A "lifestyle business" is one of those terms that money/funding people use to describe someone who can make a nice lifestyle for themselves with their company, but doesn't really make jobs or opportunities for a lot of other people.)

So here we are -- a big, small company or a small, big company. I've been on both sides of the table and have to say that it's pretty nice where we are. And since the "small is better" argument is very often offered in both elegant (Signal vs. Noise) and ignorant (Generic "Being Corporate Sux!!") ways, I thought I might contribute my reasons to why bigger can be better.

She then lists her reasons:

1. More people, different view points.

2. Accountability.

3a. Creating jobs for many people.

3b. It's nice not to always have to bootstrap.

4. The ability to shift roles.

5. Sticking to what we're good at.

6. It isn't just an American thing.

7. Creating products that really make an impact.

I'm a bit biased in talking about this whole thing, but I can say that the small startup resonates with me, like with others. That said, there are great things you can do for others as more people use your product and with the scale comes the blessings and challenges of software in the large. Check out her full post. It's a great read.

1 comment:

Anonymous said...

Not having been of significant age in the 70's or 80's I've grown up with the idea of software companies, for the most part, being fairly large organizations. It seems as though the industry as a whole is following the same track as most other technical fields. Where once you had two brothers building the first airplane in the garage you now have multinationals pumping out jumbo jets. While it may appear self evident, the smaller form clearly led to the larger, but was unsuited to remain competitive. The amount of prior knowledge, skill, regulation, and level of product quality required makes most competitive development only feasible for large companies in a rapidly evolving industry; be they development houses or plane manufacturers. As such, competition in the established software domains is limited by the sheer weight large companies hold.

That said, innovative development in new domains and problem areas may be much more likely to come from small houses in much the same way that the occasional revolutionary discovery is made by the garage tinker. There simply is not so much existing practice to accommodate and this allows a smaller number of people to be amazingly successful. Additionally, the 'requirements' placed upon innovative products are not the same as the standards products in established domains are held to. Compare early web browsers to their far evolved brothers as an illustration. To argue whether one form is superior to the other ignores the possibility that they may both be useful forms depending on what you're trying to accomplish.

Much of this is essentially what Mena gets at in her bullet points albeit from a different direction.