Comparison
Conway's lawvsInverse Conway manoeuvre
Conway's law
the system has four services and the company has four teams, and nobody planned that.
Organisations produce designs that mirror their own communication structure. It is an observation rather than advice, and it holds because the interfaces that are easy to change are the ones inside a team and the ones that are hard are the ones between teams. It explains a great deal that looks like bad engineering: an unnecessary service boundary is often just the place where two groups found it easier to define an API than to talk every day.
Full entry →Inverse Conway manoeuvre
they wanted the architecture split three ways, so they reorganised the teams first and waited.
Deliberately reshaping teams to produce the architecture you want, rather than fighting the architecture the current teams will inevitably produce. It is a genuinely powerful move and an expensive one, because reorganisations cost months of productivity and social capital. It is also the honest answer to why a technically sound decomposition failed: the boundary was drawn in the code but not in the org chart, so it eroded.
Full entry →