Why Seven is the Magic Team Size

The throughput of any development team is the collective throughput of the people on that team. People are happiest and most productive when they’re on a team that’s the right size. Two person teams are clearly bad, as are 100 person teams. So what is the right size?

Software development is fairly unique among professions because close, trusting relationships are required to get anything done. Software development is an interconnected value chain, with each member of that chain contributing some work that is then consumed by another member of the team. Back-end developers build code fronted by APIs, which the front-end developers consume. Designers model user interfaces, which the front-end developers implement by consuming APIs. Both front-end and back-end developers must deploy code with the help of ops. It’s one big chain of interconnected dependencies.

In many other professions, you can get additional throughput from a team by adding more members to that team. If you have a hotel full of rooms that need to be cleaned, you’ll double your throughput if you double your team size from 10 to 20. Since each cleaner works in their own room, you can parallelize the work as much as you’d like. You could go from a team of 10 to a team of 100 and get a perfectly proportional 10x improvement in throughput. 

Software development doesn’t work that way. As Fred Brooks said in his famous 1975 book, The Mythical Man Month, “Adding human resources to a late software project makes it later.” If you have 10 developers working on a project and double the team size to 20, it just slows it down further. If you went from 10 to 100 developers, the project would crawl to a complete stop.

So what is the right size? Let’s look at a few considerations.

Problems with Small Teams

Small teams are terrible for individual productivity and happiness. Two, three and four person teams suffer from a diversity of skills. Developing software requires many different disciplines including architecture, design, front-end, back-end, ops, security, etc with each person bringing years of experience. Many people bring experience from other disciplines. For example, it’s not uncommon that a designer started his or her career as a front-end developer, or that an ops person also has experience as a back-end developer. Good teams draw on the experience of many different individuals to come up with full stack solutions to problems that are inherently very complex to solve. Two, three and four person teams just don’t have enough skills to draw from. 

Another issue with small teams is instability due to interpersonal conflicts. If you have two people on a team, it can be like a bad marriage if the two individuals aren’t getting along. If you have three, it can devolve into a two versus one situation where someone feels left out. If you have four, you can have a two versus two situation, or even worse, a three versus one situation. Disagreements become personal much more quickly than they otherwise would. A “no” to your great new idea feels a lot worse if it’s coming from one or two other people than it does as the consensus of a larger group.

Problems with Large Teams

Large teams, on the other hand, can be even worse than smaller teams. In creative professions like software development, important decisions must be continually made about what’s being worked on and how problems are solved. Are you going to re-factor now or in six months? Are you going to use React or Angular for your front-end? Are you going to work on supporting a new discount type or supporting purchase orders as a payment method? In large teams, there’s strong social pressure to be a team player and go along with the flow. People who speak up and say “Wait, why are we doing this?” are labeled as not being team players, or difficult to work with. In smaller teams, where each team member knows and trusts every other team member, it’s far easier for someone to break out of that group think. 

The problem of group think can extend beyond the boundaries of individual teams and extend to the rest of the organization. According to a Wall Street Journal profile of Amazon CEO Jeff Bezos:

At an offsite retreat where some managers suggested employees should start communicating more with each other, Bezos stood up and declared, “No, communication is terrible!” He wanted a decentralized, even disorganized company where independent ideas would prevail over groupthink.

Individuals within teams and teams themselves should feel completely empowered to question the status quo. Small, independent teams that can function autonomously are best for innovation.

Another issue with larger teams is the sheer number of communication pathways that members have within teams. Software development requires that members within a team trust each other. When trust is lacking, you see fighting between factions of groups, the need for more documentation, and more process in the form of change requests, forms, approvals, etc. The formal term for this is “Cover Your Ass Syndrome” and is defined as:

“the bureaucratic technique of averting future accusations of policy error or wrongdoing by deflecting responsibility in advance”. It often involves diffusing responsibility for one’s actions as a form of insurance against possible future negative repercussions. It can denote a type of institutional risk-averse mentality which works against accountability and responsibility,  often characterized by excessive paperwork and documentation, which can be harmful to the institution’s overall effectiveness. The activity, sometimes seen as instinctive, is generally unnecessary towards accomplishing the goals of the organization, but helpful to protect a particular individual’s career within it, and it can be seen as a type of institutional corruption working against individual initiative.

This lack of trust within and between large teams is why enterprise development is so painfully slow. It’s why those big multi-billion dollar IT projects in the private and especially the public sectors never succeed.

Trust — The Most Important Ingredient of Software Development

Building trust within and across teams requires communication, which is also known as “social grooming.” Primates physically groom each other (hence the “grooming” in “social grooming”) by picking bugs out of each other’s fur. Humans, on the other hand, eat meals together and socialize outside of work. Both of these activities serve identical purposes — to bond, reinforce group membership, and build trust. We all do it and it’s what allows business to get done. Working in a purely transactional workplace would be terrible. 

The problem is that you can’t maintain meaningful connections with more than a few people. As groups add more members, the number of connections increases exponentially according to the formula [N * (N-1)]/2, where N = group size. A two person group has only one communication pathway. Person A can interact directly with Person B. A three person group has three communication pathways. A four person group has six. A 10 person group 45. A 20 person group has 190.

Humans simply can’t maintain more than a handful of meaningful, trusting relationships at work. It’s a limitation of the human brain.

Finally, the last issue with larger teams is social loafing. There’s a famous term for this in sociology called the Ringelmann Effect, named for a French agricultural engineer who in 1913 discovered that individuals exerted less individual effort as the number of people pulling on a rope increased. This effect has been replicated by dozens of subsequent studies across dozens of different tasks ranging from rowing a boat to assembling large pieces of machinery.

As group sizes increase, members reduce their effort because they feel less responsible for the output of the group. A member of a five person group bears 20% of the outcome of the project, whereas a member of a 25 person team bears 4% of the outcome of the project. When the link between effort and outcome is severed, group members become demotivated and allow their colleagues to pick up the slack. People naturally want to own things. They want to be responsible. They want others to see their efforts and talents. They want people to tell their friends about the cool new feature they were responsible for bringing to market.

Given the clear drawbacks of both small and large teams, what’s the right size? At commercetools, we’ve found the best size to be seven, plus or minus two members. It’s not a hard rule, but it is a range that we aspire to and often adhere to. Seven is a fairly standard number across many disciplines. Basketball teams have members on the court. Volleyball and hockey teams have six. Baseball teams have nine. The smallest unit of most militaries around the world is a squad, which has between six-10 members. Amazon has a famous “two pizza team rule,” meaning no team can be larger than can be fed by two pizzas. Most of the agile and microservice gurus call for seven person teams.

Seven seems to be a magic number that has worked well for us at commercetools. It’s a large enough team that it can draw on the skills from many people, while avoiding the interpersonal conflicts that often arise from smaller teams. Each member of the team likely has a backup (or two), so that if one designer goes on vacation the other can take over, for example. Members of the team can build long-term, trusting relationships with each other. The whole team can go out to eat and sit at one table. The communication overhead is fairly minimal, with there are only 21 communication pathways (only six per individual) to maintain. In short, it’s a good size that works for all constituencies. 

About commercetools

commercetools is a next generation software technology company that offers a true cloud commerce platform, providing the building blocks for the new digital commerce age. Our leading-edge API approach helps retailers create brand value by empowering commerce teams to design unique and engaging digital commerce experiences everywhere – today and in the future. Our agile, componentized architecture improves profitability by significantly reducing development time and resources required to migrate to modern commerce technology and meet new customer demands. 

The innovative platform design enables commerce possibilities for the future by offering the option to either use the platform's entire set of features or deploy individual services, á la carte over time. This state-of-the-art architecture is the perfect starting point for customized microservices, enabling retailers to significantly reduce time-to-market for innovative commerce functionalities.

With offices in Germany and the United States, B2C and B2B companies from across the globe including well-known brands in fashion, E-Food, and DIY retail trust commercetools to power their digital commerce business.

Visit www.commercetools.com for more information.