The org chart is an architecture decision
Melvin Conway observed in 1968 that organisations design systems which mirror their own communication structures. It circulated for decades as a piece of folklore that felt true.
It was tested properly in 2012. Alan MacCormack, Carliss Baldwin, and John Rusnak, publishing in Research Policy, used a natural experiment: pairs of software products serving the same function, one built by a commercial firm with tightly coupled participants, the other by an open-source community with loosely coupled ones.
They found strong support. In every pair examined, the product from the loosely coupled organisation was significantly more modular. The magnitude was substantial — up to a factor of eight in terms of how far a design change in one component could propagate to others.
The managerial implication is the part worth sitting with. How teams are organised does not merely affect delivery speed. It determines the structure of what gets built, including its capacity to be changed later. A team boundary drawn today becomes a seam or a knot in the product for years.
One honest note on the study: the researchers treated firms as tightly coupled and open-source communities as loosely coupled by assumption rather than measuring the degree of coupling in each. The finding is strong; the operationalisation has been questioned.
The four team types
Matthew Skelton and Manuel Pais set out Team Topologies in 2019. Four team types, and the discipline is that everything is one of them.
Stream-aligned. Aligned to a single flow of work — a customer segment, a product line, a service. This is the default. Most teams should be this, and the others exist to support them.
Enabling. Helps stream-aligned teams acquire capability they lack. Temporary by design. If an enabling team becomes permanent, it has turned into a dependency.
Complicated-subsystem. Owns a component requiring specialist knowledge that would overload a stream-aligned team. Justified only when the specialism is genuinely deep.
Platform. Provides internal services that stream-aligned teams consume self-service. The test is self-service: if teams have to raise a ticket and wait, it is not a platform, it is a queue.
Three interaction modes
Collaboration. Two teams work closely for a defined period. High bandwidth, high cost, appropriate for discovery. Not a permanent state.
X-as-a-Service. One team consumes something another provides, with minimal communication. Low cost, appropriate once the interface is understood.
Facilitating. One team helps another improve. Temporary.
The reason to name interaction modes is that unnamed interaction defaults to collaboration everywhere, which is how coordination cost grows faster than headcount.
The evidence splits in two, and only one half holds
This is the most important thing to understand before applying the framework.
The Conway's Law foundation is empirically grounded. The mirroring research is independent, published in a peer-reviewed journal, and found large effects. Structuring teams around flow rather than function has a real basis.
The team-sizing guidance is not. Team Topologies invokes Dunbar's numbers — roughly 5, 15, 50, 150 — as limits on group cohesion at various levels. Dunbar's number has been seriously challenged.
Lindenfors, Wartel, and Lind replicated the original analysis in Biology Letters in 2021, using larger datasets and modern statistical methods. Their estimates of average group size ranged from 69 to 109 by one method and 16 to 42 by another, with 95% confidence intervals of 4 to 520 and 2 to 336 respectively. Their conclusion was that specifying any one number is futile, and that a cognitive limit on human group size cannot be derived this way.
Their paper also notes that the Swedish Tax Authority restructured its offices to stay within the 150-person limit — a real organisational decision made on a number that does not survive scrutiny.
So: use the structural argument, not the numbers. Small teams are worth defending for reasons that stand on their own — coordination cost, ownership clarity, and the queueing effects of shared capacity — none of which require a figure from primate neocortex research.
Under the grading used across this series, Team Topologies is a documented practitioner method resting on one empirically grounded foundation and one contested one.
Cognitive load is the better sizing principle
The framework's more defensible sizing idea does not depend on Dunbar at all.
A team can hold a limited amount of domain in its head. Exceed it and the team stops making good decisions, not because members are overloaded with tasks, but because nobody holds a complete picture of anything.
That gives a usable test with no number in it: can the team explain, without referring to documentation, how their part of the system works and why it works that way? When the answer becomes no, the team owns too much domain, and the fix is reducing scope rather than adding people.
This also connects directly to throughput. Adding people to a team that has exceeded its cognitive limit adds coordination overhead to a system that is already the constraint.
Structure around flow, not function
The practical instruction is one sentence: draw team boundaries where the work flows, not where the skills are similar.
Functional organisation — all designers together, all engineers together, all marketers together — optimises for professional similarity and guarantees that every unit of customer value crosses several boundaries. Each crossing is a queue.
Flow-aligned organisation puts the people needed to deliver an outcome in one team, accepting that skills are distributed rather than pooled. It costs some efficiency in specialist utilisation and buys throughput.
The diagnostic is the handoff count. Take a typical piece of customer-facing work and count how many team boundaries it crosses from request to live. Above two or three, structure is the constraint, and no process change will fix it.
Where it goes wrong
Applied as a reorganisation template. The framework is a diagnostic for where handoffs create delay. Redrawing the whole org chart to match four labels produces the same problems with new names.
Platform teams that are not self-service. A platform other teams must file requests against is a bottleneck with a modern title. The self-service test is the whole distinction.
Enabling teams that become permanent. Designed to transfer capability and dissolve. Left in place, they become a dependency the stream-aligned teams route around or wait on.
Collaboration as the default mode. Every team pair collaborating with every other is how coordination cost grows quadratically. Most interactions should be X-as-a-Service.
Ignoring the mirroring implication. Teams get restructured while the existing architecture stays. The two then fight, and the architecture usually wins, because it was built by the previous structure.
Diagnostic: is structure helping or hindering?
Six tests.
A typical piece of customer work crosses two or fewer team boundaries.
Every team can be classified as one of the four types, and most are stream-aligned.
Any platform team is genuinely self-service, with no ticket queue.
Each team can explain its part of the system without documentation.
Interaction modes between team pairs are named, and most are not collaboration.
Enabling teams have an end date.
Test one is the fastest and most revealing. It takes ten minutes and does not require agreement on anything conceptual.
What this produces
Delivery that scales with headcount rather than degrading with it.
The failure this addresses is specific and common: a business adds people, delivery slows, and nobody can point to why. The answer is usually that each addition increased coordination cost more than capacity, because the boundaries were drawn across the flow rather than along it.
Structure is a design decision with a long half-life. The research says it will be visible in the product for years after the reorg that caused it. That is a reason to make it deliberately rather than by accretion.
Frequently asked questions
What is Conway's Law and is there evidence for it?
Conway observed in 1968 that organisations produce systems mirroring their communication structures. MacCormack, Baldwin, and Rusnak tested it in 2012 by pairing open-source and proprietary products of similar function, and found the loosely coupled organisations produced significantly more modular designs — by up to a factor of eight on change propagation.
What are the four team types in Team Topologies?
Stream-aligned, enabling, complicated-subsystem, and platform. Most teams should be stream-aligned; the other three exist to support them.
Is Dunbar's number a reliable basis for team sizing?
No. A 2021 replication in Biology Letters found estimates ranging widely with confidence intervals from 4 to 520 people, and concluded that specifying any single number is futile. Use cognitive load and coordination cost as sizing principles instead.
How do I know if a team is too large?
Ask whether the team can explain how their part of the system works, and why, without consulting documentation. When they cannot, the team owns too much domain — and the fix is reducing scope rather than adding people.
What makes a platform team different from an operations team?
Self-service. If other teams consume the platform without filing requests, it is a platform. If they raise tickets and wait, it is a queue with a new name.
Should we organise by function or by product?
By flow. Functional grouping optimises for specialist similarity and guarantees that every unit of customer value crosses multiple boundaries, each of which is a queue. Count the handoffs in a typical piece of work — above two or three, structure is the limiting factor.
Does restructuring teams fix a bad architecture?
Not on its own. Existing architecture was produced by the previous structure and will resist the new one. Team change and architectural change need to happen together, or the architecture wins.
Sources
Conway, M., How Do Committees Invent? (1968)
MacCormack, A., Baldwin, C. and Rusnak, J., Exploring the Duality Between Product and Organizational Architectures: A Test of the Mirroring Hypothesis, Research Policy 41(8), 2012
Skelton, M. and Pais, M., Team Topologies (2019)
Lindenfors, P., Wartel, A. and Lind, J., 'Dunbar's Number' Deconstructed, Biology Letters 17(5), 2021
Structure your next phase
Zerologic works with leadership teams on operating model and team design — drawing boundaries along the flow of work rather than around functional similarity.
Talk to us: partners@zerologic.io · zerologic.io
