Skip to content

Inverse Conway Design Intervention

Design intervention — instantiates Organization–Artifact Topology Alignment

Deliberately shapes team boundaries first so the artifact the teams produce grows into the desired architecture — using Conway's law on purpose instead of fighting it.

If an organization's structure will imprint itself on its artifact anyway, you can pick the imprint. Inverse Conway Design Intervention changes the teams — their boundaries, ownership, and communication paths — so that the architecture the teams naturally produce is the one you want. Its defining move is to work with Conway's law rather than against it: instead of designing the artifact and hoping the org cooperates, it designs the org so the desired artifact becomes the path of least resistance. Its lever is team topology; it consumes a target architecture and enacts it socially, leaving the artifact-side surgery and the record-keeping to siblings.

Example

A media company wants a modular "content platform plus independent product apps" architecture, but today one large team owns everything and the codebase is a monolith that faithfully mirrors that single team. Refactoring the code first would fail — the one team would simply re-entangle it. So they run the inverse-Conway maneuver instead: reorganize into a platform team owning shared content services and three stream-aligned teams for news, video, and audio, each able to ship independently. With that team topology in place, the cheapest way for each product team to work is to build against the platform's API — and the artifact drifts toward the intended modular shape because the org now makes any other shape expensive. They moved people, and the architecture followed.

How it works

What distinguishes it from an ordinary reorganization is that the org change is derived from a target architecture:

  • Start from the desired architecture — the target the teams are meant to induce, taken from the domain boundary review.
  • Enumerate team-topology options — how to split into stream-aligned, platform, enabling, and complicated-subsystem teams.
  • Pick the split whose path of least resistance produces the target — the team boundaries that make the wanted module boundaries the natural ones.
  • Change the org and let Conway's law build — the maneuver moves people, then relies on the mirroring effect to shape the artifact over time.

Tuning parameters

  • Team-type mix — how many stream-aligned versus platform versus enabling teams. More platform teams increase reuse but risk a central bottleneck.
  • Boundary alignment — how tightly team boundaries match the target module boundaries. A tighter match imprints more strongly but disrupts more people.
  • Cognitive-load ceiling — how much domain each team carries. Overloaded teams re-couple things to cope, undoing the intended split.
  • Transition pace — a big-bang reorganization versus a gradual one. Faster imprints sooner but costs more disruption and attrition.
  • Reversibility — how hard the maneuver is to undo if the target architecture turns out to be wrong.

When it helps, and when it misleads

Its strength is that it makes the architecture self-reinforcing: because the org's grain now runs the same way as the intended design, teams stop fighting the structure and the artifact tends to stay in shape rather than drifting back.

Its failure mode is that reorganizations are expensive and land on people, and Conway's law is indifferent to whether the target is good — it will imprint a bad architecture just as faithfully. Run without a clear target, the maneuver is just churn with a fashionable name. The classic misuse is reorganizing for its own sake, or to move a particular person, and labelling it an inverse-Conway intervention after the fact. The discipline that guards against this is to run it only when the desired architecture is clear and genuinely worth a reorganization, to respect each team's cognitive-load limit, and to pair it with the domain boundary review that supplies — and justifies — the target.[1]

How it implements the components

Inverse Conway Design Intervention fills the org-side lever of the archetype — the team-boundary design, and nothing beyond it:

  • team_topology_design_option_set — the set of team-boundary and ownership options it generates and selects among to induce the target architecture.

That single component is the point. It does not define the desired_architecture_intent — it consumes that target from the Bounded Context or Domain Boundary Review; the artifact-side architecture_refactoring_option_set belongs to Artifact Boundary Refactor; and the mirror_or_decouple_decision_record that documents the choice belongs to Architecture Decision Record with Ownership.

Notes

The artifact follows the reorganization with a lag. Expect a period where the old monolith persists under the new team boundaries before the mirroring effect reshapes it — the maneuver sets the direction, not the speed. When you can't wait for the drift, pair it with an Artifact Boundary Refactor so the org change and the artifact change move together.

References

[1] The inverse Conway maneuver — reshaping teams so the desired architecture emerges from their communication structure — is a central technique in Team Topologies (Matthew Skelton and Manuel Pais), which names stream-aligned, platform, enabling, and complicated-subsystem as the recurring team types. It is sound only when the target architecture is deliberate; Conway's law will mirror an ill-chosen target with equal fidelity. ↩