Every services firm and product team eventually hits the same wall: a pod that was delivering predictably at six engineers stops delivering predictably at ten. Velocity flattens. Quality dips. Standups stretch from 15 minutes to 45. Nobody can tell you exactly why — but everyone feels it.
This isn't a coincidence. It's a structural property of how engineering teams communicate. And the answer isn't to push harder on the same model — it's to change the model.
The math nobody told you
A pod of n engineers has n(n-1)/2possible pair-wise communication channels. At six people that's 15 channels. At ten people that's 45 — three times the coordination overhead for less than twice the engineering throughput.
Brooks made this point in 1975. Every generation of engineering leaders rediscovers it.
Adding people to a late software project makes it later. The reason is communication overhead, and it scales quadratically.
Where it actually breaks
Around 7–9 engineers on a single pod, three things start happening simultaneously:
- Standup overload. 9 people each speaking 90 seconds = 14-minute standup before context-switching cost. Nobody listens to anyone else's update.
- Code review concurrency. Too many open PRs touching too many shared files. Review becomes shallow or becomes a bottleneck.
- Architectural drift. Two engineers solve the same problem differently because they didn't talk to each other. The codebase fragments slowly.
Three patterns that actually work past 8
1. Split into two pods, with a clean interface between them
The most common and the most effective. Find the natural seam in the system — usually a service boundary or a domain boundary — and split the pod along it. Each pod owns its deliverables, its repo, and its on-call. They communicate via API contracts, not standups.
This works if the seam is real. Splitting across an arbitrary boundary creates worse coordination overhead than just keeping the big pod.
2. Tier the team: a core pod plus specialists
Keep a 5–6 person core pod that owns the system end-to-end. Pull in specialists (data, DevOps, mobile, ML) as embedded contributors for 4–8 week stretches. The specialists report to their own discipline lead but operate inside the pod for the duration.
This works for engagements where the work mix changes phase by phase. It doesn't work if the specialists are full-time embedded — at that point you're back to a single large pod.
3. Async-first communication with a written cadence
Replace synchronous standups with async daily updates in a shared doc. Replace ad-hoc Slack threads with weekly written design docs that get reviewed in a single meeting. Replace impromptu architecture decisions with an ADR (architecture decision record) that anyone can comment on for 48 hours before it's adopted.
Async-first lets a single pod work past 10 people without standup melting down. The tradeoff: it requires a writing culture, which most engineering teams don't have. If you're not willing to invest in that, this pattern won't stick.
What we do at Top Kingwin
Across our engagements, our default pod size is 5–7 engineers, and we split rather than grow past 8. Larger engagements run two or three coordinated pods, each owning a service boundary, with a part-time architect floating across them. The architect is the only person who carries context between pods.
We've found that two 6-person pods consistently outship one 12-person pod. Not by a little — by a lot. Roughly 1.4× the throughput, with measurably better code quality.
If you're feeling the wall
Three diagnostic questions:
- How long is your daily standup? Anything over 20 minutes is a symptom.
- How many open PRs does your team carry on average? Anything over 1.5× team size is a symptom.
- How often do two engineers solve the same problem differently in the same week? If you can't remember the last time it didn't happen, you're past the wall.
This is a pattern we've seen across nearly every engagement that scales past initial delivery. If you're trying to grow a pod and feeling the resistance, we'd love to compare notes.