You've written the post-mortem. You've run the retro. You've added a new Slack channel to "improve communication." And somehow, three months later, you're writing another post-mortem about a different problem that has the exact same root cause.
The team is too big for how it's working. You know it. You're just not sure you know it enough to act on it.
I've written about when to split a team and how to recognize you're already late. What I haven't written about is the earlier moment — the inflection point before the chaos becomes undeniable. Because by the time it's undeniable, you've already paid the tax.
The Signal Isn't Slowness. It's Coordination Becoming the Work.
Most managers wait for velocity to crater before they act. That's the wrong trigger. Velocity drops are lagging indicators — they show up after the coordination overhead has already embedded itself into how the team operates.
The earlier signal is subtler: your team starts spending more energy staying aligned than shipping. As teams grow, the number of communication pathways increases faster than headcount — a team of four has six potential communication lines; a team of twelve has sixty-six. That math doesn't care about your intentions or your Notion docs.
What it looks like in practice: three Slack threads running simultaneously about the same decision. A PR that needs sign-off from two people who don't share context. A standup where half the room is waiting for the other half to finish before they can start. Coordination overhead is the cumulative time, attention, and operational energy required to keep people aligned — and it accumulates invisibly, disguised as "normal communication," until the team is busier coordinating than executing.
The inflection point is when you catch yourself scheduling a meeting to prepare for a meeting. That's not a process problem. That's a structure problem.
The Ownership Vacuum Is the Clearest Pre-Chaos Indicator
Lars Barkman's framework for right-sizing teams names something I've seen managers consistently explain away: the ownership vacuum. "Who's responsible for this?" becomes a frequent question. Unofficial subgroups form — the frontend people start making decisions without looping in everyone else, not because they're being territorial, but because waiting for the full team is slower than just deciding.
That subgroup formation is your team telling you something. They've already identified the split. They're just doing it informally, without clear charters, without explicit ownership, and without you having made the call. The cost of informal splits is that they create shadow coordination structures — now you have the overhead of the big team plus the overhead of managing the informal factions that emerged to work around it.
The question to ask yourself: can every engineer on your team accurately describe what the other engineers are working on this week? When team members struggle to describe what others are doing, that's a knowledge gap that signals the team has grown past the point where shared context is naturally maintained. You're past the inflection point.
The Monolith Analogy Is More Literal Than You Think
There's a practitioner account from an engineering manager who describes the night a change to a PDF invoice generator took down user authentication — not because they were related, but because they lived in the same codebase, shared the same dependencies, the same deploy pipeline, the same database connection pool. The insight that followed: monoliths don't scale badly in traffic alone. They scale badly in people. Once multiple teams are stepping on each other's code, once a one-line change requires a full redeploy of everything — that's when decomposition earns its cost.
The same logic applies to team structure. A team that's too large doesn't just slow down. It creates unexpected blast radius. One engineer's decision affects another's work in ways nobody anticipated, because the surface area of shared context is too large to manage. As teams grow from 10 to 30 engineers, development often slows, coordination overhead increases, and innovation stalls — and the degradation is measurable, not just felt.
The pre-chaos inflection point is when you start seeing unexpected blast radius on decisions that should have been contained. A backend change breaks a frontend assumption nobody documented. A deployment window gets contested because two workstreams need it simultaneously. These aren't communication failures. They're structural ones.
What to Actually Watch For
The split decision doesn't require a crisis. It requires pattern recognition on three specific signals:
Coordination is consuming more than 20% of work time. More than 20% of work time spent in internal coordination meetings is a red flag — the calendar test is blunt but reliable.
Ownership questions are recurring, not occasional. If "who owns this?" comes up more than once a week, the team's surface area has exceeded its clarity.
Informal subgroups are already operating. If your engineers have already self-organized into functional clusters, the split has happened. You're just not managing it yet.
The inflection point isn't a moment of crisis. It's the week you notice all three of these at once and tell yourself it's probably just a rough patch. It's not. Act before the chaos makes the decision for you.
