How many people can one manager actually manage? The question sounds administrative. It is architectural. The answer determines the shape of the entire organisation — how many layers sit between the CEO and the front line, how fast information travels, how much distortion accumulates in transit, and whether decisions are made by people with context or people with titles.
Classical management theory — Lyndall Urwick in 1956, drawing on military command structures — settled on five to seven direct reports as the effective maximum. The reasoning was cognitive: a manager tracking five people can hold each person's context, priorities, blockers, and development needs in working memory. At eight, the tracking degrades. At twelve, the manager is scheduling one-on-ones they can't prepare for and reading status updates they can't act on. The manager becomes a router — passing information between people who could communicate directly if the hierarchy didn't exist.
Jeff Bezos rejected this framing entirely. His "two-pizza team" rule — no team should be larger than two pizzas can feed, roughly six to ten people — was not about span of control in the classical sense. It was about eliminating coordination costs at the team level so the manager's job shifted from information routing to decision-making. Amazon's insight: the problem isn't that managers can't handle more reports. The problem is that large teams generate exponential communication overhead. A team of six has fifteen communication paths. A team of twelve has sixty-six. A team of twenty has one hundred and ninety. The manager becomes the bottleneck not because they're incompetent but because the mathematics of group communication are unforgiving.
Google ran the opposite experiment. Under Larry Page's return as CEO in 2011, some engineering VPs managed twenty or more direct reports. The logic: wider spans force managers to delegate deeply, prevent micromanagement, and push decision-making authority down to the people with the most context. Google's Project Oxygen research found that the best managers coached, communicated vision, and removed blockers — functions that don't require narrow spans. The implicit assumption: if you hire people who don't need close supervision, you can widen the span dramatically.
Both approaches work. Neither is universally correct. The variable that determines which is right is the nature of the work. Routine, well-defined tasks tolerate wide spans. The manager of a twenty-person customer support team with documented processes and clear escalation paths doesn't need narrow oversight — the process itself provides the structure. Novel, ambiguous, high-judgment work requires narrow spans. The VP of product managing three product leads who are each making bet-the-company decisions about market direction needs to be deeply embedded in each person's context. The span must match the cognitive load of supervision, not an arbitrary number from a management textbook.
Every additional management layer between the top and the bottom adds latency and distortion. A directive from the CEO passes through four layers of management and arrives at the front line as a different directive — not because anyone intentionally changed it, but because each layer filters, interprets, and rephrases based on their own context and incentives. Bezos's observation cuts to the core: "Communication is a sign of dysfunction. It means people aren't working together in a close, organic way." The ideal organisation doesn't need to communicate across layers because the layers don't exist — or because the spans are designed so that each layer adds decision-making value rather than translation overhead.
Section 2
How to See It
Span of control manifests in the speed and fidelity of decision-making. When decisions are fast and reflect ground-level reality, the span is correctly calibrated. When decisions are slow and detached from operational context, the span is either too wide (the manager lacks bandwidth to synthesise information) or too narrow (too many layers between decision-maker and information source).
The clearest diagnostic: track how many layers a piece of customer feedback must travel before it reaches someone who can act on it. In a well-designed organisation, the answer is one or two. In a span-of-control failure, the answer is five or more — and by the time the feedback arrives, it has been abstracted into a dashboard metric that strips out the urgency and nuance of the original signal.
Startups & Growth-Stage Companies
You're seeing Span of Control at work when a fifty-person startup promotes its best engineer to "Director of Engineering" managing twelve engineers, and within six months that former engineer is spending 100% of their time in one-on-ones and status meetings. They've written zero code. They can't name the top three technical risks in the current sprint. The span exceeded the cognitive carrying capacity for the type of work — high-ambiguity engineering decisions that require deep context — and the result is a manager who manages process instead of outcomes.
Enterprise & Corporate
You're seeing Span of Control at work when a large company has seven layers of management between the CEO and the customer-facing employee. Each layer exists because the layer above it had too many direct reports, so a new layer was inserted to "help manage." The result: a decision that should take a day takes three weeks. The CEO's strategic intent arrives at the front line as an unrecognisable derivative of the original message, filtered through seven interpretive lenses.
Product & Engineering
You're seeing Span of Control at work when Amazon structures AWS as hundreds of small, autonomous teams — each owning a single service, each with a single-threaded leader who controls inputs and outputs. The narrow team structure eliminates the coordination overhead that would cripple a traditional engineering organisation building the same product portfolio. Each team's leader has a span of six to eight. The organisational complexity is handled through API contracts between teams, not through management layers above them.
Leadership & People
You're seeing Span of Control at work when a VP with twenty direct reports after a post-acquisition integration cannot provide meaningful feedback to anyone. Performance reviews become copy-paste exercises. One-on-ones get cancelled or reduced to fifteen minutes. The VP's calendar is wall-to-wall meetings, every one of them shallow. The span is technically functional — no one is being ignored entirely — but the quality of management has degraded to the point where the VP is a reporting node, not a leader.
Section 3
How to Use It
Decision filter
"When I evaluate whether a span is right, I ask one question: can this manager describe each direct report's top three priorities and biggest blocker without checking a document? If they can, the span works. If they can't, it's too wide — or the work doesn't warrant that level of oversight, and the manager is doing work that shouldn't exist."
As a founder
Design spans deliberately at each growth stage rather than letting them emerge by accident. At ten people, flat is fine — everyone reports to you, and the communication overhead is manageable. At thirty, you need to introduce a management layer, but keep spans narrow (four to six) because the work is still ambiguous and high-judgment. At one hundred, differentiate: widen spans in operational functions where the work is well-defined, narrow spans in strategic functions where each decision carries disproportionate risk. The worst pattern is uniform span — treating engineering, sales, operations, and design as if they all require the same supervisory density.
Resist the reflex to solve every coordination problem by adding a management layer. Each layer adds latency, dilutes accountability, and creates a new information bottleneck. Before adding a layer, ask: can I solve this with better tooling, clearer ownership, or direct communication between the people doing the work? If yes, you've avoided the single most expensive organisational decision a founder makes — adding a layer that, once installed, is nearly impossible to remove.
As an investor
Span of control is a due diligence proxy for organisational health. During diligence, ask the CEO to draw the org chart and count the layers. A Series B company with five layers of management is carrying structural overhead that a competitor with three layers is not. Count the direct reports for each executive. A CTO with fifteen direct reports in a company doing novel R&D is not managing — they're triaging. A head of sales with four direct reports managing fifty reps through two layers is appropriately leveraged for a function with well-defined processes.
The ratio that matters most: layers-to-total-headcount. A one-hundred-person company should have two to three layers. A five-hundred-person company should have three to four. Companies that exceed this ratio are paying a management tax — each unnecessary layer consumes salary, slows decisions, and creates the information distortion that disconnects leadership from reality.
As a decision-maker
Match the span to the cognitive load of the work, not to a fixed number. A manager overseeing twenty customer support agents following scripted processes can be effective — the process itself is the management layer. A manager overseeing four product leads making strategic bets on new markets needs to be deeply immersed in each person's context. The first span is operationally wide and cognitively light. The second is operationally narrow and cognitively dense. Both are correct. The error is applying the same span logic to both.
When restructuring, use span of control as the lever rather than headcount. Most organisations that feel bloated don't have too many people — they have too many layers, each with too few direct reports. Collapsing a layer and widening the span of the remaining managers often produces better outcomes than layoffs: fewer information bottlenecks, faster decisions, higher accountability, and managers who actually manage rather than forward emails.
Common misapplication: Treating span of control as a fixed number — insisting that every manager should have exactly seven direct reports regardless of context. The right span for a VP of Sales managing regional directors with established playbooks is twelve to fifteen. The right span for a VP of Research managing scientists working on novel problems is three to five. The number is determined by the supervisory load per report, not by a universal constant.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The founders who get span of control right share a conviction: organisational structure is a product, not an afterthought. They design it with the same rigour they apply to their software architecture or their product roadmap — and they iterate on it as aggressively.
Bezos built Amazon's organisational architecture around the principle that coordination overhead is the enemy of speed. The two-pizza team rule was the structural expression: keep teams small enough that they don't need formal coordination mechanisms. Each team owns a service. Each service communicates with other services through well-defined APIs. The manager's span is constrained not by a rule but by the size of the team — six to ten people who collectively own a single output.
The genius was that Bezos solved the span-of-control problem at two levels simultaneously. At the team level, narrow spans ensured deep context. At the organisational level, the API-contract model between teams eliminated the need for management layers whose sole purpose was coordination. A traditional organisation of ten thousand engineers might have eight layers of management. Amazon structured the same engineering force as hundreds of autonomous teams with three to four layers — each team operating as a startup, each manager operating as a founder. The coordination happened through technical interfaces, not human ones. Bezos eliminated the management layers by making them structurally unnecessary.
The constraint was real and deliberate. When a team grew beyond two-pizza size, it split — regardless of whether the split was "efficient" from a resource perspective. Bezos accepted local inefficiency (duplicate tooling, redundant infrastructure) in exchange for the global efficiency of small, fast, autonomous teams. The trade-off reflected a deep insight about span of control: the cost of one manager trying to hold fifteen engineers' context is always higher than the cost of two managers with redundant infrastructure.
Lütke approaches span of control as a programmer would approach system architecture — by minimising dependencies and maximising autonomy. Shopify's team structure intentionally keeps spans narrow at the execution level. Small, autonomous pods own specific product surfaces. The pod lead manages five to seven people. The constraint is enforced through culture, not policy: when a pod grows, it splits.
Lütke's 2023 restructuring was partly a span-of-control correction. Years of growth had widened spans at the middle-management level and deepened the layer count. Lütke eliminated layers, collapsed reporting structures, and reset team sizes — not to reduce headcount as a primary goal, but to restore the span density that had eroded as the organisation grew. His internal communication was direct: the company had accumulated structural overhead that was slowing execution. The restructuring removed management layers that had become translation layers — nodes in the hierarchy that passed information between the levels above and below without adding decision-making value.
The underlying philosophy: every management layer must justify its existence by making decisions that the layer below cannot make on its own. A layer that exists only to aggregate information and pass it upward is organisational debt, not organisational structure. Lütke reviews Shopify's span ratios regularly, treating them as system metrics rather than HR artifacts. When the ratio drifts — too many layers, too few direct reports per manager — he treats it the way a site reliability engineer treats latency: as a structural problem that degrades performance until fixed.
Section 6
Visual Explanation
Section 7
Connected Models
Span of control is the hinge that connects individual management capacity to organisational architecture. Get it wrong and every other structural decision — team design, communication flow, decision authority — inherits the distortion. The models below map how span interacts with the cognitive, structural, and strategic forces that determine whether an organisation moves fast or drowns in its own coordination costs.
Reinforces
Dunbar's Number
Dunbar's Number sets the cognitive ceiling — approximately 150 stable relationships — that constrains how large a group can coordinate through informal, trust-based interaction. Span of control is the organisational mechanism for operating below that ceiling within each management unit. A team of six sits comfortably within every person's cognitive capacity for tracking relationships and context. A team of thirty requires formal processes to substitute for the informal coordination that Dunbar's limit no longer supports. The reinforcement: Dunbar's Number explains why wide spans degrade quality (the manager exceeds their cognitive limit for relational tracking), and span of control provides the structural tool for staying within Dunbar's boundaries at each level of the hierarchy.
Reinforces
Conway's Law
Conway's Law predicts that the organisation's communication structure will be mirrored in its technical architecture. Span of control directly shapes that communication structure. Narrow spans with deep hierarchies produce narrow, vertically integrated systems. Wide spans with flat structures produce broad, loosely coupled systems. Amazon's two-pizza teams produce microservices architectures. Apple's functional organisation under tight spans produces tightly integrated products. The reinforcement is bidirectional: the span determines the communication structure, the communication structure determines the system architecture, and the system architecture then constrains future organisational design — because restructuring the organisation means restructuring the software, and vice versa.
Reinforces
[Team of Teams](/mental-models/team-of-teams)
General Stanley McChrystal's Team of Teams framework addresses the coordination problem that arises when narrow spans produce many small teams that must work together. The solution: connect the teams through shared consciousness (common operating picture) and empowered execution (decision authority pushed to the team level). Span of control determines the size and number of teams. Team of Teams determines how those teams coordinate. The reinforcement: small teams with narrow spans are necessary for speed and autonomy, but they create a coordination challenge that Team of Teams solves through transparency and trust rather than through additional management layers.
Section 8
One Key Quote
"Communication is a sign of dysfunction. It means people aren't working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more."
— Jeff Bezos, internal communication to Amazon leadership
The quote inverts the conventional wisdom that better communication is always the answer. Bezos's point is structural: if two teams need to communicate heavily, the organisational design is wrong. Either the teams should be merged (bringing the work within a single span), the interface between them should be formalised into an API contract that eliminates the need for ongoing negotiation, or the work should be re-partitioned so that each team can operate autonomously.
This is span of control elevated from a management tactic to an architectural principle. The goal isn't to help managers communicate better across wide spans. The goal is to design the organisation so that the communication overhead never arises — because each team is small enough to coordinate internally, and the interfaces between teams are clean enough that cross-team coordination happens through contracts, not conversations. The best management layer is the one that doesn't need to exist.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Span of control is the most under-discussed structural decision in startups and the most over-complicated one in enterprises. Startups ignore it entirely — the founder manages everyone until one day they manage no one effectively. Enterprises turn it into an HR policy — "all directors shall have six to eight direct reports" — that treats a context-dependent architectural decision as a uniform rule.
The pattern I see most: accidental spans. No one decided that the VP of Engineering should have fourteen direct reports. The company grew. People were hired. Reorgs were deferred. The VP's span expanded one report at a time until they were spending forty hours a week in one-on-ones and zero hours thinking about engineering strategy. The span wasn't designed. It emerged. And by the time it was noticed, the VP had built relationships with all fourteen reports that made restructuring politically expensive.
The diagnostic I use: ask the manager to describe each report's top blocker. Not from memory — that's too easy to fake. In real time, without preparation. A manager with a well-calibrated span can do this for every report. A manager with an overloaded span can do it for three or four. The rest get generic answers — "they're doing great" or "they have some challenges" — that reveal zero actual knowledge of what's happening. A manager who can't describe their reports' blockers isn't managing. They're maintaining the appearance of management.
The layer question matters more than the span question. Most organisational dysfunction attributed to span of control is actually a layer problem. The span per manager might be fine — six to eight, well within cognitive limits. But the organisation has six layers, and each layer adds a week to every decision cycle and a twenty-percent distortion to every piece of information. The correct intervention is not to adjust spans but to eliminate layers — collapsing two layers into one, widening the remaining manager's span, and accepting that the wider span requires less managerial involvement (which is often the right outcome for well-defined work).
Amazon's approach is the most intellectually honest. Bezos didn't try to find the optimal span. He redesigned the organisation so that span of control was a secondary concern. Two-pizza teams capped at ten people. API contracts between teams instead of management layers above them. Single-threaded leaders with full ownership. The span question — "how many reports can one person manage?" — became irrelevant because the organisational architecture eliminated the conditions under which the question matters. You don't need to optimise a manager's span if you've designed the system so that each manager's scope is inherently bounded.
Section 10
Test Yourself
Span of control gets invoked whenever someone feels their manager is too busy or their organisation is too slow. The scenarios below test whether you can diagnose when the span is genuinely the problem — versus when the real issue is layer depth, work type, or managerial capability.
Is Span of Control the right diagnosis here?
Scenario 1
A 200-person engineering organisation has four layers: CTO → 4 VPs → 16 Directors → 48 Managers → individual contributors. Each VP manages 4 Directors. Each Director manages 3 Managers. Each Manager manages 6-8 engineers. The CTO complains that decisions take too long — product changes that should ship in a week take three weeks because every decision routes through all four layers for approval.
Scenario 2
A startup's VP of Sales manages 18 account executives directly. There are no sales managers between the VP and the reps. The VP insists this flat structure 'keeps them close to the customer.' In practice, the VP holds thirty-minute one-on-ones with each rep every two weeks, reviews pipeline weekly, and is available for deal escalations. The sales team consistently hits quota, rep turnover is below industry average, and the VP still has time for strategic planning.
Scenario 3
A fast-growing AI startup has a VP of Research managing 12 PhD researchers, each working on a different research direction — from reinforcement learning to computer vision to natural language processing. The VP reviews each researcher's progress monthly in a 45-minute meeting. Three promising research threads have stalled because the VP didn't catch early signs of dead-end approaches. Two researchers have quietly pivoted to duplicative work because no one noticed the overlap.
Section 11
Top Resources
The literature on span of control spans nearly a century — from military command theory through mid-century management science to modern organisational design. The concept has been refined but not fundamentally changed since Urwick's original formulation. What has changed is the context: remote work, software-mediated coordination, and the shift from industrial to knowledge work have altered the boundary conditions without invalidating the core dynamics.
Grove's treatment of span of control is the most operationally useful in the management literature. He frames it not as a fixed number but as a function of "task-relevant maturity" — the more experienced and autonomous the report, the wider the span can be. His guidance: a manager should spend roughly half a day per week per direct report. At six reports, that's three days — leaving two for the manager's own contribution. At twelve, the math breaks. Grove's framework is the bridge between classical theory and modern practice.
McChrystal solved the span-of-control problem at the highest stakes: coordinating thousands of special operations troops and intelligence analysts against a decentralised enemy. His solution — shared consciousness and empowered execution — kept team sizes small (narrow spans) while enabling cross-team coordination without adding management layers. The book's relevance to corporate organisations is direct: the structural challenge of coordinating many small autonomous teams is identical whether the teams are military units or engineering squads.
Kegan and Lahey's research on developmental organisations addresses a dimension of span that most management texts ignore: the developmental load. A manager's span is constrained not just by the coordination load (how many tasks to track) but by the developmental load (how much growth each report requires). In organisations that treat employee development as a core function, the effective span is narrower because each managerial relationship carries a higher investment obligation.
The most detailed insider account of how Amazon operationalised span of control through the two-pizza team, single-threaded leadership, and the "fitness function" for team design. Bryar and Carr describe how Bezos deliberately constrained team sizes and management layers — and the structural mechanisms (API mandates, written narratives, bar raisers) that made wide organisational spans work without wide managerial spans. Essential for understanding how span of control works in practice at a company that treats organisational design as a competitive weapon.
Brooks's law — "adding manpower to a late software project makes it later" — is the engineering corollary of span-of-control theory. The mechanism is identical: each additional person increases the number of communication paths, and the coordination overhead eventually exceeds the productive contribution. Brooks quantified what Graicunas theorised: the cost of coordination grows faster than the benefit of additional capacity. The book remains the most cited proof that the mathematics of group communication impose hard limits on effective team size — and by extension, on effective spans of control.
Leaders who apply this model
Playbooks and public thinking from people closely associated with this idea.
Span of Control — The same 64 people organised under narrow spans (left) vs wide spans (right). Narrow spans produce more layers, more management overhead, and longer communication chains. Wide spans produce fewer layers but higher cognitive load per manager. The optimal span depends on the nature of the work.
Tension
Organisational Debt
Organisational debt accumulates when structural decisions — including span of control — are deferred rather than made. A company that doubles headcount without adjusting spans or adding layers is accumulating debt: managers are overloaded, decisions slow, information distorts. The tension: adding management layers to fix overloaded spans creates its own debt (more overhead, more latency, more translation loss). The resolution requires deliberate span design at each growth stage — widening spans where the work has become routine, narrowing spans where the work has become more complex, and eliminating layers that add latency without adding decision value.
Leads-to
Two-Pizza Team
The two-pizza team is the architectural outcome of optimising span of control for speed and autonomy. Bezos's rule — no team larger than two pizzas can feed — sets the span at six to ten by constraining team size. The team lead's span is determined by the team's size, not by a management formula. The lead manages five to eight people because that's how many people fit in the team, and the team is sized for communication efficiency, not organisational convention. Two-pizza teams are what you get when you solve for coordination cost minimisation rather than management span maximisation.
Leads-to
Coordination Costs
Every report added to a span increases the coordination cost borne by the manager and the team. Graicunas's formula quantifies this: the number of potential relationships grows combinatorially with team size. At four reports, there are forty-four potential relationships. At eight, there are one thousand and eighty. Coordination costs are the mechanism through which span of control translates into organisational speed. The wider the span, the higher the coordination cost. The higher the coordination cost, the more time is spent on alignment and the less time is spent on execution. The lead-to relationship: span of control is the input, coordination cost is the output, and the relationship is nonlinear.
The mistake investors make: confusing flat with fast. A flat organisation with wide spans is fast only if the work at each node is well-defined and the coordination between nodes is minimal. A flat organisation where every node is doing novel, ambiguous work and needs heavy coordination is not fast — it's chaotic. The leanest org chart is not always the fastest organisation. Sometimes the right answer is more layers, narrower spans, and deeper managerial investment — especially in functions where the cost of a bad decision exceeds the cost of a slow one.
My operating rule: the span should match the cost of a mistake. When mistakes are cheap and reversible (consumer feature experiments, marketing campaigns, internal tooling), widen the span and push autonomy down. When mistakes are expensive and irreversible (infrastructure architecture, pricing strategy, regulatory compliance), narrow the span and invest in deep managerial context. The span is a risk-management tool, not an efficiency metric.
