What is Conway's Law?
Conway's Law is an influential observation made by computer programmer Melvin Conway in 1967. It states that organizations which design software systems are bound to produce designs that copy the communication structures of those organizations. In simpler terms, the way your company's teams are structured and communicate directly dictates how your codebase is organized and how different modules interact.
A Real-World Analogy: City Infrastructure
Imagine a city planning department split into three isolated teams: the Road Department, the Water Department, and the Electricity Department. Instead of sitting together to plan a street, the Road Department builds a freshly paved highway. A month later, the Water Department tears up the new asphalt to lay down water pipes because they never coordinated. Finally, the Electricity Department digs up the street again to bury power cables.
Because the teams operated in strict isolation, the final street structure becomes a chaotic, patched-up mess with redundant dig sites. Had the city restructured these workers into a single neighborhood planning squad, the street, pipes, and cables would have been laid smoothly in one unified pass.
Why Conway's Law Matters in Daily Tech Operations
In software engineering, Conway's Law manifests every day in system architecture, API boundaries, and technical debt. When leadership divides engineering strictly by technical layers—such as a dedicated React frontend team, a Node.js backend team, and a MySQL database administration team—the resulting software predictably develops rigid, overly complex network boundaries between those layers.
Developers spend endless hours writing boilerplate translation code, serializing JSON payloads back and forth, and waiting on pull request approvals across organizational boundaries. Conversely, when companies form cross-functional "feature teams" aligned around business domains (like Checkout or User Auth), the codebase naturally evolves into clean, modular services or domain-driven modules. Understanding this law prevents software architects from fighting against their company’s org chart and helps managers restructure teams to achieve better technical designs.
Concrete Scenario: E-Commerce Team Restructuring
Before (Siloed Teams)
An e-commerce platform is built by three separate departments: a React UI team, an Express.js API team, and a MySQL DBA team.
To display a user's account dashboard, the React frontend must make three separate HTTP requests to the Express server (/api/users, /api/user-permissions, and /api/user-cart) because three different backend sub-teams created those routes independently. Furthermore, the Express API requires complex DTO (Data Transfer Object) mapping because the database team maintains a legacy MySQL schema and requires formal ticket submissions for schema modifications.
Result: High network latency, duplicated state management in React, and heavy database query bloat.
After (Domain-Driven Feature Team)
The organization restructures into a cross-functional "Checkout Domain Team" containing a React engineer, a Node.js developer, and a MySQL expert working side-by-side.
The team simplifies the API down to a single optimized Express route (GET /api/dashboard). The Express endpoint executes a streamlined SQL query using MySQL JOIN statements, returning all required dashboard data in a single payload. The team deploys updates together without inter-departmental bureaucracy.
Key Takeaway
You cannot fix a messy software architecture purely with code refactoring if your team structure enforces the mess. If you want modular, loosely coupled, and maintainable software, you must first design loosely coupled, clear, and collaborative team communication channels.
Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!
Originally published on my blog. You can read the alternative breakdown here.
Top comments (0)