For all the talk about how good communication is key for a team's success, I have a counter idea: Avoid having to communicate in the first place. Communication is not the ideal to a team's success; less team members to communicate with is.
The closer a team size moves to one, the more efficient its productivity.
Jeff Bezos likes to refer to the ideal team size as "two-pizza teams:" any team that is small enough that they can be fed by a couple of pizza pies, is a model of efficiency and accomplishment. Anything larger is not.
The medium is the mess
Communication is actually bad. It inherently involves a loss of information. The more communication that is needed, the less of the product plan will be efficiently implemented according to the original vision.
Consider the impossibility of trying to tell a friend about a wierd dream you had the previous night. Can you convey every single detail of the dream before it fades? Of course not. You have constraints (like time and memory), so you cut out anything which is "insignificant."
The same holds true for any project plan. The larger the amount of people to convey information to, the less efficient you can be at it. Explaining to one person every detail of the plan is tedious enough. Imagine having to do the same for multiple people. Daisy chaining the information so that it is passed on from executives to managers to smaller groups has its own problems: Information loss and corruption at multiple points. It's the age-old game of "operator," only with results that are not nearly so funny.
When there is one person both running and operating the entire show, you have 0% communication efficiency loss. The vision is designed and implemented exactly as it was originally conceived. Add a second teammate and you automatically introduce inefficiency into the equation. With each new person added to a team, the potential for communication efficiency loss gets worse as each person creates failure points with every other person. Once you start getting beyond 8 team members, the efficiency loss becomes so great that it can only be made up by throwing additional resources at the problem. In other words, you are not going to see double the output from a team of 15 people as you will with a team of 8 (even though you'd expect it on paper). In fact, you'd be lucky to see even a 25% increase in output, even though your team size has doubled.
Keeping your team small
So what's the overarching lesson? You don't need a huge team to successfully launch a start up. In fact, your chances of succeeding are better, the smaller your team size. You cut out as many communication points of failure as possible and keep your startup costs down.
So how do you keep your team small?
* Choose a project that is simple to implement. Don't try to create a complex suite of applications. (Yeah, I'm a hypocrite). Focus on solving a single problem. Philip Kaplan made email more efficient to use by stalling it instead of managing it. Dead simple approach and a great idea.Take the easier approach when possible.
* Choose people that can wear multiple hats. Can your designer code? Can your programmer manage a community? Can your marketing guru fund raise? Can one guy do it all?
* Document everything. It's obvious that you will need a business plan. What's not so obvious is that you should also document the seemingly mundane; methods used for team communication, methods used for integrating with potential partners, methods used for keeping a company blog up-to-date and interesting. All documentation should be available via a central location. A wiki can work really well for this purpose. Good documentation lessens the loss from communication failures.
* Arrange your workspace in common areas. Segregating your team in different offices is a recipe for lost communication data and with it, a need for additional people. You'd be surprised at how many roles can be shared by multiple people, so long as they have the ability to communicate instantly and unimpeded with each other. Put people between walls, and those shared tasks will need to be managed by additional team members.
The following are examples of two-pizza teams that generated some of the most popular community content sites online:
Know any others?]]