Wired by Design: The Org Laws That Govern Every Engineering Team
The way you build teams is the way you build software. Not as a metaphor — as an empirical, observable, repeatable outcome. The laws governing how teams form, communicate, and decompose work have been documented since the sixties. They don't care about your best intentions. They operate whether you acknowledge them or not.
Here's the punchline up front: Conway explains where the architecture will fragment. Dunbar explains when. Brooks explains why the obvious fix makes things worse. Parkinson explains why the problem stays hidden. Goodhart explains why your metrics won't save you. And Ringelmann explains why even the people you already have contribute less as you add more. Taken together, they form a coupled system with predictable failure modes — and predictable design levers.
A note on terminology: none of these are laws in the physics sense. They're sociological observations and empirical regularities — patterns that have held up across enough organisations, over enough decades, to be treated as defaults rather than suggestions. They can be worked with, designed around, and occasionally overridden. But they can't be ignored.
This post maps the key laws, shows how they interconnect, and draws out the strategies that follow when you take all of them seriously at once.
The Core Laws
Conway's Law — Structure Follows Communication
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Melvin Conway, Datamation, 1968
This is the load-bearing observation. If your frontend, backend, and data teams are siloed, your software will have a hard seam at exactly those boundaries — not because anyone designed it that way, but because the teams built what they could talk about. Shared ownership produces a shared mess. Clean team boundaries produce clean interfaces.
Notice the word constrained. Conway wasn't saying teams tend to produce mirrored designs. He was saying they are constrained to — the design space itself is limited by the communication structure. The architecture reflects the org chart whether you want it to or not.
Brooks's Law — Coordination Overhead Is Quadratic
"Adding manpower to a late software project makes it later."
— Fred Brooks, The Mythical Man-Month, 1975
The mechanism is precise. For people on a team, the number of distinct communication channels is:
Click to expand
Every new hire requires onboarding time and creates new communication paths that tax every existing member. The team slows down before the new person produces anything. On a project already late, that deficit compounds.
Brooks's Law isn't a rule against hiring — it's a warning about timing and team composition. The cost of coordination grows faster than the capacity added.
Parkinson's Law — Work Expands to Fill Available Time
"Work expands so as to fill the time available for its completion."
— C. Northcote Parkinson, The Economist, 1955
Give a team a two-week sprint, the work takes two weeks. Give them three, it takes three. This isn't about laziness — it's cognitive satisficing (optimising for "good enough" rather than "best possible"). We optimise to "done by deadline" rather than "done well early." Scope quietly inflates to fit the available window. Confidence levels adjust retroactively.
It's worth noting that Parkinson's original essay wasn't about individual procrastination — it was about bureaucratic headcount growth. He showed that the British Colonial Office and Admiralty grew their staff regardless of whether the actual workload increased or decreased. The number of officials expanded to fill the available organisational capacity, not just the available time. That makes Parkinson more relevant to team design than most popularisations suggest: it's an observation about organisations, not psychology.
The implication for planning: tighter deadlines with deliberate scope tend to produce sharper outputs, but only when the scope is genuinely fixed. Compressing time without compressing scope just produces crunch.
Dunbar's Number — Cognition Limits Collaboration
Robin Dunbar's research on neocortex size and social group cohesion produced a set of layered numbers that matter enormously for engineering org design:
| Layer | Size | Characteristic |
|---|---|---|
| Core trust | ~5 | Full shared context, no ceremony |
| Close collaboration | ~15 | High-bandwidth working group |
| Stable social | ~50 | Everyone knows everyone |
| Organisational | ~150 | Informal coordination still possible |
Click to expand
Beyond 150, informal coordination breaks down and formal process becomes load-bearing. Beyond 50, you lose the shared context that makes fast decisions possible. Beyond 15, a team can no longer maintain full mutual awareness of each other's work.
The specific number 150 is empirically contested. A 2021 reanalysis of the original primate neocortex data found the confidence interval ranges from roughly 2 to 520 — not exactly a precise prediction. But the existence of layered cognitive limits on group cohesion is well-supported. Dunbar tells you where the fault lines are, even if the exact coordinates have error bars.
Goodhart's Law — When a Measure Becomes a Target
"When a measure becomes a target, it ceases to be a good measure."
— Charles Goodhart (paraphrased by Marilyn Strathern, 1997)
Velocity. Story points. Lines of code. Deployment frequency. Code coverage. Every metric an engineering team has ever been measured by has eventually been gamed, inflated, or optimised at the expense of the thing it was supposed to represent.
Goodhart's Law is the measurement counterpart to Parkinson. Parkinson says work expands to fill time. Goodhart says measured work expands to fill the metric. A team measured on velocity will produce velocity — not necessarily value. A team measured on deployment frequency will deploy frequently — not necessarily safely. The metric becomes the product.
This matters for team design because every organisational structure carries implicit metrics. Functional teams (frontend, backend, QA) tend to be measured on functional throughput. Stream-aligned teams tend to be measured on user outcomes. Conway says the architecture follows the team structure. Goodhart says the behaviour follows the measurement structure. If you design the team well but measure it badly, Goodhart will undo your work.
Ringelmann Effect — Social Loafing Scales With Group Size
Individual effort decreases as group size increases.
— Maximilien Ringelmann, 1913
Ringelmann had people pull ropes. He found that as the group grew, each individual pulled with less force — not because they were tired, but because the diffusion of responsibility reduced personal accountability. Two people didn't pull twice as hard as one. Eight people pulled at roughly half the per-person effort of one.
Click to expand
Ringelmann's original experiments used physical rope-pulling tasks. Meta-analyses (notably Karau & Williams, 1993) broadly confirm the effect across task types, but the magnitude varies: cognitive and knowledge-work tasks consistently show less loafing than physical ones, particularly when individual contributions are identifiable. The curve above is approximate and illustrative — the shape is well-supported, but the specific percentages should not be read as precise values for engineering teams.
This is the motivational complement to Brooks's coordination argument. Brooks says adding people increases communication overhead. Ringelmann says adding people also decreases per-person effort. Large teams are doubly penalised: more overhead and less individual contribution.
The Ringelmann Effect is why the "two-pizza rule" (Jeff Bezos's heuristic that teams should be small enough to feed with two pizzas) works in practice. It's not just about coordination — it's about the psychological consequence of anonymity in a group. When your contribution is visible and attributable, you work harder. When it dissolves into a crowd, you don't. Small teams create nowhere to hide.
The Supporting Laws
These don't need full sections, but they constrain and inform the core laws above.
Amdahl's Law — Parallelisation Has a Ceiling
The speedup of a system is limited by the fraction of work that cannot be parallelised.
— Gene Amdahl, 1967
When you split teams to parallelise work, Amdahl sets the ceiling on how much speedup you can get. If 30% of the work requires cross-team coordination — integration, shared decisions, platform dependencies — splitting into more teams cannot yield more than roughly 3.3× throughput improvement, no matter how many teams you create. This formalises the diminishing returns of team splitting and tells you when to stop.
Gall's Law — Complex Systems Evolve From Simple Ones
"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works."
— John Gall, Systemantics, 1975
This is the essential counterweight to the Inverse Conway Maneuver (discussed below). You should design your target team topology — but you cannot leap to it in one move. Big-bang reorgs fail because they attempt to instantiate a complex system from scratch. The path to the target structure runs through working intermediate states.
Price's Law — A Square Root Does Half the Work
The square root of the total number of contributors produces roughly half of the total output.
— Derek J. de Solla Price, 1963
Price's original work (Little Science, Big Science) was about scientific publication productivity — he observed that a small fraction of researchers produced the majority of papers. The "square root" formulation is a later simplification; the actual distribution is closer to a Lotka power law, and the precise shape has been contested. But the core observation — output is heavily concentrated among a minority of contributors — has held up across enough domains to be treated as a planning default.
In a team of 100 engineers, roughly 10 produce half the output. This compounds Brooks's argument: not only does adding people increase coordination overhead, but the marginal productivity of each new person is lower than the per-capita average. Scaling headcount linearly does not scale output linearly.
The Coupled System
Read in isolation, each law offers a heuristic. Taken together, they describe a coupled system — with Conway at the centre.
Brooks's Law describes the coordination overhead of growing teams — but that overhead matters because Conway says it will imprint on the architecture. Dunbar's Number describes cognitive limits on group size — but those limits matter because Conway says the team's informal fragmentation will become the system's real structure. Parkinson and Goodhart describe how work and metrics expand — but that expansion matters because Conway says the resulting behaviour will crystallise into architectural boundaries. Ringelmann describes motivational loss in large groups — but that loss matters because it compounds the coordination tax that Conway turns into structural reality.
Conway is the transmission mechanism. The other laws describe forces. Conway describes where those forces land.
Click to expand
Conway + Brooks: The Scaling Trap
When a team grows past Dunbar's cohesion threshold (~15), Conway predicts the architecture will start to fragment — the team's communication structure is no longer coherent. The instinct is to hire and restructure to match. But Brooks predicts that adding people under deadline pressure makes the situation worse before it gets better.
The trap: you need the architectural split, but hiring to force the split creates the exact coordination overhead Brooks describes. The resolution requires separating the two decisions in time. Don't restructure the architecture reactively under pressure. Design the split proactively, when the team has slack. Hire into the target structure, not the current one.
Brooks → The Inverse Conway Maneuver
The Inverse Conway Maneuver — coined by Johnny LeRoy and Matt Simons around 2010, popularised on the Thoughtworks Technology Radar (2015), and developed extensively in Team Topologies (Skelton & Pais, 2019) — is the strategic application of Conway's Law in reverse:
If your current architecture is a monolith and your target is autonomous services, don't restructure the code first. Restructure the teams first.
Create stream-aligned teams with clearly owned domains and well-defined interfaces to the rest of the org. The architecture will follow — because Conway says it must. This is how Brooks's Law becomes manageable: when teams have clear ownership boundaries, new members join a well-scoped context. They don't need to understand the whole system. The coordination tax drops because the communication surface is deliberately constrained.
The Inverse Conway Maneuver is Brooks's Law turned into a design tool. But Gall's Law constrains how you execute it: you can't leap to the target state in one reorg. Design the target topology, then migrate through working intermediate states. The big-bang reorg is a complex system designed from scratch — and Gall says it won't work.
Team Topologies identifies four team types that operationalise this: stream-aligned teams (own a flow of work end-to-end), enabling teams (help stream-aligned teams acquire missing capabilities), complicated-subsystem teams (own areas requiring deep specialist knowledge), and platform teams (provide self-service internal services). The taxonomy matters because not every team can be stream-aligned — and forcing specialists into stream alignment where it doesn't fit is a Conway violation in the other direction.
Equally important are the three interaction modes between teams: collaboration (two teams working closely together for a bounded period), X-as-a-Service (one team consumes another's output through a well-defined interface), and facilitating (one team helps another build a capability, then steps back). These modes describe how communication actually flows between teams — which is exactly what Conway governs. Choosing the wrong interaction mode is as consequential as choosing the wrong team boundary.
Parkinson + Conway + Goodhart: The Feature Factory
Functional teams (separate frontend, backend, QA, data layers) create built-in Parkinson effects. Work in each function expands to fill the sprint. Cross-functional dependencies generate waiting time that gets absorbed invisibly — "blocked on backend" becomes a steady state rather than an exception.
Goodhart makes it worse. When functional teams are measured on functional throughput (tickets closed, features shipped, test cases written), each function optimises for its own metric. QA writes more tests — not necessarily better ones. Frontend ships more UI — not necessarily what users need. The metrics are green. The product is incoherent. Welcome to the feature factory.
Stream-aligned teams — one team owns one user journey or domain end-to-end — compress this. The team's own deadline pressure is internal. There's no waiting on another team's sprint cycle. Parkinson's expansion still operates, but it operates inside the team rather than across a dependency graph. Scope control is easier because ownership is clear. And Goodhart is moderated because the team's natural metric becomes user outcome, not functional throughput.
The pattern is well-documented outside software. When the UK's National Health Service introduced ambulance response time targets — arrival within 8 minutes for life-threatening calls — trusts began redefining what counted as "arrival" and reclassifying call severity to hit the number. The target was met. Patient outcomes didn't improve (Bevan & Hood, 2006). Wells Fargo's cross-selling targets produced the same dynamic at industrial scale: employees opened millions of unauthorised accounts to satisfy the metric (DOJ Statement of Facts, 2020). In both cases, the measure became the product. Goodhart isn't a curiosity — it's a reliable failure mode of any system that optimises for a proxy.
Dunbar + Conway: Why Team Topology Matters at Scale
As engineering organisations scale, they tend to violate Dunbar's limits without noticing. A team of 25 that once operated as a single unit starts to fragment informally. Sub-groups form around the office layout, the Slack channels, or the codebase ownership that's naturally emerged. Conway is already happening — the architecture is drifting to match the informal structure, not the org chart.
The engineering leadership failure here is to respond to coordination problems by adding coordination: more meetings, more process, stricter PMs. Dunbar says the underlying issue is cognitive — the team is too large for the collaboration pattern you're expecting. The response is structural, not procedural. Split the team explicitly, design the interface between the new teams deliberately, and let Conway do the rest.
Brooks + Ringelmann: The Double Penalty of Large Teams
Brooks tells you that coordination overhead grows quadratically. Ringelmann tells you that individual effort drops as the group grows. These are independent mechanisms — one structural, one motivational — and they compound.
A team of 20 doesn't just have 190 communication channels to manage. It also has 20 people each contributing less effort per person than they would in a team of 5. The coordination tax goes up. The per-person output goes down. The productivity curve doesn't just flatten with scale — it bends downward.
This is why capping teams at 8–10 isn't a soft preference. It's backed by two independent forcing functions, both of which accelerate past that threshold.
When the Laws Conflict
The laws mostly reinforce each other, but not always. Knowing when they pull in different directions is what separates design from dogma.
Conway vs. Specialisation. Conway says structure teams around the desired architecture. But some capabilities — ML engineering, security, SRE, design systems — require deep specialisation that doesn't map neatly to a single product domain. Forcing specialists into stream-aligned teams can dilute expertise and produce worse outcomes. This is why Team Topologies includes enabling teams, complicated-subsystem teams, and platform teams alongside stream-aligned ones. The taxonomy exists precisely because Conway alone isn't sufficient.
Brooks vs. Strategic Urgency. Brooks says don't add people to a late project. But sometimes the project is strategically critical and you must grow the team. The answer isn't "don't hire" — it's "hire into a new, independent workstream with a clean interface to the existing one." Create a new team with a well-scoped domain. Don't inject new people into the hot path. Brooks's Law applies to adding people to an existing communication structure. If you create a new structure with a defined boundary, the quadratic penalty resets.
Parkinson vs. Innovation Slack. Tighter deadlines counter Parkinson, but they also kill exploration. Some of the most valuable engineering work — discovering a better abstraction, prototyping a new approach, refactoring a load-bearing module — requires unstructured time. The resolution isn't to choose one or the other. It's to maintain both modes explicitly: delivery sprints (tight scope, compressed time) and exploration periods (loose scope, protected time). Mixing them in the same sprint satisfies neither.
Failure Modes
The practical strategies below tell you what to do. These anti-patterns tell you what it looks like when you don't.
The Reorg That Made It Worse
A team of 30 is struggling. Leadership decides to split it into three teams of 10 — under deadline pressure, mid-sprint, with no clear domain boundaries. Brooks predicted exactly this. The three new teams inherit the old communication patterns, add new cross-team coordination overhead, and spend the next two sprints figuring out who owns what. The deadline slips further.
What went wrong: Restructuring reactively under pressure. The decision to split was correct. The timing was not.
The 25-Person "Team"
On paper it's one team. In practice, three sub-groups have formed: the people who sit together, the people who work on the API, and the people who joined in the last six months. They have different standup times and different Slack channels. The architecture has three styles. Nobody planned this — Dunbar did.
What went wrong: Ignoring the cognitive limits. The team exceeded Dunbar's ~15 threshold and fragmented informally. The architecture drifted to match the informal structure, not the intended one. By the time leadership noticed, Conway had already shipped.
The Metric That Ate the Product
A platform team is measured on deployment frequency. They deploy 47 times per week. They are also the team with the highest rollback rate, the most production incidents, and the least customer-facing impact per deployment. Every review cycle, they report excellent numbers. Goodhart predicted this.
What went wrong: Measuring activity instead of outcome. The team optimised for the target, not the thing the target was supposed to represent.
Practical Strategies
Taking the laws together, a set of practical principles follows. Each is grounded in at least two of the laws above.
1. Co-design architecture and team topology — then use the teams as the enforcement mechanism. (Conway + Gall) Define the architectural boundaries first, then draw team boundaries to match. The team structure is a more reliable lever than design documents. Migrate incrementally (Gall) — don't attempt the target state in one move.
2. Cap working teams at 8–10, split before you hit the limit. (Brooks + Dunbar + Ringelmann) Don't wait until the team is struggling to coordinate. At ~10, start designing the split. Hire into the target structure. The case for small teams rests on three independent mechanisms: coordination overhead (Brooks), cognitive limits (Dunbar), and motivational diffusion (Ringelmann).
3. Treat team interfaces like API contracts. (Conway) Every team should have an explicit understanding of what it publishes to and consumes from adjacent teams. This is Conway operationalised. Unclear interfaces produce unclear seams in the codebase. Define the contract, version it, and hold teams to it.
4. Set scope-fixed, time-boxed delivery windows. (Parkinson) The response to Parkinson isn't longer deadlines — it's scope discipline. Fix the outcome, compress the time, and resist the scope creep that fills the slack. But protect explicit exploration time separately — mixing delivery and innovation in the same sprint satisfies neither.
5. Protect cognitive load per team. (Dunbar + Conway) A team that owns too many domains, or too many systems, will fragment along informal lines. Dunbar is operating below the surface. Keep each team's domain small enough that every member can hold the full context. When in doubt, the domain is too big, not too small.
6. Hire into the architecture you want, not the one you have. (Conway + Brooks) The Inverse Conway Maneuver only works if hiring decisions reinforce the target structure. A new hire joins a team with a clear domain. The domain shapes their mental model. Their work reinforces the boundary. When a project is urgent, hire into a new team with a clean interface — don't inject people into the hot path (Brooks).
7. Measure outcomes, not activity. (Goodhart) Goodhart says every metric will be gamed. The defence isn't better metrics — it's measuring closer to the outcome you actually care about. Deployment frequency is a proxy. Customer impact is closer to the thing. Combine quantitative metrics with qualitative judgment and resist the urge to reduce team performance to a single number.
8. Know the parallelisation ceiling. (Amdahl) Amdahl says that if 30% of your work is inherently sequential (cross-team integration, shared decisions, architectural alignment), no amount of team splitting can yield more than ~3× throughput. Beyond a certain number of teams, the returns are negligible and the coordination cost is real. Split for ownership and cognitive load — not because "more teams = more speed."
The Meta-Observation
These laws don't just describe independent effects. They describe a coupled system — and Conway is the reason the coupling matters. Without it, the other laws are management problems. With it, they become architectural realities you ship to production.
Conway explains where the architecture will fragment. Dunbar explains when. Brooks explains why the obvious fix (more people) makes things worse. Ringelmann explains why even the people you already have contribute less as you add more. Parkinson explains why the problem stays hidden longer than it should. Goodhart explains why the dashboard says everything is fine.
The Inverse Conway Maneuver — constrained by Gall's Law and informed by Amdahl's — is what you get when you use all of them to design forward rather than explain backward.
Engineering leadership at scale is, in large part, the discipline of working with these forces rather than against them. The teams that scale well aren't the ones that hired better or worked harder — they're the ones that designed their team structure with the same rigour they applied to their software.
The org chart is the architecture. Build it like one.