Conway's Law & Data Modeling

Using Conway's Law to "see" how to model data

When modeling data, it’s often assumed to happen in a vacuum, outside of the boundaries and contours of the organization. This is a massive blindspot. Thankfully, Conway’s Law provides a lens for “seeing” the way data might be modeled in your organization.

This section is part of the upcoming chapter on Organizations and Data Modeling. More to come.

Thanks,

Joe Reis¹

---

Silos are everywhere

“…organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” - Melvin Conway².

In 1968, when computing meant giant mainframes and punch cards, Melvin Conway published a paper called “How Do Committees Invent?”. He couldn't have known it then, but his central observation would become a foundational law for technology and system design, eventually bearing his name: Conway's Law.

Conway's Law states that organizations design systems that mirror their communication structure. The systems and data a company creates will reflect how its teams are organized and how they communicate with each other. If the company is centralized and top-down, this creates hierarchical and siloed communications and systems. By contrast, a flat and decentralized organization will support less rigid and controlled communication patterns.

Conway’s Law allows you to “see” how departments and business units interact, which affects the type of data model you’ll build. Are departments such as Marketing, Sales, and Operations siloed from one another? When different departments or teams operate independently with limited communication, they often develop their own data models and systems, resulting in data silos. This isn't just a technical inconvenience. It's a direct tax on business agility. Every redundant or inconsistent piece of data slows down decision-making, hinders innovation, and erodes trust in the data itself. When data models are fragmented across siloed teams, the result is inconsistent, redundant data, lost trust, and broken integration. This hinders everything, from ML model training to executive reporting, and slows down the organization’s ability to act on data.

Conway’s Law also affects how technology teams interact with each other. If your organization has separate teams for front-end, back-end, and database development, your software is likely to have distinct components with rigid boundaries, reflecting these divisions. Likewise, if software, data, and AI/ML are separate teams, these divisions will also interact accordingly. If these teams must coordinate and communicate due to dependencies, the resulting system will likely have tightly coupled components, making it more difficult to change and maintain. And if communication between teams is slow or inefficient, it can lead to delays and bottlenecks in the development process, resulting in a system with similar limitations. This friction is a primary source of accidental complexity and technical debt. If data ownership is strictly aligned with team boundaries, it can create barriers to data access and sharing. Teams may be reluctant to share their data or may impose restrictions on its use.

Recognizing the gravitational effect of Conway's Law, some organizations use the "Inverse Conway Maneuver." This means intentionally designing their team structure to achieve a desired system architecture. For example, if they want a modular, loosely coupled system, they might create small, autonomous teams responsible for specific components. This is the core principle that enables modern practices, such as microservices architectures or Data Mesh, where teams are given full ownership of a discrete business capability. Of course, as we’ll discuss soon, the enormous weight of the organizational chart must be considered when attempting such a move.

In an ideal world, strive for cross-functional teams comprising representatives from various departments to promote collaboration and create a unified data landscape, free of silos. Foster a culture of open communication and collaboration to encourage the sharing of data and knowledge transfer. Above all, burn Conway’s Law into your brain and learn to use it every time you look at your organization’s structure.

Next, let’s look at some common types of organizations and their impact on how you’ll model your data.

1. Updated August 11, 2025

2. https://www.melconway.com/Home/pdf/committees.pdf