Inverse Conway Maneuver

The idea

Conway's Law says organisations produce designs that mirror their communication structures. The Inverse Conway Maneuver turns that observation into a lever: if systems mirror organisations, then deliberately designing the organisation is a way of designing the system.

Martin Fowler credits the term to Jonny LeRoy and Matt Simons, writing in the Cutter IT Journal in 2010. Thoughtworks put it on its Technology Radar in 2014, recommending that teams evolve their structure to promote the architecture they want. Team Topologies later gave it a practical vocabulary: stream-aligned, platform, enabling and complicated-subsystem teams, with explicit interaction modes of collaboration, X-as-a-Service and facilitation.

Why it works

Communication paths become interfaces. Teams that talk constantly tend to build tightly integrated components; teams that interact through a defined service tend to build a clean boundary. Arranging the teams arranges the seams.

Ownership drives design decisions. A team that owns a business capability end to end will shape its code around that capability. A team that owns a technical layer will shape its code around the layer.

Fighting Conway's Law is expensive. An architecture that cuts across team boundaries needs constant coordination to hold together. Aligning teams with the target design removes that friction instead of managing it forever.

Where it applies

• Moves to independently deployable services, where team boundaries decide whether the services really are independent.
• Reorganisations, so architects can say what the new structure will do to the system.
• Platform strategy, to decide which capabilities a platform team should offer as a service.
• Domain-driven design, aligning stream-aligned teams with bounded contexts.

How to apply

1. Sketch the target architecture in terms of boundaries and dependencies, not technologies.
2. Map today's teams and their communication against it, and note where they cut across the target boundaries.
3. Design teams around the boundaries you want, typically stream-aligned teams around business domains with platform teams beneath them.
4. Define how teams interact: which pairs collaborate for a period, and which consume each other as a service.
5. Partner with leadership and HR, and plan the transition. Team design is an organisational decision, not an architecture diagram.

Example scenario

An enterprise wanted independent product services but organised its engineers by technology: front end, back end and a central database team. Every feature needed all three, so the "services" shared a schema and were released together.

The architect worked with the engineering director to form product-aligned teams, each owning a business capability with its own data, and a small platform team for shared infrastructure. Within a couple of quarters, clean service boundaries began to emerge along the new team lines, and most features could be released by a single team.

Questions to ask

When not to use it

• Rigid architectures. Fowler notes that reorganising teams around a system whose architecture resists change will not fix it quickly; the code may need restructuring too.
• Small organisations where one or two teams own everything and communication is easy anyway.

How it misleads you