What breaks at 10, 50 and 150 people, and what to install before each

By Meet Patel · 2026-10-03 · 6 min read

Fred Brooks gave the arithmetic in The Mythical Man-Month. If every worker has to coordinate with every other, the number of communication channels is n(n-1)/2. In the version quoted on Wikipedia, 50 developers give 50 × 49 ÷ 2 = 1,225 channels of communication. Apply the same formula to company sizes. Ten people have 45 possible pairs. Fifty people have 1,225. One hundred and fifty people have 11,175. Headcount rises 15 times from the first size to the last, and the number of possible pairs rises about 248 times.

Two caveats come first. Brooks's formula is an upper bound on coordination paths in a project where each part depends on every other, and a company does not use all of its pairs. And the thresholds in this post (10, 50 and 150) are my working rules. No study I am citing shows that organizations break at exactly those headcounts. They are useful because the mechanism behind each one is concrete, and each mechanism can be tested in your own company.

Around 10: the founder becomes the router

At ten people each person has nine possible partners, and the founder is one of them for everyone. When a customer question touches pricing, a hire touches budget or two people disagree about priority, the shortest path runs through the founder, so the founder becomes the router for most decisions. The company runs quickly while the founder has the context, and slows as the number of decisions per week outgrows the founder's hours.

The router test I would use takes one week. Keep a tally of every decision made that week that anyone had to wait on. Mark the ones that waited for the founder specifically. Divide: founder-gated decisions over all waiting decisions. If that ratio is above about half, the company has a router problem, and the delay is measurable in the waiting time on each item. Eight days to notice describes what that delay looks like once a signal arrives.

Take a hypothetical 12-person company. In the test week, 30 decisions waited on someone, and 21 of them waited on the founder, a ratio of 70 percent. If each of those 21 waited an average of 1.5 days, the company lost 31.5 decision-days in a single week to one person's calendar. That figure is the case for writing decision rights down, and it is easier to put in front of a founder than a general sense that things are slow.

What to install before this point is small. Write down who decides the five most frequent decisions, with a named owner for each, and the limit on what that owner can approve without asking. A one-page weekly priorities note, owned by the founder and read by everyone, replaces many of the questions people would otherwise route through them.

Around 50: no one holds the whole picture

At 50 people there are 1,225 possible pairs and nobody can know what everyone is working on. Three things tend to give way together.

• Shared definitions. Two teams count "active customer" or "closed deal" differently, and both answers are right by their own rules. Three systems, one number shows how that plays out in a single metric.
• Onboarding by osmosis. New hires used to learn the company by sitting near the people who knew it. At 50 there are too many places to sit, so context has to be written down.
• Middle management. A first layer of managers appears without the decision rights that make it useful, and the founder keeps routing around them.

What to install: a metric dictionary with one owner and one definition per number, a decision log for choices that affect more than one team, and written onboarding that a new hire can finish in their first two weeks without a founder present. Give managers explicit decision rights, and say which decisions go to them first. The one-owner rule applies here: every recurring decision has one named person.

Around 150: relationships stop covering everyone

Robin Dunbar's 1993 paper in Behavioral and Brain Sciences, Coevolution of neocortical size, group size and language in humans, used the relationship between neocortex size and group size in nonhuman primates to predict a size for human groups. The preprint says: "Equation (1) yields a predicted group size for humans of 147.8," with 95% confidence limits of 100.2 to 231.1. The figure is often rounded to 150.

The paper concerns social groups. Applying it to a company is my extrapolation, and the wide confidence interval is a reminder that 150 is a rough marker. The reasoning I find useful is this. Below some size, people can hold a working relationship with nearly everyone, and trust travels directly. Above it, trust has to travel through intermediaries, and the company needs mechanisms to replace the direct relationships that used to carry coordination.

What breaks at that stage is the informal network that made up for missing structure. Cross-team requests take longer because nobody knows whom to ask, and a team's priorities collide with another's without anyone seeing the clash. What to install: function-level goals that roll up to company goals, a written statement of how decisions get made, named interfaces between teams (who to ask for what, and how fast they answer), and a standing way to publish decisions to everyone, so that context moves by writing rather than by hallway.

A hypothetical example of an interface: a sales lead at a 150-person company needs a contract exception from legal. With no interface, she asks around, three people forward her on, and the answer takes nine days. With a written interface, the exceptions queue has an owner and a two-day response commitment, and the sales lead knows where to go on day one. The queue costs one person's attention, and it replaces a search that previously cost several people's.

The three thresholds side by side

• About 10 people, 45 possible pairs. Symptom: decisions wait for the founder. Install: decision owners for the five most frequent decisions, a weekly priorities note.
• About 50 people, 1,225 possible pairs. Symptom: teams answer the same question differently. Install: metric dictionary, decision log, written onboarding, managers with explicit decision rights.
• About 150 people, 11,175 possible pairs. Symptom: nobody knows whom to ask. Install: function-level goals, team interfaces, a decision publication routine.

Install one stage early

Structure takes longer to install than the symptoms take to appear. Writing decision rights takes weeks. Growing a manager takes months. A metric dictionary needs several rounds of argument before the definitions settle. If you wait for the symptom, you will be repairing the company while it is failing to serve customers.

My rule is to start the next stage's installation at roughly 70 percent of the threshold: around 7 people, 35 and 100. The numbers are a rule of thumb. The test I would run to see whether it fits your company is to ask, at each of those sizes, which of the three symptoms is already visible. If the symptom is visible, you are late.

Many of these hires and rule changes sit on the borderline of two stages, which is where great early hires stall. The person who thrived when the founder was the router may not want to work inside a decision-rights table, and a good manager at 50 may need a different set of support at 150. Say what the role looks like at the next threshold before you hire into it.

A checklist to run each quarter

1. Count headcount and compute n(n-1)/2, so the number is on the table.
2. Run the router test for one week and record the ratio.
3. Pick ten recurring metrics and check that each has one definition and one owner.
4. Ask three recent hires what they could not find out in their first two weeks.
5. Ask three team leads whom they would approach for a cross-team decision, and compare the answers.
6. List the structure the next threshold needs and name an owner and a date for each item.

The checklist finds the symptom while it is still cheap to treat. Headcount adds people linearly and the pairs between them grow with the square, so a company that waits for the pain will find the pain already well established. Install the structure one stage ahead of the people who will need it.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com