Two software teams work calmly on opposite sides of a dividing wall, while tangled communication lines cross between them, representing the coordination costs created by team boundaries.

The Process That Worked at 15 Developers Breaks at 50

A team I worked with scaled from a handful of developers to fifteen without adding a single ceremony. Four events, the same four they’d started with, fixed time boxes throughout. That restraint did more work than it looked like at the time.

Growing a team without growing its coordination overhead is challenging. The number of communication paths in a group grows combinatorially with headcount — Fred Brooks’s original observation, usually summarised as n(n-1)/2 — so doubling a team doesn’t double the coordination load, it multiplies it several times over. Most teams feel that arithmetic directly: more meetings, longer standups, decisions that used to take an hour taking a day.

This team didn’t feel it, because they’d pre-empted it. The four ceremonies stayed fixed, but what happened inside them changed — acceptance criteria got more explicit, working agreements got heavier, the definition of done tightened as headcount grew. The discipline absorbed the combinatorial cost before it could surface as a visible drag on delivery.

Years later, the CTO from that engagement invited me for coffee. Headcount had grown past fifty. Delivery to production was more frequent, and higher volume, than it had ever been. And yet, as he told it, the team had never again felt as productive as it did the year they first split into multiple teams.

📥 Want a practical framework for this?

My free guide — Insights to Improvement — walks through how to identify quality gaps and build the team habits that close them. Used by agile teams in the UK and LATAM.

Download it free →

What he was describing, as far as I can tell from his account, has a different name from the problem he’d solved at fifteen. Conway’s Law holds that organisations design systems which mirror their own communication structure. Once a team splits, the boundaries between the new teams stop being an internal ceremony question and become a structural one: do those boundaries actually match the seams in the software, or did they get drawn along whatever lines were administratively convenient at the time? When they don’t match, every cross-team dependency becomes a synchronisation problem, and no amount of within-team discipline touches it, because the coordination cost hasn’t disappeared — it’s moved to a boundary nobody inside either team owns.

That’s a plausible read on why the feeling of productivity dropped even as the metrics improved. Volume and frequency are visible at the team level. The friction he was describing lives between teams, in inconsistent measurement and unplanned synchronisation — exactly the layer a per-team dashboard is built to miss.

The two problems don’t share a fix. A Brooks’s Law problem gets absorbed by tightening what a team agrees to internally. A Conway’s Law problem asks a different question entirely: who actually owns the boundary between two teams, and who decided where that line would sit in the first place.

The leverage point is different for every team. Finding it is the work.

If this resonated, the next step is free.

A practical guide on turning team improvement into a repeatable system — the same approach I use with clients. No pitch, just the framework.

Download: Insights to Improvement →

Discover more from The Software Coach

Subscribe to get the latest posts sent to your email.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.