What breaks at every size
Org failures arrive on a schedule. Knowing which one is next turns a crisis into a maintenance task you did early.
Also available as a standalone Playbook →
Growing an engineering organisation feels continuous from the inside, and isn't.
It goes in steps. Something works fine for a year, then stops working over about six weeks, and everybody experiences the failure as new, personal and specific to their own company.
It almost never is.
Four breakpoints show up in nearly every organisation, at roughly eight, twenty, fifty and a hundred and fifty people.
The numbers are soft. The sequence isn't.
Around eight: the end of the single conversation
Below eight engineers, coordination is free.
Everyone's in the same channel, hears the same customer complaint, and can reconstruct any decision by asking the person sitting next to them.
What breaks is memory.
Somebody makes a call about how authentication works on a Tuesday. Four months later two people have different accounts of what was decided, and both of them are sincere.
Nothing was written down, because writing things down felt like bureaucracy when there were four of you. And it was.
The symptom that arrives first.
The same question gets answered twice, differently, by two people who both had the authority to answer it.
What to add: a decision log.
Genuinely just a file in the repo. Dated entries, what was decided and why, and what would make you revisit it.
Ten minutes per entry. Cheapest thing on this entire page, and the one most often skipped.
Around twenty: informal coordination dies
This is the sharpest of the four and the one founders take hardest.
At twenty engineers there are too many pairs of people for everyone to stay current with everyone.
The founder or first engineering leader, who has genuinely been in every meaningful decision until now, becomes a bottleneck without any single decision going wrong anywhere.
Things get slower and nobody can point at why. Two teams build overlapping things because neither knew the other had started.
The symptom: decisions waiting on one person's calendar.
Look for work that sat still three or more days, waiting on an answer that four people could have given in hindsight.
What to add: real teams with real ownership, a planning rhythm that doesn't require the founder in the room, and probably your first engineering manager. Also the moment where written proposals stop being optional, because the alternative is that context now only reaches people who happen to be nearby.
The emotional content of this transition is worth naming.
Going from "I know everything that's happening" to "I know about a third of what's happening" feels like losing control of your own company, and the instinct is to claw the visibility back through status reporting.
That instinct produces a lot of dashboards and no improvement.
Around fifty: culture stops transmitting by contact
Up to about fifty, new people learn how things are done here by sitting near people who already know. Standards, tone, what gets escalated, how much testing is enough. Nobody teaches it and it works.
Past fifty, more than half the organisation joined after the culture was formed, and a meaningful number of them were onboarded by someone who was themselves onboarded six months ago. Drift starts. Not dramatic drift, just two teams with visibly different bars for code review and no shared understanding of why.
The symptom: you hear about a decision, made two layers down, that you'd have made differently, and when you ask why you get a completely reasonable answer based on information you'd never have used.
That's not a failure. That's the job changing. The mistake is treating it as insubordination.
What to add: written standards for the things that actually matter (review, testing, incident handling, what a promotion means), an onboarding process that someone owns, and managers of managers who are chosen for judgment rather than tenure. Levels usually become necessary somewhere in here too, though later than most companies introduce them.
Around a hundred and fifty: coordination becomes the product
Dunbar's number gets quoted a lot and probably carries more weight than the anthropology supports, but something real does happen in this range. You can no longer hold the organisation in your head as people. It becomes groups.
The dominant cost stops being how well any individual team works and becomes what happens between them. Dependencies, shared infrastructure, the six-week wait for another team's roadmap slot, the migration that requires eleven teams to do a small thing each.
The symptom: most of your senior people's time goes on cross-team negotiation, and the phrase "we're blocked on" appears in every update.
What to add: platform and internal tooling as a funded concern rather than a volunteer effort, interfaces between teams that are explicit enough to be depended on, and a written technical strategy that lets teams decide consistently without asking. This is where the work of leadership becomes mechanism design and stays there.
Why the numbers are wrong
I've given four numbers and I'd distrust them if I were you.
The underlying variable isn't headcount, it's the number of things that need coordinating, which is roughly the count of teams times the count of shared systems. A twelve-person company with six microservices and two products can hit the twenty-person wall early. A forty-person team on one monolith with clear ownership can sail past fifty without noticing.
Distributed teams hit every breakpoint earlier, because the free coordination that comes from proximity is a real subsidy and remote work removes it. If you're fully distributed, subtract something like a third from every number above, and put the decision log in place on day one.
Building one stage early
The useful discipline is to install the next stage's machinery about six months before you need it, while there's slack to do it badly and fix it.
The unuseful version is installing two stages early, which is how a twenty-person company ends up with a career ladder, a change advisory board, and quarterly OKR cascades. Process copied from a company four times your size is not preparation, it's cargo. It will slow you down now in exchange for a problem you may never have.
One stage ahead. Then stop and ship something.