Startups

Org design for startups: from 10 to 100 without the chaos

OrgTool Learn · 8 min read · Updated July 2026

Startups don't skip org design; they defer it with interest. Every early-stage company runs for a while on heroics and hallway context — correctly. But somewhere between 10 and 100 people, the informal machine starts dropping things, and the companies that handle the transition well aren't the ones that bureaucratize early; they're the ones that make a handful of small structural decisions deliberately instead of by accident. This is the short list.

The first chart is an ownership map

The earliest useful artifact isn't a hierarchy — it's an explicit answer to "who owns what," with exactly one name per thing. Most sub-20-person companies discover, the first time they write this down, that three important things are owned by nobody and two are owned by everybody, which is the same problem wearing a different shirt. Draw the ownership map before the reporting map; the reporting lines mostly fall out of it.

Watch the founder span

The most common early structure is every-single-person-reports-to-a-founder — workable at 8, failing silently at 15. The failure is invisible because founders absorb it: coordination becomes their nights and weekends, decision latency climbs, and the team reads the slowdown as strategy drift rather than as a span-of-control problem. Treat a founder span above ~10 as a structural fire, not a badge of flatness. (The general theory is in spans & layers — startups are its most extreme case study.)

Hire managers deliberately, not as currency

Two management-hiring failure modes account for most early structural debt: promoting your best IC to manager as a retention move (you lose your best IC and gain a reluctant manager), and title inflation as a negotiation move (a "VP" at 12 people who becomes a layer-justification problem at 60). The discipline: create management roles when coordination load demands them, staff them with people who want the actual job, and keep the title architecture boring for as long as possible.

Plan headcount as scenarios, not as a list

The startup hiring plan is usually a flat list in a spreadsheet: role, quarter, salary. What it can't answer: what the org looks like if the Series B slips a quarter, which three hires unblock the most, what the plan costs annualized with on-costs. That's scenario modeling — the same discipline big-company restructuring uses, pointed at growth instead of reduction. Keep a baseline (today), a plan-of-record, and a slip case, and make offers from the comparison, not the list.

Make vacancies first-class citizens

An open role is a structural fact, not an absence: it has a manager, a cost, a start date, and dependencies. Plans that model vacancies explicitly — drawn on the chart with dashed borders, counted in cost projections — stop the two classic early-stage surprises: the team that looks staffed on paper but is 30% holes, and the manager who discovers at offer time that three "approved" roles all report to them in the same quarter.

Grades before comp drifts

Nobody wants leveling frameworks at 15 people, and nobody survives their absence at 50: by then, ad-hoc offers have created a compensation archaeology that takes a painful repricing round to fix. The lightweight version costs one afternoon — a handful of grades with rough bands, applied to every offer from now on. It's not bureaucracy; it's pre-committing to fairness while it's still cheap. Startups that skip it meet the pay-equity conversation later, on harder terms.

Map the bus factor early

At startup scale, succession planning sounds absurd — until the one person who understands the deploy pipeline resigns. The five-minute version: for each critical function, note who else could cover it tomorrow. Where the answer is "no one," you've found your real organizational risk, and it rarely matches the org chart's idea of seniority. This is the smallest possible informal-org analysis, and it's worth doing from about 20 people onward.

Key takeaways

  • Draw the ownership map first; the reporting chart follows it.
  • Founder span over ~10 is a structural problem being absorbed as founder overwork.
  • Create management roles for coordination load — never as retention or negotiation currency.
  • Plan headcount as compared scenarios (baseline / plan / slip), with vacancies modeled explicitly.
  • Adopt lightweight grades before compensation drifts; map the bus factor before it drives.

Further reading

  • Horowitz, The Hard Thing About Hard Things (2014) — the chapters on hiring executives and scaling management remain the founder-side standard.
  • Grove, High Output Management (1983) — spans, one-on-ones, and managerial leverage from the operator's seat.
  • The startup-scaling literature from major venture firms on organizational debt — read for patterns, not prescriptions.
FAQ

Questions people ask

Educational content with named sources; statements about OrgTool restate claims verified against the current build (claims/learn.md).

When does a startup actually need an org chart?
The moment two people give conflicting answers to "who owns this?" — usually somewhere between 10 and 20 people. Before that, the chart is the founders' calendar. The useful early artifact isn't a hierarchy diagram; it's an explicit map of ownership: every important thing the company does, with exactly one accountable name on it.
When should we hire our first managers?
A workable rule of thumb: when a founder or lead is coordinating more than 8–10 people day-to-day, management has become a real job someone is already doing badly on the side. Promote or hire for it deliberately — and resist creating managers as a retention currency, which is how five-person companies end up with three layers by fifty.
Do startups need org design tools, or is a whiteboard fine?
A whiteboard is fine until the questions get consequential: what does this hiring plan cost annualized, what happens if this person leaves, which offer do we make first? Those are modeling questions, and the whiteboard answers none of them. A tool earns its place when scenarios, costs, and vacancies need to be compared rather than remembered — OrgTool's free tier (one org, up to 25 people) exists precisely for that stage.
Keep reading, or try it on a real org.
Every concept in this library is a working screen in the product — free for orgs up to 25 people.