Org Chart Patterns for Teams Under 20 People
Three real reporting structures for small teams, drawn out, with the specific failure mode each one is prone to and how to tell which one actually fits.
A small team's reporting structure is often never deliberately chosen — it accretes, hire by hire, until one day someone asks "wait, who does this person actually report to?" and the honest answer takes a minute to work out. Naming the actual pattern in use, and its specific failure mode, makes it easier to notice when it's stopped fitting — and the two-pizza rule is a useful, concrete signal for when any single team or pod within these patterns has grown past the size it can coordinate informally.
Pattern one: flat
Everyone reports directly to one person — usually the founder or owner.
Where it works: Genuinely small — roughly under eight or ten people — where one person can maintain real, regular context on everyone's work without becoming a bottleneck.
Where it fails: Past that size, the person at the top becomes the constraint on every decision that needs their input, regardless of how minor. The specific failure mode is a queue — people waiting on the one person who's context-switching across everyone's work simultaneously, with less real attention for each report than a smaller flat team would get.
Pattern two: pod-based
Small, semi-autonomous groups (pods), each with its own lead, all coordinating through a lighter layer above.
Where it works: A team that's outgrown flat but doesn't yet need deep, formal management layers — pods give each small group real ownership and a direct line for day-to-day decisions, while the owner stays involved at the pod-lead level rather than every individual.
Where it fails: Pods that don't coordinate with each other can start optimizing locally in ways that conflict — two pods solving the same problem differently, or duplicating effort neither is aware of. This structure needs a deliberate cross-pod coordination habit or it quietly fragments into silos.
Pattern three: hub-and-spoke
A central operations or coordination function that every other function routes through for shared services (finance, HR-adjacent functions, tooling), while reporting lines for actual work stay separate.
Where it works: Teams with genuinely separate functions (say, a client-delivery team and a product team) that still need shared, consistent operational support — payroll, tooling, scheduling — without duplicating that function inside each team.
Where it fails: If the hub's authority is unclear — is it a service function people can ignore, or does it have real decision authority on shared matters — it becomes a source of friction rather than support. This structure needs explicit clarity on what the hub actually controls versus what it just facilitates.
Choosing between them honestly
The signal that a structure has stopped fitting is rarely subtle once named directly: a flat structure where the owner is visibly the bottleneck on decisions well below their actual necessary involvement; a pod structure where two pods are quietly duplicating work; a hub-and-spoke where nobody's sure whether the hub's guidance is a suggestion or a requirement. Each pattern's failure mode is specific enough to check for directly, rather than needing a vague sense that "something feels off" about how the team's currently organized.
The chart should match reality, not the other way around
If people are already informally routing real decisions to someone other than who an org chart says they report to, that's not a discipline problem to correct — it's a sign the chart is describing a structure that no longer matches how work actually happens. Updating the chart to reflect the real pattern, rather than insisting people follow a structure that's already been informally abandoned, keeps the chart useful as a description of reality rather than a fiction everyone quietly works around.
The short version
Flat, pod-based, and hub-and-spoke are three real, recognizable patterns for a small team's reporting structure, each with a specific, predictable failure mode rather than a vague sense of not working well. Naming which pattern is actually in use, and watching for that pattern's specific failure signal, makes it far easier to notice when the structure needs to change than waiting for a general feeling that something about the team's organization isn't quite right.
Frequently asked questions
Does a team under 20 people need a formal org chart?
A drawn-out chart isn't strictly necessary, but the underlying decision — who reports to whom, and why — needs to be genuinely clear even at this size. Ambiguity here doesn't disappear just because nobody wrote it down; it just surfaces later as confusion during a real disagreement.
What's the most common org chart mistake at a small company?
A flat structure held onto too long — everyone reporting to the founder past the point where that's actually sustainable, which quietly turns the founder into the bottleneck for every decision regardless of how small.
How often should a small team's reporting structure be revisited?
Whenever headcount roughly doubles, or when a specific manager is visibly stretched too thin — waiting for an annual review cycle to revisit structure often means running with a structure that stopped fitting months earlier.
Should reporting structure match the org chart exactly?
It should, and a gap between the two — someone informally going to a different person for real decisions than their chart shows — is itself a signal the chart needs updating to reflect reality, not that people need to be corrected.