Finding the ideal team structure for Startups

A lot of what is written about managing teams is a discussion of the two basic classes of teams, centralized and decentralized teams. Both have their pros and cons and are best suited to different situations.

Centralized teams also give rise to a top-down structure of an organization. Top down teams can get a lot of work done as all members work in tandem. Independent and creative thinking can jeopardize the entire organization. The scope of work is divided into two classes, thinkers and doers. Thinkers do medium/long range planning, anticipate issues, allocate resources, manage motivation and doers execute the activities that the thinkers have identified on a transaction basis. Centralized teams are usually stable and provide security to all its members. Large companies and governments usually fall into this category.

De-centralized teams on the other hand are much more fluid and depend on creative and independent thinking members. These teams are usually upstarts and their objective is to find a niche that has not been exploited by others. Every member is a thinker and doer. The tasks are not stable and the position of each member is not secure if they are not willing to change their roles or learn new skills.

Truly decentralized teams are a much more rear phenomenon in business than centralized teams. Hence most people would have never experienced working in decentralized teams or even heard of anyone who worked in one. This also includes founders of start-up companies

A one to three person start-up does not face this problem, but when a start-up takes more risk than usual, the centralization / decentralization problem comes up. This is because most people have no experience / understanding of de-centralized way of working. As Steve Blank rightly points out, a start-up is a "search" for a scalable business model and hence what it requires is a de-centralized team. This is exactly what Jason Fried and company write about in "Rework"

Or the other option is to become ambidextrous. Be centralized and de-centralized at the same time. Let the need drive the structure. Say if you need to do extensive testing before a new feature release, make a centralized team and split planning and doing. If you need to build 10 new features in a month, keep it de-centralized. The catch here is that all the team members also have to be ambidextrous.