Published: Last updated:

Conway's Law

Team Structure Shapes the Architecture

Conway's Law states: Organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations. The reverse, the Inverse Conway Maneuver, turns this into an active design principle: we organise teams the way we want the architecture to look.

Conway's Law is not a warning but a tool. Deliberate team design is architecture design.

Effects in Practice

  • Classic case: A monolithic backend team produces a monolithic backend service.
  • Microservice trap: Teams cut by technology (frontend/backend/DB) instead of by domain produce distributed monoliths.
  • Right approach: Structure teams along Bounded Contexts (DDD) so that each team fully owns its service.

Inverse Conway Maneuver

The active use of Conway's Law: define the target architecture first, then organise the teams accordingly.

  • Team Topologies: The framework by Matthew Skelton and Manuel Pais formalises this principle in four team types (stream-aligned, platform, enabling, complicated subsystem).

Focus: Architecture is People Work

No technical decision is purely technical. Every architecture decision is also an organisational decision.

FAQ

Does Conway's Law apply to small teams too?

Yes, on a smaller scale. Even in a five-person team, informal ownership boundaries emerge that mirror the codebase.

Do we need to reorganise constantly?

No. But for major architectural changes (e.g. monolith to microservices) the team structure must be considered in parallel, otherwise the migration will fail.

References


Related topics

  • Methods: DDD, the domain method behind Conway's Law.
  • Technology, the technology section that frames Conway's Law.

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.