Skip to content
    Architecture & organization designChapter 9

    Conway's Law

    How communication structures shape software architecture and how to apply the Inverse Conway Maneuver.

    Original guideworking20 minevergreen · reviewed Aug 13, 2026
    Staff+
    Engineering Manager
    Chapter outline

    Brief

    The essential idea

    Conway's Law says that systems mirror the communication structures of the organizations that build them. A centralized DBA serving four product teams naturally encourages a layered architecture with a shared database, coordination queues, high coupling, and dependencies that make change slow even when each team is locally effective.

    The Inverse Conway Maneuver starts with the desired architecture and designs team boundaries to support it. If the target is shared-nothing services, cross-functional teams need end-to-end ownership of clients, APIs, and data stores, while interfaces between teams must be loosely coupled, versioned, and tested so that cross-team communication becomes infrequent and purposeful.

    Decision lens

    Key takeaways

    Architecture reflects communication paths, so refactoring code alone cannot repair every structural problem.

    Centralized specialist functions often become coordination bottlenecks and shared architectural coupling points.

    The Inverse Conway Maneuver aligns team topology with the architecture and flow the organization wants to create.

    Cross-functional, end-to-end ownership reduces high-frequency handoffs and waiting.

    Loose coupling, high cohesion, version compatibility, and cross-team testing preserve autonomy.

    Conway's Law is a diagnostic tool: recurring architectural friction should trigger an examination of team boundaries and communication.

    Workplace experiment

    Apply it at work

    1. 1

      Draw the real communication paths used to deliver one change and compare them with the system's dependency graph.

    2. 2

      Identify one centralized role or shared component that creates recurring queues for several teams.

    3. 3

      Describe a target architecture and the end-to-end team ownership required to support it.

    4. 4

      Define versioning and integration-test policies that let teams coordinate through stable contracts rather than meetings.

    Choose one action, define the observable effect, and keep the first test small enough to reverse.

    Evidence

    Sources and further reading

    Additional sources

    Channel, aggregator, and commentary links confirm the work; they are not the primary source.

    Previous chapterSOLID for Team LeadsNext chapterTeam Topologies — Short Summary