At first glance the arithmetic is simple. If one person does 1 unit of work, then ten people should do 10. In practice it does not work that way.
The more people there are, the more time goes into communication: syncing up, reaching agreement, doing reviews, signing off on decisions.
Passing on context is a problem of its own. The larger the team, the harder it is to make everyone understand how the system is built and why. Especially with no clear rules about where knowledge lives: some of it stays in chats, some in Jira, some in Confluence, and some exists only in one person’s head.
The upshot is that finding the right information and rebuilding context become part of the work themselves.
There is another side to this, known as social loafing. In a large group one person’s contribution becomes less visible. The link between your own effort and the shared result is harder to see, and responsibility slowly dissolves. It starts to feel as though doing slightly less is fine, because somebody else will make up for it.
Both factors are easy to spot in software development. Adding people increases a team’s capacity, but it also creates more connections, dependencies, and conversations.
More people ≠ proportionally more output.
Sometimes, instead of growing the team, it pays to cut the number of dependencies, draw clearer lines of ownership, and give small groups more autonomy.