Inverse Conway Manoeuvre
Deliberately structuring teams to match the architecture you want, on the basis that the system will come to mirror the organisation regardless.
Conway's Law observes that systems mirror the communication structures of the organisations that build them. The manoeuvre takes it as a design instrument: choose the target architecture, then organise teams to match it, rather than fighting the resulting drift indefinitely.
Concretely: if you want independently deployable services aligned to business capabilities, you need long-lived teams owning those capabilities end to end. If teams are organised by technical layer — a front-end team, a back-end team, a database team — the architecture will develop layer-aligned boundaries and every feature will require three teams, whatever the diagram says.
The corollaries are as useful as the manoeuvre itself:
A microservices architecture with a functionally-siloed organisation produces a distributed monolith. The services exist, and every change still requires coordination across the same boundaries as before, with distribution added as pure cost.
Boundaries are drawn where communication is expensive. Interfaces between teams that rarely talk become strict and stable; interfaces inside a team stay fluid. That is why service boundaries should follow team boundaries and not cut across them.
Reorganisations are architectural events and should be reviewed as such.