The thing nobody warns you about scaling is that the structure which got you here is the one most likely to sink you. The founder who knew every customer, the engineer who could answer any question, the decisions made over coffee, these are the very things that stop working at the next size up. Scaling is less about adding people and more about rebuilding how the people you have coordinate.

The quick version

  • Scaling means handling more, more people, customers, revenue, complexity, without your costs, delays or mistakes growing even faster. It is not the same as just getting bigger.
  • Growth is not smooth. Organisations tend to grow in calm stretches punctuated by predictable crises, where the management style that worked must be replaced rather than tuned.
  • There is a human ceiling on coordination. The informal "everyone knows everyone" model has a natural limit, after which you need explicit structure, rules and roles to do what conversation used to do for free.
  • The central choice is how much to standardise versus how much to let local teams vary, and the answer changes as you grow.

Why bigger is not automatically better

Start with the word itself. To scale is to grow output faster than the cost and friction of producing it, to serve twice the customers with far less than twice the overhead. The opposite, where each new layer of size adds more than its share of cost, delay and confusion, is what economists call diseconomies of scale: coordination gets expensive, communication garbles, and decisions that took an hour now take a fortnight and a steering committee. Most of the pain people attribute to "growing too fast" is really this, adding mass without redesigning how that mass moves.

Which is why it pays to treat every doubling as a design problem, not a hiring problem. Before you add the next cohort of people, ask what will break when they arrive: which decisions currently rely on one person's head, which conversations happen by luck rather than by design, which processes only work because the team is small enough to forgive them. Scaling well is the discipline of fixing those before the new headcount exposes them, not after.

Growth comes in jolts, not a smooth line

The most useful map of how organisations grow is also one of the oldest, and it has aged well. In "Evolution and Revolution as Organizations Grow", first published in Harvard Business Review in 1972 and updated by the author in 1998, Larry E. Greiner argued that companies don't grow on a smooth curve. They move through long, calm phases of evolution, each ended by a sharp revolution: a crisis where the very practices that produced the last phase of growth become the thing holding it back.

Greiner names the phases by what drives growth in each, creativity, direction, delegation, coordination, collaboration, and (added in 1998) alliances. Between them sit the crises. The young company grows on creativity until it hits a leadership crisis: the founders can no longer run everything by feel. It grows again through direction, professional management, budgets, defined roles, until that very control provokes an autonomy crisis, as capable people chafe under decisions made far above them. Delegation answers that, until autonomy fragments into a control crisis; coordination answers that, until coordination calcifies into the red-tape crisis every large company knows.

flowchart LR
  A(["Creativity"]) -->|"Leadership crisis"| B(["Direction"])
  B -->|"Autonomy crisis"| C(["Delegation"])
  C -->|"Control crisis"| D(["Coordination"])
  D -->|"Red-tape crisis"| E(["Collaboration"])
  E -->|"Growth crisis"| F(["Alliances"])
Greiner's phases of growth, each ended by the crisis its own success creates. Leaders Loop

The practical use here is to read your symptoms as a stage diagnosis, not a list of unrelated problems. If your best people are quitting because they can't make a call without three sign-offs, you are likely in an autonomy crisis, the cure is delegation, not better sign-off software. If nothing ships because every team optimised for itself, that is a control crisis, and the cure is coordination. Greiner's real gift is the order: each solution plants the seed of the next crisis, so the structure you build now should be chosen knowing it will eventually need replacing.

An honest limitation. Greiner's model is a lens, not a law. It is a stylised sequence drawn from observation, not a tested prediction, real companies skip phases, loop back, or sit in one for a decade. Industries that grow slowly stretch the phases out; fast ones compress them. Use the model to name the crisis you're in and to anticipate the next, not to insist your company march through six tidy boxes in order.

The human ceiling on "everyone knows everyone"

There is a second, quieter limit on scaling, and it is biological rather than managerial. Anthropologist Robin Dunbar proposed, from a correlation between primate brain size and social-group size, that humans can comfortably maintain only around 150 stable relationships, a figure now widely known as Dunbar's number. Dunbar pointed to recurring echoes of it: the size of many traditional villages, of the basic unit in several professional armies, and of natural community groupings. Below roughly that number, an organisation can run on relationships, you know who to ask, who's good at what, who to trust. Above it, you literally cannot hold everyone in your head, and the informal network that coordinated the work silently stops covering it.

Below about 150 you can run on relationships; above it, you have to run on structure, because no one can hold the whole company in their head any more.

The most cited corporate application is the manufacturer W. L. Gore & Associates (of Gore-Tex), long reported to cap a plant at around 150 people and split it once it grows past that, precisely to keep the "we all know each other" dynamic alive. The lesson isn't to treat that threshold as a number to beat; treat it as a signal. When a team, site or division pushes past Dunbar-scale and you feel coordination getting heavy, the answer is usually to divide into smaller, more autonomous units with clear interfaces, not to bolt more process onto one unit that has outgrown the human limit.

An honest limitation. Dunbar's number is a memorable approximation, not a precise constant, the underlying figure carries a wide statistical range, and it has been actively contested in the research literature. Treat it as a rule of thumb about when relationship-based coordination starts to strain, not as a hard headcount at which an org chart must legally split.

The choice underneath all of it: standardise or vary

Every scaling decision eventually reduces to one tension: how much should every part of the company do things the same way, and how much should local teams adapt? Stanford's Robert Sutton and Huggy Rao, in Scaling Up Excellence (2014), frame this memorably as a choice between "Catholicism", replicate the one true way exactly, every branch identical, and "Buddhism", where a shared mindset travels but the specifics flex to fit each place. Their point, drawn from years of cases, is that neither extreme wins: the craft of scaling is deciding, deliberately and case by case, which things must be identical everywhere (safety, brand, core values) and which should be left for local judgement.

Make that choice explicit, then, instead of letting it happen by accident. Write down the short list of non-negotiables that travel unchanged, and then genuinely free everything else to vary. Scaling fails in both directions: over-standardise and you crush the local knowledge that made the original great; under-standardise and you get a hundred incompatible versions of the company with nothing holding them together.

A worked example

Take a company, call it Meridian, a services firm. (Illustrative figures throughout; this is a teaching example, not a real company.) At 40 people it hummed: the two founders knew every client, decisions happened in the kitchen, and "ask Priya" was the documentation. Eighteen months and a funding round later it is 180 people across three cities, and everything that used to be easy is now slow. New hires don't know who to ask; the founders are the bottleneck on every decision; two offices have quietly invented contradictory ways of running a project.

flowchart TD
  A(["40 people
runs on relationships"]) --> B{"Crossed ~150?
founders the bottleneck?"}
  B -->|"Yes"| C(["Autonomy crisis
(Greiner)"])
  C --> D(["Delegate: real decision
rights to team leads"])
  C --> E(["Divide: smaller units
under Dunbar-scale"])
  C --> F(["Standardise the few
non-negotiables only"])
  D --> G(["180 people that still
move like 40 did"])
  E --> G
  F --> G
One scaling moment, read through three lenses at once. Leaders Loop

Read through the three lenses, Meridian's mess resolves into one diagnosis. Greiner says this is the autonomy crisis, growth through direction has run out, and capable people are stalling because every call routes through the founders. Dunbar says they've crossed the threshold where one network can't hold the whole company. Sutton and Rao say the two divergent offices are a standardisation question left unanswered. The fix is not "more meetings." It is to give team leads genuine decision rights (delegation), break the 180 into smaller units with clear remits (dividing below the human ceiling), and write the short list of things every office must do identically while letting the rest flex. Do that, and Meridian at 180 can move with something close to the speed it had at 40, which is the entire point of scaling well.

Frequently asked questions

What's the difference between growth and scaling?

Growth is adding more, more people, more revenue, more offices. Scaling is doing that without your costs and complexity rising just as fast, so each new unit of size is more efficient, not less. A company can grow and de-scale at the same time: hiring fast while every decision gets slower and every customer gets worse service. The goal is growth where the structure keeps pace with the size.

When do we actually need more structure and process?

When the informal version starts failing, new people can't find who to ask, the same mistake recurs because nothing's written down, or decisions stall waiting on one overloaded person. Greiner's crises are the cue: each is a signal that the current operating style has hit its ceiling. The trap is adding process too early (which kills a small team's speed) or too late (after the chaos has already cost you good people).

Is Dunbar's number a hard rule we should reorganise around?

No, treat it as a rough signal, not a law. The number is an approximation with a wide range, and it's contested in the research. The useful idea is the direction it points: somewhere in the low hundreds, "everyone knows everyone" stops being true, and coordination that used to be free now needs deliberate design, clearer roles, smaller units, explicit interfaces between teams.

Should we standardise everything to scale, or keep teams autonomous?

Neither extreme. The skill, in Sutton and Rao's framing, is deciding which few things must be identical everywhere, usually safety, brand, core values, anything where inconsistency is dangerous, and then deliberately freeing the rest to adapt locally. Over-standardising crushes the local knowledge that made you good; under-standardising fragments the company. Make the list of non-negotiables short and explicit.

How do we scale without losing the culture that made us special?

Culture is mostly transmitted by the people who already hold it, so scaling too fast, hiring faster than you can onboard and acculturate, is the surest way to dilute it. Slowing the hiring rate, investing heavily in onboarding and ramp, and being explicit about the handful of values that don't flex (the "Catholic" core) protects the culture far more than any perks scheme. Growth dilutes culture by default; keeping it is an active design choice.

Related in the Toolkit

Scaling is where organisation design stops being theory. The crisis Greiner calls "delegation" is, in practice, a question of who holds which decision rights, and dividing past Dunbar-scale is really a choice about team topologies, spans and layers.

Where to go next