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.
But this doesn't mean a startup should begin with microservices. That would typically be overengineering, and the services would probably have the wrong granularity. Early on, you still don't understand the cohesion and coupling of the business entities well enough to know where the boundaries belong.
Dividing the software into autonomous running pieces makes almost everything harder: debugging, troubleshooting, understanding the system, latency, and error handling, among other things.
It's better to conquer first, then divide. Start with a modular monolith: a single deployment with internal boundaries, where modules own their data and communicate through defined interfaces. Use it to learn which parts of the business belong together and which ones keep pulling apart.
Once you understand those boundaries, you can break the system down into microservices where doing so is actually useful. The module boundaries become extraction points, and the Strangler Fig Pattern lets you move them out gradually.
The sequence matters. First learn the shape of the business and the software. Then decide which parts need independent teams and independent deployments. Conway's Law still applies; you are simply waiting until you understand what you are organizing around.
