Scrum guidance on team size tends to state the recommended range (typically cited as 3-9 developers) without explaining what specifically degrades as a team exceeds it. Knowing the actual failure modes is more useful than knowing the number, because it explains why the number exists and what to watch for as a team approaches it.
Communication overhead grows faster than the team does. The number of potential one-to-one communication channels in a group grows roughly with the square of its size, not linearly. A team of five has ten possible pairs; a team of eleven has fifty-five. This isn't an abstract concern: it shows up concretely as Daily Scrums that stretch well past their timebox because there's genuinely more to say, and as an increasing number of decisions that require checking with people who weren't in the original conversation.
Sub-teams form whether or not anyone plans for it. Past a certain size, people naturally cluster into smaller informal groups based on who sits near whom, who's working on related pieces of work, or simply who talks to whom most easily. This isn't dysfunction (it's a natural human response to a group too large to track as a single unit) but it undermines Scrum's assumption of one team with one shared understanding of its work, and it often produces exactly the kind of siloed information gaps that a single small team wouldn't have.
The Daily Scrum stops serving its purpose. Fifteen minutes divides unevenly across more people, and a large team's Daily Scrum tends to either run over its timebox regularly, or compress into something so brief it stops providing genuine synchronization value, with people tuning out during updates that don't affect their own work.
Individual accountability becomes harder to track. In a small team, it's relatively easy to know who's doing what and to notice when someone is struggling or under-loaded. In a larger team, this visibility degrades, and problems that would have been caught early in a smaller team persist longer before anyone notices, simply because there's more surface area for something to go unnoticed.
Decision-making slows down even for straightforward calls. A decision that a five-person team can make in a two-minute conversation might require a scheduled discussion, or several rounds of asynchronous input, in an eleven-person team, simply because more people feel entitled to weigh in, and reaching genuine consensus (or even informed dissent) takes longer with more voices.
What to actually do about it
Splitting into multiple smaller teams, each with clear ownership of a coherent piece of the product, addresses the coordination problem directly, but introduces a new problem, which is coordinating across the now-multiple teams. This isn't a reason to avoid splitting; it's a reason to invest deliberately in cross-team coordination mechanisms (which is exactly what frameworks like Flight Levels are designed to address) rather than assuming the split alone solves everything.
The practical threshold isn't really a fixed number: it's the point where the team itself starts reporting that coordination feels harder than the work itself, that decisions take longer than they should, or that sub-groups have started operating somewhat independently of the whole. That's the signal worth acting on, whether it shows up at eight people or fourteen.