How your organization shapes your software
Understanding Conway's Law
Have you ever wondered how some organizations decide on their structure? How do they decide who reports to whom? Which teams collaborate together whereas others are placed apart?
Regardless of who makes these decisions, the structure of an organization will have an effect on the software that is produced. This is known as the Conway's Law1 (based on his article titled “How do committees invent?“)
Conway argues that there is a two-way relationship between a company's structure and its software architecture. A rigid, top-down team structure often leads to unusual architectural patterns. Similarly, a monolithic system with poorly defined boundaries tends to result in teams that are also poorly defined.
Where is the link
The link between organizational structure and system architecture lies in the way teams communicate and collaborate. When teams are structured around specific functions or departments, the systems they build often reflect these boundaries. For example, if a company has separate teams for frontend and backend development, the resulting system might have a clear separation between frontend and backend components. While this can work well in some cases, it can also create inefficiencies when changes require coordination across multiple teams.
A real-world example of this can be seen in e-commerce platforms. Imagine a company where the product catalog, search, and checkout systems are owned by different teams. If these teams are siloed and rarely collaborate, the systems they build might have poorly defined integration points, leading to a fragmented user experience. Conversely, if the organization is structured around user journeys—such as a team owning the entire "browse and purchase" flow—the resulting system is more likely to have seamless integration, as the team is incentivized to optimize the entire experience rather than just their individual components.
The mess you’re in
You shouldn't worry if your organization or architecture is a mess. It's natural for structures to evolve chaotically over time. In such cases, Conway's Law can actually be leveraged to your advantage.
If you want to change your system architecture into a more modular one, start by restructuring your teams. Once you have the right teams configured appropriately, the architecture will naturally evolve in the desired direction.
This transformation won't happen overnight. It requires patience and persistence, but gradually, the system architecture will begin to mirror your new organizational structure. By intentionally designing your organization to reflect your desired technical architecture, you can guide your systems toward a healthier structure.
Map and Align
To leverage Conway's Law effectively, you first need a clear understanding of both your organizational structure and system architecture. A comprehensive, though not necessarily perfect, view of how different system components interact is essential.
Mapping Your Organization
Most companies have HR tools that can export the current organizational structure. This gives you a visual representation of reporting lines and team compositions.
Often, the structure that organically emerges in an organization feels logical at first glance. The marketing department might have an Ads team and an A/B testing team, while a communications department might have email and in-app communications teams. This division seems natural until you examine the actual workflows. For example, if the Ads team heavily relies on email campaigns for their advertising efforts, then separating them from the email team creates unnecessary coordination overhead. In such cases, it would make more sense to structure teams around these workflow dependencies rather than traditional departmental boundaries.
Ultimately, you should have something similar to the following diagram:
Mapping Your Architecture
With your organizational map in hand, you can then document your system architecture. The C4 Model2 provides an excellent framework for this purpose. Start with Context and Container diagrams to gain sufficient understanding.
Context diagrams offer a high-level system overview, helping you engage with individual teams as they create more detailed container-level diagrams.
For more sophisticated mapping, consider using graph databases like Neo4j3. These tools excel at visualizing complex relationships between systems and teams, making it easier to identify misalignments.
Visualizing the Relationship
In the visualization below, we've mapped both teams (represented as blue nodes) that belong to the same track and the systems they own (represented as red nodes). The solid lines connecting blue nodes to red nodes indicate ownership relationships, which team is responsible for which system. Meanwhile, the lines between red nodes represent dependencies between different systems. This dual-layer mapping reveals where organizational and architectural structures may be misaligned. When a system has many dependencies with systems owned by different teams, it suggests potential communication bottlenecks and coordination challenges. Ideally, systems with strong interdependencies should be owned by teams with equally strong collaboration channels, minimizing the organizational "distance" that information must travel.
We can see a couple of issues here. Even though these teams all live in the same track, it appears that except for Teams 2 and 4, no teams' ownables depend on each other. This raises the question: should Teams 1 and 3 remain in this organization or be moved elsewhere?
We can also see an interesting balance between the number of ownables per team. Assuming that each ownable has similar complexity and codebase size, if Team 1 is maintaining its systems without issues, it might be worth considering merging Teams 2 and 4 since they have fewer ownables. Conversely, if Team 1 is struggling with its ownership load, it might be wise to adopt a similar approach to Teams 2 and 4 by breaking Team 1 into two smaller teams.
Start to optimize
Once both architectures are mapped, you can identify optimization opportunities. A common goal is increasing delivery speed. This often means arranging your organization so that components that change together are owned by teams that work closely together.
The principle "things that change together should be close together" applies to both code and organizational structure. Teams with similar or interdependent responsibilities should be grouped proximally in the organizational chart, mirroring how their code components interact in the system architecture.
By intentionally aligning your organizational structure with your desired system architecture, you can create a virtuous cycle that improves both over time.
Another valuable optimization target is innovation capacity. When mapping reveals that certain teams are heavily constrained by cross-team dependencies, it may indicate barriers to experimentation. By restructuring to create more autonomous domains, where teams have end-to-end ownership of user-facing capabilities, you can unleash creative potential. This approach allows teams to innovate within their domains without being blocked by organizational boundaries. For instance, if your mapping shows that every feature enhancement requires coordination across five different teams, consider reorganizing around capability-focused teams instead of technology-focused ones. Teams empowered with full-stack expertise and clear domain boundaries can rapidly prototype, experiment, and deliver novel solutions, turning Conway's Law into an innovation accelerator.
Conclusion
Conway's Law reveals that software architecture and organizational structure are deeply intertwined, each influencing the other. By understanding this relationship, organizations can strategically align their team structures with desired architectural patterns. This alignment doesn't happen automatically—it requires intentional mapping, analysis, and restructuring. When done effectively, organizations can optimize for delivery speed, innovation, and overall system health. Rather than fighting against Conway's Law, successful organizations embrace it as a powerful tool for driving positive change in both their teams and their technology.