Team Structure:
Communication and Product Delivery

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—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. It’s more effective to “conquer and divide”—build a working product first, then break it into smaller services once the boundaries become clear.

The Strangler Fig Pattern is a useful technique to transition from a monolith by gradually introducing new services, allowing teams to adapt as the architecture evolves.

The goal isn’t just technical—it’s to create team structures that enhance speed, collaboration, and ownership, enabling growth and innovation at scale.

Need Help Aligning Teams and Product Delivery?

If you need help managing distributed teams effectively, explore my experience as a Remote Team Manager.