Reorganisations usually move boxes around without changing how anything actually gets done. The shape that matters is not the reporting tree, it is whether a team can take a piece of work from idea to live without waiting on five other teams. Get the team types, the spans and the layers right and work flows; get them wrong and you get hand-offs, queues, and managers managing managers.

The quick version

  • Team topologies is a way of designing teams around the flow of work rather than around functions. It names four team types and three ways they should interact, so you choose team shapes on purpose instead of by accident.
  • Span of control is how many people report directly to one manager. Too narrow and you get over-management and tall hierarchies; too wide and the manager can't actually support anyone.
  • Layers are the rungs between the chief executive and the front line. Each extra layer slows decisions and dilutes information, so leaner is usually better, but only up to the point where managers are still able to do their job.
  • The three connect: wider spans mean fewer layers, and team-of-teams design (topologies) tells you which teams should be wide, flat and autonomous, and which need closer support.

The idea in depth: shape teams around flow

The most influential recent answer to "how should we organise teams?" is Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais (Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution). It grew out of software delivery, but the logic travels well beyond it. The core move is to stop organising purely by function or project and instead define four fundamental team types: stream-aligned teams that own a continuous flow of work for a product or customer journey; platform teams that provide internal services so the stream-aligned teams don't reinvent them; enabling teams that help others build a missing capability and then step back; and complicated-subsystem teams that own a part needing rare, deep expertise.

Those teams connect through just three interaction modes: collaboration (close, deliberately time-limited because it is high-effort), X-as-a-service (one team consumes another's service through a clean interface), and facilitating (an enabling team coaches another for a while). The discipline is naming, on purpose, which mode each pair of teams is in, and noticing when "temporary collaboration" has quietly become permanent.

flowchart LR
  S(["Stream-aligned
owns flow end-to-end"])
  P(["Platform
internal self-service"])
  E(["Enabling
coaches, then leaves"])
  C(["Complicated-subsystem
deep specialist part"])
  P -. "X-as-a-service" .-> S
  E -. "facilitating" .-> S
  C -. "X-as-a-service" .-> S
The four team types, with the stream-aligned team at the centre and the others reducing its load. Leaders Loop

Underneath this sits one governing constraint: cognitive load. A team can only hold so much in its collective head, so each team's scope should be bounded to what it can reasonably understand and own. Skelton and Pais lean on the well-known anthropological work associated with Robin Dunbar, that humans sustain close working trust in groups of roughly five, deeper trust up to around fifteen, and so on, to argue teams should stay small (often five to eight, rarely beyond about fifteen) and grow by splitting rather than swelling. The practical upshot: when a team feels permanently overloaded, don't add three more people to the same team. Carve off a clear slice of the work into a new, well-bounded team, and give the original team a clean interface to it.

This is also where Conway's Law earns its place. In 1968 the computer scientist Melvin Conway observed that "organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations" ("How Do Committees Invent?", Datamation, April 1968). Put plainly: your product ends up shaped like your org chart. Team Topologies turns this from a warning into a tool, the "inverse Conway manoeuvre", by designing the team boundaries you want the system to have. One honest caveat is worth stating plainly: the four-types model is a practitioner framework, not a peer-reviewed finding. It is clear and widely adopted, but its evidence base is case studies and experience reports, not controlled trials. Treat it as a vocabulary for better conversations about boundaries, not as proof that any one shape outperforms another.

How wide should one manager's reach be? Span of control

The oldest of the three ideas is span of control, the number of people reporting to a single manager. The argument that wider is not free was made mathematically by V. A. Graicunas in a 1933 paper (later reprinted in Gulick and Urwick's Papers on the Science of Administration, 1937). His insight was that a manager doesn't just hold relationships with each report individually; they also have to manage the relationships between reports and with every subgroup. Those cross-relationships multiply far faster than the headcount, which is why Graicunas concluded the workable number of direct reports was small, around four to six (see Fred Nickols' careful reconstruction, "The Span of Control and the Formulas of V. A. Graicunas").

Modern practice is more generous, because not all work is equally interdependent. Bain & Company's organisation research, drawn from a database of well over a hundred global companies, reports that the average manager has six to seven direct reports, while best-in-class organisations run average spans of ten to fifteen ("Streamlining spans and layers," Bain & Company). The reconciliation is the important part: the right span depends on the work, not a universal magic number. Bain notes that skills-based roles, engineers, brand managers, people who need real coaching, sit comfortably around six to eight, while standardised task-based roles like call-centre or shop-floor supervision can run to fifteen or more.

A narrow span isn't safe management; it's often just a manager who has too little to do, propping up a layer the organisation doesn't need.

So in practice: don't set one span target for the whole company. Look at each team's work. Where the work is standardised and the people are experienced, widen the span deliberately, fewer managers, more autonomy. Where people genuinely need coaching, keep it tight and resist the temptation to "flatten" them into neglect. The failure mode to watch for is a manager with two or three reports: that is rarely careful stewardship and usually a symptom of an extra layer that exists to give someone a title.

How flat is too flat? Layers

Spans and layers are two ends of the same lever. Widen spans and you need fewer layers, the rungs between the chief executive and the front line, because each manager covers more ground. Bain's data puts the average organisation at eight to nine layers, while best-in-class companies operate with no more than seven, even at large scale. Every extra layer is a place where a decision waits for sign-off and where information is summarised, softened and slowed on its way up. De-layering is the classic remedy for a sluggish organisation, and the gains are real, but Bain is blunt that it backfires when done by blunt headcount target rather than by looking at what each layer is actually for.

flowchart TD
  A(["Narrow spans → tall org
~6 reports, 8–9 layers"]) --> B{"Is each layer
doing real work?"}
  B -->|"No, title-only layers"| C(["Remove the layer,
widen the span above"])
  B -->|"Yes, coaching, judgement"| D(["Keep it,
match span to the work"])
  C --> E(["Flatter org → faster decisions
~10–15 reports, ≤7 layers"])
  D --> E
The spans–layers trade-off: wider spans let you remove layers, but only the layers that aren't doing real work. Leaders Loop

Here is where the three ideas lock together. Topologies tells you which teams should be flat and autonomous (a mature stream-aligned team consuming a platform as a service can be wide with few layers) and which need closer support (an enabling team coaching novices needs a tighter span). Span of control tells you how wide each manager's reach should be given that work. Layers fall out of those two choices. The sequence matters here: before you announce a "flatter structure," map your actual spans and layers team by team, then ask of every thin layer, "what decision dies if this rung disappears?" If nothing dies, the rung is overhead. And flatter is not free either. Remove a layer and the surviving managers inherit wider spans, if you don't also reduce what they're expected to do, you've moved the bottleneck, not removed it.

A worked example

Take a 60-person product organisation, call it Harbour. (Illustrative figures throughout; this is a teaching example, not a real company.) On paper Harbour is "lean." In practice every feature needs the mobile team, the API team and a separate "integrations" team to coordinate, and a release waits behind three hand-offs. The org chart shows a head of engineering, four "team leads" with three or four engineers each, and two of those leads also reporting through a "delivery manager" who has just two reports.

Read through the toolkit: the delivery manager with two reports is a title-only layer, nothing decides there that the leads couldn't. Remove it, and the head of engineering's span widens from four to a healthy six. Now the topology problem: the "integrations" team is a hand-off in the middle of every flow. In Team Topologies terms, integrations shouldn't be a team work passes through; it should be a platform capability the product teams consume as a service. Harbour reshapes two cross-functional stream-aligned teams that each own a customer journey end-to-end, backed by a small platform team exposing integrations through a clean interface. Releases stop queuing because no stream-aligned team waits on another.

The result is not "more managers" or "fewer" as a slogan, it is the right shape: one fewer layer, spans matched to the work (wider for the autonomous stream teams, tighter for a small enabling pairing helping a new hire), and the chronic hand-off turned into a self-service interface. Notice the order: Harbour didn't start by cutting headcount. It started by asking where work got stuck, and let spans and layers follow from the flow.

Frequently asked questions

What's the difference between team topologies and a normal org chart?

An org chart shows reporting lines, who answers to whom. Team topologies describes how teams are shaped around work and how they interact to deliver it. The same reporting lines can produce very different flow, depending on whether teams own work end-to-end or pass it between each other. Topologies is the design question the org chart skips.

Is there a "correct" span of control?

No single number, and anyone who quotes one is overselling it. Graicunas argued for a small span because relationships multiply faster than headcount; Bain's modern data shows best-in-class average spans of ten to fifteen. The reconciliation: span should match the work, tight where people need coaching, wide where the work is standardised and the people are experienced.

Isn't flatter always better?

Flatter usually speeds decisions and cuts cost, which is why de-layering is so common. But removing a layer widens the spans above it; if you don't also reduce what those managers carry, you've just relocated the bottleneck. Flat works when the teams below are genuinely autonomous, and fails when it leaves stretched managers unable to support anyone.

What is cognitive load and why does it limit team size?

Cognitive load is the total a team can reasonably hold in its collective head, the systems it owns, the context it tracks, the relationships it maintains. Team Topologies argues you should bound each team's scope to fit that limit and grow by splitting rather than swelling, drawing on Dunbar-style research that trust degrades as groups get large. A permanently overloaded team usually signals a wrong boundary, not a need for more people.

How does Conway's Law affect how we should organise?

Conway's Law says systems end up mirroring the communication structure of the organisation that builds them, so you can't bolt a clean architecture onto a tangled org; the org wins. Design the team boundaries you want the system to have (the "inverse Conway manoeuvre"), rather than drawing teams first and hoping the architecture cooperates.

Related in the Toolkit

Team shape is one layer of a bigger design question: the overall org structure you sit inside, and the way you've chosen to centralise or decentralise decisions, both constrain how wide and flat any individual team can be.

Where to go next