What is the Inverse Conway Maneuver pattern?
Conway's Law observes that a system's structure tends to copy the organisation that built it: three teams produce three components, and teams that rarely talk produce components with a narrow interface. The inverse manoeuvre uses this on purpose. Decide which services and boundaries you want, then organise teams so that each one owns one of them, and the architecture follows.
What problem does the Inverse Conway Maneuver pattern solve?
Redrawing service boundaries on a diagram does not last if teams stay organised the old way. A shared frontend team will keep producing one shared frontend, and a central database team will keep producing a shared database. Changing the teams is often the only way to make a new architecture stick.
How do you implement the Inverse Conway Maneuver pattern?
- Design the target architecture around business capabilities, and identify the boundaries that matter most.
- Form or reshape teams so that each one owns one or a few of those boundaries, across every layer.
- Make cross-team communication go through the interfaces you want, such as APIs, events and contracts.
- Expect the architecture to follow over months, not weeks, and review where team and system boundaries still disagree.
- Move people deliberately and keep teams stable afterwards.
When should you use it?
- You are moving to services and the current teams are organised by technical layer.
- The architecture keeps drifting back to a shape nobody chose.
When should you avoid it?
- You do not yet understand the domain well enough to know where the boundaries should be. Reorganising twice is expensive.
What do you gain?
- The architecture you want becomes the easiest one to build
- Team and service ownership line up
- Fewer cross-team dependencies
What does it cost?
- Reorganisations are disruptive
- Wrong boundaries are costly to undo
- Needs leadership support, not just architects
What are common mistakes with the Inverse Conway Maneuver pattern?
- Drawing a new architecture and keeping the old teams, then wondering why it does not happen.
- Reorganising around boundaries that are guesses, before the domain is understood.
- One team owning many unrelated services, so the boundaries between them blur.
Inverse Conway Maneuver in practice
Halcyon Lending
Architects designed a set of capability-based services, but the frontend team, backend team and database team stayed as they were. Two years on, the new 'services' all shared one database and one frontend release.
The company reorganised into teams for applications, underwriting, servicing and collections, each with its own engineers for every layer, and moved the database specialists into a platform team that runs managed databases. The shared schema was split over the following year.
Further reading: How Do Committees Invent? (Melvin Conway, Datamation, 1968); Conway's Law (Martin Fowler, 2022)
Example decision record
- Context
- A new service architecture keeps collapsing back into a shared frontend and a shared database.
- Decision
- Reshape teams around the target capability boundaries before expecting the architecture to change.
- Consequences
- Team and service boundaries line up.
- The reorganisation is disruptive and depends on getting the boundaries right.
Test yourself on Inverse Conway Maneuver
Architects drew six capability-based services. A year later the system still has one shared frontend and one shared database, built by the frontend team and the database team, which were never changed. Why?
4 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →