Home → Leadership
Growing a Team: Five People and Fifteen Are Not the Same Job
The team grows and the work does not get faster; the meetings get longer. Nobody became lazy, nobody got worse — you are simply running three times the people with the same method. Everything that worked at five breaks at fifteen.
- The problem is pairs, not people. Five people have ten paths; fifteen have a hundred and five.
- A split is an architectural decision. Conway: the system settles on your team boundaries.
- Split along the work, not the people. "Who gets on with whom" is a poor criterion.
- Splitting too early is expensive too. Two teams means two rotas and two backlogs.
The one thing that grows exponentially
Double the team and you do not double the output, because what grows is not headcount but who needs to talk to whom:
| People | Pairs | In practice |
|---|---|---|
| 5 | 10 | Everyone knows everything; standup takes 8 minutes |
| 8 | 28 | Information still flows, but needs repeating |
| 12 | 66 | People check their phones in meetings |
| 15 | 105 | "I didn't know that" becomes a daily sentence |
In our team the clearest measure was standup length: 8-9 minutes with seven people, 25 minutes with thirteen. As it got longer it got less useful, because the share of items that concerned everyone had dropped. In a thirteen-person standup you waited 22 minutes to hear the three sentences about your own work.
Signs it is time to split
A rule like "split above eight" helps less than it sounds, because the work decides, not the headcount. The signals to watch:
- People are not listening in standup. The earliest and most honest signal.
- The backlog holds two stories. If prioritising means comparing apples with oranges, you are discussing two products.
- A natural boundary has appeared in the codebase. Two areas exist, and nobody touches both.
- "This does not concern us" is common in planning.
- The manager has become the bottleneck. If 1:1s no longer fit the week, the team has already outgrown itself.
Splitting early has a cost that is routinely underestimated: two on-call rotas, two backlogs, two planning meetings and a new coordination overhead between them. Two teams of five are not always faster than one team of ten.
Where to split: taking Conway seriously
Conway's law says systems mirror the communication structure of the organisation that builds them. However you split the teams, the architecture will eventually settle on those boundaries. That turns a team split from a staffing decision into an architectural one.
- "Who gets on with whom"
- By technology: a frontend team and a backend team
- By seniority: the seniors as one team
- Split it in half and see what happens
They all end the same way: every piece of work needs both teams.
A team should be able to finish a piece of work end to end on its own: from idea to production. Draw the boundary accordingly — product flow, customer journey or data ownership.
The test: write down the first five items of next quarter. How many finish inside one team? Fewer than three means the boundary is in the wrong place.
Splitting by technology is especially treacherous: it looks tidy on paper, and then every small feature requires synchronising two sprints, with the waiting taking longer than the work.
Replacing what the split costs you
The moment you split, you lose something: shared context. Nobody knows everything any more. Accept it and put cheap connections in its place:
- A joint demo. The two teams show each other every two weeks; thirty minutes, unrehearsed.
- A written decision record. Architecture decisions in one place, short. After a split this becomes mandatory.
- Temporary visits. One person spends a sprint with the other team; the fastest way to move knowledge.
- Shared on-call, separate sprints. The system is still one system; fully separating the rota is the road to "that is not our service".
There is also the management side: two teams need two leads. If you are not growing one from within, the split stays half-done — and that means a new manager's transition period, which has to be part of the plan.
Checklist
- How long is standup? How many people are listening?
- Do the first five items of next quarter finish inside one team?
- How many separate product themes are in the backlog?
- Is there a natural boundary in the codebase, or am I inventing one?
- Who leads the second team? Are they ready?
- What knowledge disappears when we split, and what replaces it?
- If this boundary is wrong in six months, what does undoing it cost?
Conclusion
Growing a team is not adding headcount; it is rebuilding shared context. At five people context formed by itself; at fifteen you have to construct it deliberately: boundaries, written decisions, joint demos.
And the best split is the one where nobody waits for anybody. Without that you have not created two teams; you have cut one team in half and inserted a queue between the parts.