How big should your teams be?

When you start talking to agilists, they will tell you all sorts of stories. They will say small teams are good. A team should not be more than 9 to 10 people. They will point out all sorts of science. Dunbar numbers. Things that apes did in groups. Tribes. From 5,000 years ago. Some of these do have merit, but I can tell you that this is all made up. And no one truly knows. And there is no singular answer. And it depends on the context of the work the teams are doing.

My recommendation is very simple. Never start with one team. It does not help you to learn to ship anything. Start with sufficient team members to do all the work required to be done. Get them to figure out how to decompose themselves initially and as they continue the work. If you are a reasonably sized large organization, start with at least 50 team members as that will help give a basket of skills, competencies and experiences to the teams. And like I say that the quantity of team members is "Large enough to learn from and small enough to not fail badly".

Your starter team size (recommended: 50) should be small enough not to fail badly, but large enough to learn from on how multiple teams can work together to produce and ship integrated work, often enough. As early as every week or two at the latest.

From a work point of view, a team size is the number of people required to exhibit all the skills, competencies and experiences that are generally required to ship a total feature to the customer.  If a CEO of a company is paying for it, it would be one's expectation that something gets shipped. A 50 member team is probably $10 million a year that is a run rate of $200,000 per week. For $200,000 something needs to be produced, shipped and market validated each week. If 50 people don't know how to do that, then there is really no agility in that system. Because, that is when value gets realized.  And no CEO is going to care only about the science of team size. That is irrelevant to the conversation, as sunken money without validation is the biggest risk. In fact, one could form a team of teams of say 50 people and let the team members figure out how they would like to do the work.

Sunken money with no market validation is the biggest risk

In reality work gets done by small sets of people. Sometimes, it is a couple of people working together. Sometimes, it might be 3-4 people. Sometimes, it might be 7. Sometimes one needs to do pair-programming. Sometimes mob programming. Sometimes it is all hands on deck, especially during complex integration. Therefore, for a piece of work the context of the work determines how many people are required. And as skills and competencies spread among team members, the size of people working together on something specific will continue to change to a smaller number.

So why does one care about the size of the team?  50 people can be carved in 5 teams of 10, or 10 teams of 5.  It is essentially whatever the team members feel is optimal in their context. There is no necessity to go in with a pre-conceived answer before one knows what is being built and what problems are being solved. And these keep changing each day as work progresses. Pretending to know the team-mix even when every human is different and there is the real impossibility of balancing skills and competencies on every team just means that - don't try doing it, and leave it to the teams to group themselves and then regroup themselves as often as they believe it is ideal for them to do so.