Growth from twenty people to forty feels like more of the same. It isn't. Somewhere in that range, a company stops being a group that can hold everything in its collective head and becomes an organization that needs structure to function.
The useful part is that the breakage is predictable. In almost every company that goes through this, four things break — and they break in roughly the same order.
First: onboarding
The first thing to go is the ability to absorb new people. At twenty, a new hire learns by sitting near someone and absorbing context. At forty, there isn't a free experienced person to sit near, and the context has grown too large to absorb informally.
The symptom: ramp time stretches. People who would have been productive in six weeks take three months, and nobody can say exactly why.
Second: decision-making
At twenty people, most decisions route through one or two people and that's fine — they have the context and the bandwidth. At forty, the same routing creates a queue. The founder or the senior lead becomes a bottleneck, not because they're slow but because the volume doubled while their hours didn't.
The symptom: things sit. Proposals wait for approval. Projects stall at the same step. Everyone is working and nothing is finishing.
Third: customer ownership
With a small team, everyone knows roughly which clients are in trouble. That shared awareness disappears quietly. Accounts start falling between people — each assuming someone else is covering it.
The symptom: a client churns and the post-mortem reveals three people each knew one piece of the problem and nobody had the whole picture.
Fourth: reporting
Reporting is last to break because it's last to be noticed. The numbers that were fine when one person could sanity-check them become unreliable when four teams feed into them with different definitions. The reports still get produced. They just stop being trusted.
The symptom: meetings where people dispute the numbers instead of discussing them.
Why the order matters
If you know the sequence, you can work ahead of it instead of behind it.
Before you hire the people who will take you from twenty to forty, write down how onboarding actually works. Before the decision queue forms, decide explicitly which decisions don't need you. Before accounts start slipping, assign named ownership with a review cadence. Before the numbers get disputed, agree on definitions.
None of this is expensive at twenty people. All of it is expensive at forty.
The mistake
The common error is to treat each break as an isolated incident. Onboarding is slow, so we hire a recruiter. Decisions are stuck, so we add a manager. Accounts are slipping, so we hire a CS person.
Each fix is reasonable on its own and none of them address the thing that's actually happening: the company outgrew an operating model that was never written down, and adding people to an unwritten model makes it worse, not better.
The question isn't what to fix first. It's whether you're building the structure before you need it, or after it's already cost you.