There's a phrase attributed to a well-known Argentinian politician that states:
"If you want something not to get done, create a committee."
Conway's Law in Action
Around the same time that politician was in office, Melvin E. Conway published his paper "How Do Committees Invent?" In it, he introduced what we now know as Conway's Law:
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
Have you ever seen a busy homepage that felt more like a power struggle between departments than a user-friendly experience?
That's Conway's Law in action. Teams will ship the org chart.
How Team Structure Impacts Product Delivery
Have you ever seen teams bottlenecked by waiting on each other? Or services named after their internal workings instead of the business model they serve? That's Conway's Law at play: your product ends up mirroring your organization's communication patterns.
Whether consciously or not, businesses design systems that reflect how they communicate internally, or hit walls when trying to go against those patterns.
The rise of remote work has only amplified these challenges, making clear communication structures more critical than ever.
Many companies attempt to overlay "agile" frameworks on top of rigid silos and hierarchies, but no software design can fix organizational structures that introduce friction and delays.
Modernizing architectures isn't just a technical endeavor; it requires aligning team communication with product goals. For instance, migrating to microservices won't help if your team operates as one large unit.
Say you hire an agency that offers you four teams of frontend and backend developers and a central DBA to handle database changes (this comes from an example from Team Topologies):
This structure will naturally lead to separate frontend and backend components and a shared core database:
A shared DBA encourages a single database, and splitting frontend and backend roles leads to separate tiers. If your goal is decentralized data ownership, this structure will work against you.
The Inverse Conway Maneuver
If your teams shape your architecture, what happens when you need a different architecture? This is where the Inverse Conway Maneuver comes into play: instead of letting team structures dictate your software design, you reshape your teams to match the desired architecture.
This strategy, highlighted in the book Accelerate, involves aligning your teams with the architecture that will support fast, independent delivery. When your teams are organized to minimize dependencies and bottlenecks, they can deploy faster and with fewer coordination issues.
For example, if you aim for microservices with decentralized data ownership, team boundaries should reflect service boundaries, with each team owning a slice of the product and its data. A cohesive, autonomous team structure reduces the need for constant high-bandwidth communication, which is crucial for scaling without friction.
However, this isn't easy. You can't simply divide existing teams and hope it works. Most startups shouldn't start with microservices at all.
The smarter path? A modular monolith. A single deployment with well-defined internal boundaries, where modules own their data and communicate through clean interfaces. All the organizational benefits of thinking in services, without the distributed systems headaches.
When you eventually need to scale a specific part of the system, those module boundaries become your extraction points. The Strangler Fig Pattern lets you peel off services gradually, but only when the pain of keeping them together outweighs the cost of splitting them apart.
The goal isn't just technical. It's to create team structures that enhance speed, collaboration, and ownership, enabling growth and innovation at scale.
