Before I got involved with product development a few years ago, my entire career was spent owning and running a small (10-20) person web app consulting firm. Clients (ranging from mom-and-pop operations to Fortune 100 megacorps) would come to me with a problem and I would assemble a team to solve that problem with some sort of web application. 99% of the time, the size of that team was somewhere between 1 and 4 consultants.

When I started a little Web 2.0 company, it seemed natural to keep the team to 2 people, with me doing some design, PR, marketing, and biz related stuff, and Brian doing the assorted geekery required to make a web app go (server and client side coding and a bit o’ sysadmin work).

When our little company got bought by Jobster and we relocated to Seattle, one of the things that truly blew me away was the SIZE of the product development operation at what most Jobsterites felt was a lean operation. There were literally dozens of developers, a few designers, a mess of program managers, and a small army of offshore QA folks. I don’t have the exact count, but I think that somewhere in the neighborhood of 35 people could honestly say, “My job is to build software” at Jobster.

So why the discrepancy? The little teams that I had worked on for most of my life weren’t solving tiny problems. Sure, we had an occasional brochure-ware client, but a big slice of our time was build applications that were pretty darn complex and sophisticated. There are two very legitimate reasons that software teams get big:

• First off, some web software is just big/complex/ugly… and it has to be. Enterprise software tends to be bigger, more complex, and have lots of integration points which get pretty complicated. The “two guys in a garage” theory doesn’t really work for such things. The more I play in the world of web development, the more adamant I am about not wanted to play in the world of “big” software. Big projects might have merit, but they are certainly a helluva lot less fun.
• Some teams are really a bunch of smaller teams working on different things. Jobster was (and is!) definitely engaged in several different initiatives. So the team of 35 people were really (depending on how you slice it) working on two or three very different problems.

Unfortunately, the list of reasons for team bloat goes on and it gets pretty ugly (note: some of these are paraphrased from Parkinson’s Law)

• People make work for each other. Certain people are REALLY good at creating LOTS of work for other people. Some of this work is valuable and productive, but much of it (excess documentation, “here’s what I’m up to” meetings, etc) is not.
• The amount of work on a team ebbs and flows. Sometimes there’s a ton of work, and an undisciplined (or over-funded) team will seek to get bigger rather than just suffering through the peaks.
• People like subordinates. Oftentimes, a manager is measured by the size of their team. Bigger teams mean bigger budgets and more responsibility, and that looks good on a resume.
• Work, like water, spreads out and seeks to fill the nooks and crannies of an organization. If a 10 hour task for one person spreads around to involve 4 other people, it’s likely that the manpower spent on the task will explode to something well beyond 10 hours.
• An individual’s tasks will expand to fill the time alloted to accomplish them. This seems like the other side of the “necessity is the motherhood of invention” truism. In the times where people have more time than they need to accomplish a task, they’ll find a way to stretch it out. This includes surfing the web or (much more dangerous) adding complexity/oversight to the processes involved in completing the task (creating a longer term “bloat”).
• Communication paths grow exponentially with the size of the organization. With two people, there is exactly two possible communication directions. With a team of 10 people I have 9 other people that I have to communicate with (and who have to communicate with me). This dramatically increases the chance of miscommunication, confusion, excessive questions/clarifications, and (everyone’s favorite) office politics.
• Low quality team members can hide in the herd. If a team member loses their motivation in a two person team, it becomes pretty evident pretty quickly. On large teams, low-productivity members can lurk for months without any problems.

Of course, there is some value in larger teams. And, in my opinion, there is simply HUGE value in growing your team from 1 to 2. Two brains are most certainly more than twice as sharp as one. Beyond a team of two or three, however, I think that the added manpower offers asymptotically diminishing returns. While I truly believe in the Wisdom of Crowds, I think the best way to harness this wisdom in software development is by collecting thoughts and opinions in a one-off kind of way (usability tests, focus groups, consultants and the cheaper alternatives of asking peers, friends and family for their opinions).