पाठशाला Pathshala · संचालन Sanchālan, Operations · Lesson 23 · Scale

Scaling the operating system from 50 to 200 people

At fifty people the founder is the operating system. At two hundred that has to be written down: who decides what, when the company plans, how news travels and which meetings carry the load.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Aerial view of a multi-level highway interchange in South Jakarta. — Photograph: Tom Fisk · Pexels

At fifty people a founder still knows everyone’s name, hears most problems the day they happen and makes most of the important decisions in a corridor. At two hundred none of that is true, and a company that has not replaced those habits with a written system finds that decisions simply stop getting made whenever the founder is travelling.

This lesson is about that replacement. It covers what breaks between fifty and two hundred, the arithmetic of layers, how to write down decision rights, the planning calendar, the cadence of meetings at this size, how information should travel, and the quarterly review that keeps the system honest. It follows the [founder’s operating cadence](/library/founders-operating-cadence), which is the system for a company of ten; this is what that system becomes.

What breaks between fifty and two hundred

Molly Graham, who scaled teams at Google, Facebook and Quip, describes the stages in First Round Review’s Give Away Your Legos. Between thirty and fifty people a company goes, in her words, from being a family to being a company: communication gets harder and the place stops feeling like one team. Between fifty and two hundred the culture and habits take root, and the people hired then set the pattern, because the first hundred people hired will define the next two hundred. Past two hundred the habits are largely set and much harder to change. The window to design the operating system is the one this lesson covers.

Three things break in that window, and they break in the same order in most companies. Information first: the founder can no longer tell everyone what matters, so people learn it from whoever they sit near, and different teams act on different versions of the plan. Decisions second: every cross-team question escalates to the founder, who becomes the queue, and the queue grows faster than the company. Planning third: priorities set in one quarterly meeting of the founding team no longer reach the front line, and teams fill the gap with their own.

The arithmetic is unkind. The number of possible pairs of people in a company of n is n(n − 1) ÷ 2. At fifty that is 1,225; at two hundred it is 19,900, sixteen times as many for four times the people. Conversations that used to carry the company cannot scale with that. Structure, writing and fixed rhythms have to carry what conversation no longer can.

Layers and spans

The first structural change is a layer of managers between the founder and the work, and the question is how many. It depends on two numbers: head count and span of control, the number of people each manager leads directly. GitLab’s public handbook sets a span of about seven, ranging from four to ten, and asks managers to size their teams for where the organisation will be in six months rather than where it is today.

Aerial view of a stone stepwell with flights of stairs descending to green water. — A stepwell reaches the water in flights, each one short enough to climb. Layers in a company work the same way when each span stays near seven. Photograph: AXP Photography · Pexels

Move the sliders. At 120 people and a span of seven there are two management layers between the founder and the front line, and about twenty people managing others. Drop the span to four and a third layer appears, the number of managers nearly doubles, and every decision that has to travel up and down now passes through one more pair of hands. Raise it to ten and the managers fall to about fifteen, at the cost of managers who can no longer give each report real attention. A company at this size should keep spans near seven and add a layer only when the alternative is spans above ten.

Writing down who decides

The fix for the decision queue is not a faster founder. It is a written list of who decides what. Start from the decisions that reached the founder in the last month, and sort each into one of three columns: decided by the team that owns it, decided by the leadership team together, decided by the founder. Name one owner for every decision, a single person, never a committee. Publish the list and update it every quarter.

Jeff Bezos’s 2016 letter to shareholders gives the two rules that make the list work. Most decisions are reversible, two-way doors, and can be made quickly by the people closest to them with a light process; only the irreversible ones need the weight of the top of the company. And most decisions should be made with about seventy per cent of the information one wishes one had, because waiting for ninety per cent is usually being slow. When a team disagrees with a call, the phrase he recommends is disagree and commit: argue it once, then carry it out fully. The [lesson on reversible decisions](/library/decisions-reversible-irreversible-how-fast) sets out how to tell the two kinds apart.

Planning on one calendar

At fifty people a founding team can set three company objectives in a morning and everyone hears them by lunch. At two hundred planning has to be a calendar that every team runs on. Annually, the leadership team sets the [annual operating plan](/library/forecasting-and-annual-operating-plan): revenue, burn, head count by team and three to five company priorities. Quarterly, each team writes a one-page plan with its objectives, showing which company priority each one serves, and the leadership team reviews them side by side in a single session to find the conflicts and the gaps. The [OKR lesson](/library/okrs-for-team-of-ten) sets out the mechanics; what changes at this size is that the plans ladder, and that someone reads them all together.

The calendar is the point. Planning happens in the same weeks every quarter, the templates are the same, and a team that misses its window plans next quarter. A company where planning happens whenever the founder has time is a company where the plan is whatever the founder said last.

At fifty the founder is the operating system. At two hundred the operating system has to work when the founder is on a plane.

The cadence at two hundred

The rituals of the ten-person company still exist, but each has moved down a layer and a new one has appeared above it. Weekly: the leadership team, the founder and the six to eight heads of function, meets for ninety minutes on the company’s one-page metrics and on decisions that need more than one function; each head runs the same weekly review with their own team the day before. Monthly: a business review for each function, an hour each, with the founder or COO, on that function’s numbers, its plan and its risks, staggered across the month so the founder holds one or two a week. Monthly: an all-hands of forty-five minutes, where the founder covers the numbers, the decisions made and why, and takes questions in the open. Quarterly: the planning session and an offsite for the leadership team.

Every one of these meetings has a written pre-read sent a day before, an owner and a record of the decisions made. The [meetings lesson](/library/meetings-that-earn-their-time) applies with more force here: a weekly meeting of eight senior people costs a working day of the company’s most expensive time, and should end with decisions or not happen.

How information travels

At this size the default has to become writing. Decisions are recorded where everyone can find them, in the format the [writing culture lesson](/library/writing-culture-decisions-in-documents) describes. The founder sends a weekly note to the whole company: what happened, what was decided, what is coming, in under five hundred words, on the same day every week. Heads of function send a shorter version to their teams after the leadership meeting, so the front line hears decisions within a day of their being made rather than a month later through rumour.

Graham’s other advice belongs here too. The people who joined early held many pieces of the company, and as specialists arrive they must hand those pieces over and take on larger ones. Some will resist, because giving away part of a job feels like losing it. Say plainly, in the weekly note and in one-on-ones, that handing work to new people is the job, not a demotion.

The quarterly operating-system review

Once a quarter, in the planning week, the leadership team spends two hours on the system itself rather than the business. Spans: list every manager and their number of direct reports; anyone above ten or below four gets a change. Decisions: count the decisions that escalated to the founder in the quarter; each one either moves to a team’s list or is confirmed as the founder’s. Meetings: list every recurring meeting with more than five people, with its owner and its cost in hours; cancel any without a decision record. Information: ask five people at the front line what the company’s three priorities are; if the answers differ, the communication has failed, whatever was sent. Write the changes down, publish them in the next weekly note, and check them at the next review.

The figure is arithmetic, not a design; real organisations have specialists with no reports and managers with mixed teams. The spans and meeting lengths above are starting points to be tested against your own company.