Conway’s Law as Applied Psychology

What is Conway’s Law and why is it psychological?

Conway’s Law is psychological because the communication structures it describes are not merely organizational charts but expressions of trust, authority, and interpersonal dynamics that are encoded, often unconsciously, into the technical boundaries of the systems a team builds.

I did not learn Conway’s Law from a textbook. I learned it from a database that had three separate representations of a student record because three departments built their own intake processes without coordinating. The technical fragmentation was not a design failure. It was a precise, architectural expression of the organizational reality that those three departments did not communicate.

When I later managed the integration of these systems, the technical challenges were trivial. Mapping fields, normalizing formats, building API connectors. The real work was political: convincing three directors that their unique data structures were not reflections of their department’s special complexity but artifacts of institutional isolation. The database schema told the truth that the org chart obscured.

How does Conway’s Law manifest in microservice architectures?

Conway’s Law manifests in microservice architectures when teams create service boundaries that mirror team boundaries rather than domain boundaries, producing systems that are easy to assign but difficult to operate because the technical interfaces replicate organizational silos rather than resolving them.

The microservice movement was partly an attempt to exploit Conway’s Law deliberately: if systems mirror teams, then small autonomous teams should produce small autonomous services. In theory, this is sound. In practice, I have observed the reverse: organizations adopt microservices and then reorganize teams around the services, creating a circularity where the architecture and the org chart reinforce each other’s limitations.

A system I reviewed had 14 microservices for a product with 3 core user journeys. The service count did not reflect domain complexity. It reflected that 14 developers each wanted ownership of a deployable unit. The inter-service communication was a web of REST calls that added 200ms of latency to every user action. The architecture had successfully mirrored a communication structure where 14 people each preferred to own a small service over sharing responsibility for a coherent system.

This is Conway’s Law operating not as a neutral observation but as a warning: if your communication structure is fragmented, your system will be fragmented. If your team dynamics are competitive rather than collaborative, your service boundaries will reflect isolation rather than coherence.

How can teams use Conway’s Law constructively?

Teams can use Conway’s Law constructively by designing their communication structures first and letting the technical architecture follow, rather than defining architecture in isolation and hoping the organization will adapt to it.

• Cross-functional ownership: When I restructured the enrollment data pipeline, I placed a representative from each consuming department on the design team. The resulting schema reflected all three perspectives, not because the technology forced it, but because the communication structure included all stakeholders from the beginning.
• Shared integration ownership: Integration points between systems should be owned by a team that spans both sides, not by one side or the other. When the scheduling platform integrated with the student information system, the failure rate dropped from 12% to under 1% after I established a shared integration team with members from both departments.
• Architecture reviews as organizational diagnostics: I now treat architecture reviews as opportunities to surface organizational dysfunction. When I see a system with redundant data stores, I ask not “why is the data duplicated?” but “which teams are not talking to each other?” The technical question and the organizational question have the same answer.

What does Conway’s Law imply for the future of AI system design?

Conway’s Law implies that AI systems will mirror the communication structures between AI teams and the business units they serve, meaning that isolated AI teams will produce isolated AI features that integrate poorly with the operational realities they are meant to improve.

In the multi-agent systems I have built, the communication patterns between agents mirror the communication patterns I designed between the human roles those agents support. An agent that processes SEC filings communicates with an analysis agent through a structured interface that reflects how a data engineer would hand off to an analyst: validated data, documented assumptions, explicit confidence bounds.

When that interface was poorly designed, because I had not thought carefully about the human workflow it modeled, the agent system produced the same failures that the human workflow produced: misaligned expectations, duplicated work, and outputs that required manual reconciliation. Conway’s Law does not just describe human organizations mirroring themselves in software. It describes any system of communicating entities, human or artificial, encoding its communication patterns into its outputs. The architecture of the system is the architecture of the conversation that designed it, no more and no less.