Why the processes that worked at 5 people break at 20

At some point around 15 people, most founders have the same realization.

Something changed. Simple things that used to take a day now take a week. Decisions that used to happen in Slack now require three meetings. New hires spend weeks trying to figure out how things work. And the founder, who used to know everything that was happening, now knows less and less, even though nothing obvious has gone wrong.

The company isn't broken. It's just outgrown the way it was operating. And the gap between "what worked at 5" and "what works at 20" is steeper than most founders expect.

This post is about why that gap exists, what specifically breaks first, and what you actually need to build before it does.

The invisible cliff between 10 and 20

Every stage of scaling has its challenges, but the stretch from 10 to 20 people is uniquely painful.

Below 10 people, companies operate through direct relationships. Everyone knows what everyone else is doing. Decisions happen in hallway conversations or shared channels. Knowledge lives in people's heads, and that works because the heads are all in the same room (or Slack workspace).

Above 50 people, companies have usually built enough infrastructure to function at scale. There are systems of record. Processes are documented. Teams have clear ownership. Visibility isn't perfect, but it exists.

Between 10 and 20 is the cliff. You've outgrown the direct-communication mode, but you haven't yet built the systems that replace it. Everyone still expects the CEO to know everything. The CEO still feels responsible for knowing everything. And the number of things happening simultaneously has grown faster than any one person can track.

The symptoms are predictable:

• Decisions queue up waiting for the founder.
• New hires take weeks longer to become productive than they should.
• Different people do the same task different ways, because nobody wrote down the right way.
• Handoffs between functions break because the "handoff" is still a tap on the shoulder.
• Quality becomes inconsistent, not because people are bad, but because the system can't enforce consistency.

Almost every growth-stage company hits this cliff. The ones that navigate it cleanly aren't smarter or better funded. They just recognized what was breaking and built the right infrastructure before it became a crisis.

What breaks first (and why)

The failures don't happen randomly. They cluster around a few specific patterns.

• Knowledge transfer breaks. At 5 people, knowledge lived in heads and that was enough because all the heads talked to each other daily. At 20 people, the heads don't overlap. A CSM needs to know what Sales promised a customer six months ago. Sales has moved on. The CSM either interrupts a busy AE or guesses. Both are bad options.

• Decisions bottleneck at the founder. The CEO or COO used to make every meaningful decision by default. At 20 people, there are too many decisions and not enough of the CEO. The queue grows. Teams wait. Momentum slows. One Reddit founder put it bluntly: "Every question routes to me. Even questions that shouldn't."

• Onboarding stops working. At 5 people, you onboard someone by sitting next to them for a week. At 20 people, you can't afford to lose a week of a senior person's time for every new hire. But you also don't have documentation, so new hires spend three weeks just figuring out how the company operates before they can do real work.

• Quality becomes inconsistent. When one person did customer onboarding, it was always done the same way, because it was always the same person. When three people do onboarding, each develops their own version. Customers start getting different experiences. You can't tell because you're not watching all three.

• Cross-team handoffs fail. At 10 people, "the sales person" handed the deal to "the CS person" by yelling across the room. At 20 people, there's a sales team and a CS team, but no formal handoff. Context gets lost. Customers notice. CS spends half their time reconstructing what Sales already knew.

Any one of these, in isolation, is fixable. The problem at 20 people is that they all happen at once.

Why adding headcount makes it worse

Most founders' instinct, when they feel the strain, is to hire. More hands, faster execution. Sometimes this works. More often it makes things worse.

Adding a person to a broken process multiplies the brokenness. If onboarding takes three weeks because nothing is documented, adding another hire means another three-week productivity gap. If decisions queue at the founder, adding another team means more decisions in the queue. If knowledge is tribal, adding someone means one more person who doesn't know what the tribe knows.

The companies that scale cleanly from 10 to 50 usually slow down briefly at 15-20 people. They stop hiring for a quarter. They write down processes. They build systems. Then they resume hiring into a company that can actually absorb new people.

Companies that keep hiring through the cliff often end up with 40 people who can't get work done, instead of 15 people who could.

The four things you actually need at 20 people

What replaces direct-communication mode isn't one thing. It's four things that, together, let the company keep operating without requiring every head to know what every other head knows.

1. Systems of record, not spreadsheets

At 5 people, a shared Google Sheet is a system of record. At 20 people, it isn't. You need tools where data is the source of truth, where changes are logged, where history is searchable, and where multiple people can work in parallel without overwriting each other.

That usually means a real CRM (not a spreadsheet), a real project management tool (not a Notion page), a real support system (not a shared inbox). The specific tools matter less than the fact that data lives somewhere persistent and queryable.

2. Documented processes, not tribal knowledge

If a process exists only in someone's head, it will be done differently every time, taught wrong to new hires, and forgotten when that person leaves. At 5 people this is manageable. At 20 people it's a source of constant rework.

Documentation doesn't need to be perfect. It needs to exist. The test: if your onboarding lead quit tomorrow, could the next person figure out how to onboard a customer from what's written down? If no, that process is a time bomb.

3. Clear ownership, not shared responsibility

Shared responsibility means nobody is responsible. At 20 people you need specific owners for specific outcomes: one person who owns onboarding, one person who owns renewals, one person who owns billing disputes. Not committees. Not teams. Individuals whose name is on the outcome.

Ownership also means authority. The person who owns onboarding can change how onboarding works without asking the founder for permission. If every decision still routes up, you haven't actually delegated ownership, you've just delegated tasks.

4. A visibility layer, not ad-hoc reporting

At 5 people, the founder could walk through the office and see how things were going. At 20 people, that doesn't work. The founder needs a way to see the state of operations without personally interrupting everyone to ask.

A visibility layer isn't another dashboard. It's a system that surfaces the things that need attention: bottlenecks forming, clients at risk, processes slipping, handoffs getting lost. It answers the question "what should I care about right now" without requiring the founder to ask every team individually.

What operational visibility looks like at 20 vs 5

The shift from direct communication to systematic visibility isn't just about adding tools. It's about changing the fundamental operating model.

| At 5 people | At 20 people | | --- | --- | | Ask the person who knows | Query the system | | Status in standup | Status visible asynchronously | | Founder sees everything directly | Founder sees signals, teams own details | | Issues surface when someone complains | Issues surface when patterns emerge | | Knowledge in heads | Knowledge in docs and systems | | Trust through proximity | Trust through visibility |

The companies that make this transition cleanly treat it as a deliberate project, not a side effect. They spend real time building the visibility layer before they're forced to.

The 20-person test

Here are five questions that will tell you whether your company is ready for its next growth stage.

1. If your head of CS quit tomorrow, could the next person figure out how to run onboarding from what's written down?

2. Can you tell which clients are at risk of churning without asking CS?

3. Can a new hire get productive in their first week without pulling a senior person away from their work?

4. Do you know which customers are getting different experiences depending on who's serving them?

5. Can you see where work is getting stuck without interrupting anyone to ask?

If the answer to two or more of these is "no," you're operating below what a 20-person company needs. That's fine. It's fixable. But it won't fix itself, and it will get more expensive the longer it waits.

The founders who scale cleanly usually notice these gaps around 12-15 people and spend the next 3-6 months building what's needed before the company grows into the next painful phase.

The founders who don't, often find themselves at 30 people wondering why their company feels slower and messier than it did at 10.

---

If you want to see how operational intelligence can replace some of this visibility work automatically, read how a property management team cut weekly admin by 50% when they stopped being the integration layer between their tools.