Conway’s Law – Dr. Martin Kramer

When a program scales to more teams, I am regularly involved designing the team setup — and regularly the wrong person to do it.

Not because I lack the experience. But because the knowledge that should drive that decision is not with me. It is in the domains.

Anyone scaling a large modernization program often has the same instinct: build more teams, divide the scope, assign the available people to the newly defined areas. Bring in a leadership group that has the overview and can decide who’s needed. That sounds like sensible program management.

It is structurally wrong — and the root cause is architectural, not organizational: as long as the domain boundaries are unresolved, resource allocation drives architecture. That is Conway’s Law. And we now know exactly what follows from it.

The assumption that holds the classical approach together

The classical approach works like this: a leadership group — program managers, architects, sometimes external consultants — designs the target organization. Teams are structured around capabilities, technical layers, or resource availability. Then the available people are fitted into that structure.

McKinsey puts the starting point plainly in their Agile transformation methodology: “Most transformations start with building the top team’s understanding and aspirations.” That sounds plausible. The problem is the assumption underneath it: that the knowledge of what good team structure looks like sits at the top.

It does not. And in a transformation of the complexity that decades-old legacy or even mainframe estates carry, that mistake is particularly consequential.

Why the knowledge sits in the domains — and what Conway has to do with it

The teams working daily with the systems and business processes understand the dependencies of the existing estate better than any leadership group does. They know which parts of the system are tightly coupled. They know where the real interface problems lie.

Melvin Conway formulated in 1968 what we now call Conway’s Law: organizations that build systems inevitably produce designs that mirror their own communication structure. This is not a metaphor. It is a causal statement. If I cut teams along technical layers or by availability, I get a system architecture that mirrors that division — not the one I wanted.

MacCormack, Rusnak, and Baldwin gave this empirical grounding in a 2008 Harvard Business School study. They examined how closely organizational structure correlates with product architecture — the so-called Mirroring Hypothesis. The finding: products from loosely coupled organizations are roughly eight times more modular than those from tightly coupled ones. Poor organizational design produces poor modular architecture — not as a side effect, but as a direct consequence.

For a large modernization program — the type I work with — this means: the decision about how to cut teams is not a resourcing question. It is an architectural decision. And it must be made before the resourcing begins.

The Inverse Conway Maneuver: architecture first

Anyone who wants to deliberately create the architecture they want must design the team structure accordingly — not the other way around. Instead of defining teams and hoping the architecture follows, we reverse the sequence. We start with the question: what architecture do we need? What domains does the system have, how strong are their internal dependencies, how loose their connections to the outside?

This reversal — known in the literature as the Inverse Conway Maneuver and listed on the Thoughtworks Technology Radar as an established technique — is the central lever when scaling delivery programs.

In practice, this works through domain analysis. We use Domain-Driven Design: Event Storming sessions with domain experts from the business, Bounded Context definitions, Context Maps. The goal is always the same: a domain map that shows which areas of the system are strongly correlated internally and have as few external dependencies as possible.

That map is the starting point for the team cut — not the free slots in people’s calendars.

Skelton and Pais develop a complementary idea in Team Topologies: every team has a cognitive load — a maximum mental overhead it can carry. Stream-aligned teams that follow a single value stream minimize handoffs and keep that load manageable. Top-down structures that distribute capabilities by availability routinely ignore that limit.

A layer-based cut forces handoffs across all teams for every business change. A domain-based cut eliminates that dependency entirely.

What this means concretely in a complex program

A large modernization program — with a legacy and sometimes mainframe estate where logic has grown into a practically inseparable unit over decades — brings exactly this challenge.

The modernization strategy we recommend in these programs is consistent: build domain by domain, following the Strangler Fig pattern, slice by slice. Start with a core that proves the architecture under real conditions — before the program scales to further domains. The core business domains provide the structure; their boundaries must be established before the team cut.

This is exactly where the Conway thesis applies directly: the domain cut must precede the resource cut. Team ownership follows from domain structure — not from capacity availability.

That is why the first phase of such a program begins with Event Storming and Domain-Driven Design. Not as a methodological ritual. But because that step lays the foundation for every subsequent decision: what Bounded Contexts emerge within the core domains? Where do the boundaries lie — and who takes ownership of them?

A concrete example from practice: core insurance processes — new business, and mid-term policy amendments — each span at least three business domains in complex systems. A quote request triggers pricing in one domain; an accepted application issues a policy in a second; and the binding event (cover going effective) drives downstream obligations — billing, correspondence, commissions — that live in still other contexts. These cross-domain handoffs are exactly what Event Storming makes explicit — and exactly the evidence a team needs to decide where Bounded Context boundaries should be drawn. Had the team made that cut before this analysis, it would have either ignored those handoffs or split across them arbitrarily.

A leadership group at the drawing board cannot answer these questions. They emerge through working with the domain experts from the business — in the workshops, across the event maps, through the collaborative refinement of Bounded Contexts. Only once that map exists does it decide how teams are formed and how accountability is distributed.

Self-Selection: letting the team decide

In some programs we go one step further — and this is the step that generates the most resistance when we first propose it.

Instead of centrally assigning available people to the newly defined domain teams, we let the team organize itself. The domain map is on the table. The available slots are transparent. The constraints are clear: skills, experience distribution, seniority. And then we ask people where they see themselves.

The evidence for this approach is consistent — even if it comes from case studies rather than controlled experiments. Sandy Mamoli and David Mole documented self-selection through their work at Trade Me and in their book Creating Great Teams: teams that formed without direct management assignment became high-performing teams over two years, with minimal subsequent adjustments. Martin Lohmann’s experience report on SimCorp’s Product Division — a SAFe rollout involving roughly 550 people forming 55+ teams across seven ARTs — shows the same pattern at larger scale. At New Relic, around 50 software teams were entirely reformed through self-organization under predefined constraints. The organizers described the outcome afterwards as “way more successful than anybody anticipated”. And I have seen it working myself.

An unexpected side effect: people chose colleagues they wanted to work with. That sounds simple — and it is. Those who get to choose take ownership. Those who are assigned wait and see.

The natural moment for a self-selection session is the close of the program’s first phase: once the Bounded Context map of the core domains is in place, the team slots and their areas of responsibility are transparent enough for people to make an informed choice.

Execution matters: self-selection requires active facilitation. Without it, the results are not good teams — the case studies show that as clearly as they show the successes.

The further a program moves from self-selection toward central assignment, the less ownership people feel — and the more adjustment the structure needs afterwards.

How this fits the broader conversation

The Spotify model appears in every discussion about team scaling. Joakim Sundén, one of the Agile Coaches who worked alongside the model during its formation, described it as “part ambition, part approximation” — never fully implemented, always an aspirational image. What companies copied was the structure: squads, tribes, chapters. What they ignored was the culture — genuine autonomy, psychological safety, the willingness to let mistakes happen. Structure without domain logic and without real decentralisation is just a label.

The difference does not lie in the org chart. It lies in who holds the knowledge that informs the cut.

What this means in practice

Scaling is not a resourcing problem. It is an architecture problem.

Adding new teams without first understanding the domain structure of the system builds an organizational form that — by Conway’s Law — produces a system architecture. And that architecture will not be the one you wanted. The HBS study shows this effect is real and measurable, not theoretical.

For a complex modernization program, this means concretely: the investment in Event Storming and Domain-Driven Design at the outset is not a methodological box-tick. It is the precondition for the teams that scale in later phases to work along the right boundaries. Domain ownership, Bounded Contexts, Context Maps — these artifacts are not just architecture documents. They are the foundation of the team organization.

Who decides where the domain boundaries should lie? Someone in the leadership group who knows the scope — or the people who work with the system daily and know where the real couplings are?

In the programs I work with, this question is regularly answered implicitly before it is ever asked. That is usually how the problem starts.