From 6 to 13 squads: what actually breaks when you scale delivery

Between 2021 and 2022 I scaled Toptal’s Growth Product organisation from 6 to 13 agile squads, and served as interim VP of Growth Product along the way. The naive model of scaling — hire more people, create more teams, get more output — fails quietly and predictably. Here’s what actually breaks, in the order it breaks.

1. Alignment breaks before velocity does

Six squads can stay aligned through osmosis: shared channels, overlapping meetings, one roadmap review. Somewhere around squad eight, osmosis stops working. Squads keep shipping — velocity charts look great — but they start shipping past each other: duplicated components, conflicting experiments on the same funnel step, two teams “owning” the same metric.

The fix isn’t more meetings. It’s fewer, sharper artifacts: a single source of truth for who owns which outcome, and a product development process that every squad actually follows. Boring documents, ruthlessly maintained, beat charismatic all-hands every time.

2. The dependency graph becomes the real org chart

Past ten squads, your delivery speed is set by the dependency graph, not by any team’s velocity. We learned to treat cross-squad dependencies as first-class work: visible on the roadmap, owned by someone, with an explicit cost. The moment a dependency is invisible, it becomes a delay.

This is also where platform thinking pays for itself — shared infrastructure for auth, identity, experimentation, and analytics means squads stop reinventing the same plumbing and stop colliding in it.

3. Leadership stops scaling with headcount

Every squad you add multiplies communication paths. The job of the person at the center changes completely: from making decisions to designing how decisions get made. Delegation without a decision framework is abdication; with one, it’s leverage.

Interim VP was where this became visceral for me. The weeks I spent making individual calls were my worst weeks. The weeks I spent clarifying ownership, killing ambiguous projects, and writing down “how we decide” were the ones that moved the organisation.

The uncomfortable summary

Scaling delivery is not an engineering problem. It’s an information architecture problem: who knows what, who owns what, who decides what — kept legible while everything doubles. That conviction eventually sent me back to academia; my PhD research studies exactly how software organisations deliver at scale. And it’s also why my current products are built by AI agents inside a strict process: because I’ve watched what happens to teams when process is an afterthought.