When one team on a product grows into ten, what problems does scaling introduce?

## Scale is a different problem, not a bigger one A single cross-functional team enjoys three properties it never has to think about. Everyone works from one ordered list of work, so a priority conflict is settled in a conversation. Everyone shares one meaning of "finished", so nobody audits what another group meant by it. And integration is nearly continuous — new code meets the rest of the team's code within hours, while the author still remembers writing it. Add nine more teams and every one of those properties has to be manufactured deliberately. That is what scaling frameworks are: not "more Agile", but machinery for buying back what a small team had for free. Understanding what broke is the prerequisite for judging whether any particular framework is worth its price. ## The three things that break **1. Dependencies leave the team.** Inside one team a blocking task is a five-minute conversation at a desk. Across teams it becomes a queue: a request, someone else's estimate, a place in someone else's ordering, and a wait measured in iterations rather than hours. The number of relationships that might need a conversation grows roughly with the square of the team count while capacity grows linearly, which is why coordination cost climbs faster than headcount. **2. The shared product definition fragments.** Ten groups each ordering their own list of work will each optimise a local outcome and ship something the customer experiences as incoherent — three different date pickers, two conflicting cancellation rules. Every scaling framework's answer starts in the same place: one ordered product backlog for the product, one person accountable for that ordering, and one shared standard that every team's output must meet before it counts as finished. **3. Integration stops happening by itself.** Ten teams that each declare their own piece finished have produced ten unproven claims. The value only exists once the pieces are assembled and exercised together, and the longer that assembly is deferred the more expensive it becomes, because defects surface far from the change that caused them. So the frameworks all schedule assembly explicitly — an assembled, working product every iteration, an integration accountability, or a cadence at which the whole group demonstrates one running system. | Property | One team | Ten teams | |---|---|---| | Priority conflicts | Settled in conversation | Need a single ordering and an owner for it | | Meaning of "finished" | Implicit and shared | Must be written down and agreed across teams | | Dependencies | Mostly inside the team | Cross-team queues with schedules attached | | Integration | Continuous by habit | Scheduled, owned and defended | | Planning | One session | A joint event plus per-team planning | ## The overhead is the price, not the product The uncomfortable part is that the coordination a framework adds is pure cost. A joint planning event, cross-team representatives, an integration accountability, a dependency map — none of them ship customer value. They exist to stop the dependency load from destroying the value the teams do ship. That reframes the whole subject as a trade: you buy predictability across teams and pay for it in hours spent coordinating instead of building. That trade has a break-even. Below it — a handful of teams with genuinely separable work — the honest answer is to remove the dependencies rather than schedule them, by changing who owns what. Above it the overhead is cheaper than the chaos. ## A worked example A coach-tour scheduling platform starts with one team. Two years later there are nine, and a partner integration deadline lands: a large operator's booking feed must go live on a fixed date. 1. The routing team needs a seat-inventory change that the pricing team owns. That change sits 11 days out in the pricing team's ordering, so the routing work is idle for most of a 3-week iteration. 2. Three teams have each shipped "their part" of the partner feed. Assembled for the first time in week three, they disagree about time zones for overnight departures, and the fix costs 4 days that were in nobody's plan. 3. Nobody can answer "will the feed be ready?", because nine teams each know only their own slice. None of those is a technical failure. Every one is a coordination failure — a dependency nobody scheduled, an assembly nobody owned, a shared picture nobody kept. ## What interviewers listen for - You name the *problems* — dependencies, one product definition, assembly — before naming any framework. - You describe coordination as a cost that must be justified, not as a sign of maturity. - You do not claim that scaling makes people faster. Ten teams almost always deliver less per person than one; the reason to have them is capacity and coverage, not output per head. - You separate "we have many teams" from "we need a scaling framework". The frameworks are one answer; reducing the dependencies is another.