The Cost of Coordination

Technical trade-offs get most of the attention, yet in many organizations the dominant cost is human: waiting for another team, aligning on a schema, negotiating a release window. Coordination is work that produces no feature. A good architect treats it as a first-class cost and designs to reduce it.

Communication grows faster than headcount

If every person must stay in sync with every other, the number of communication paths among n people is n times n minus one, divided by two. Five people have 10 paths; fifteen have 105; fifty have 1,225. This is why adding people to a late project rarely helps, and why a single shared codebase with one deployment gets slower as the team grows.

The same logic applies to services and modules. Every dependency between components is a place where two groups must agree on behavior.

Conway's law is a design tool

Systems tend to mirror the communication structure of the organization that builds them. You can use that deliberately. If a feature routinely requires changes from three teams, the boundaries are probably in the wrong place. The inverse maneuver is to shape teams and boundaries to match the architecture you want.

A quick diagnostic is to examine recent work:

| Signal | What it suggests | |---|---| | Most features touch multiple teams | Boundaries cut across business capabilities | | Teams wait for another team's review or release | Hidden shared ownership | | Frequent cross-team production incidents | Tight runtime coupling | | Coordinated deployments | The services are a distributed monolith |

Kinds of coupling that force coordination

Not all coupling is equal. In rising order of pain:

1. Code sharing. A common library forces upgrades on a schedule. Keep shared code small, stable and versioned.
2. Contract coupling. Teams must agree on API or event shapes. Manageable with versioning and compatibility rules.
3. Data coupling. Two services reading and writing the same tables cannot change independently. This is the costliest form, so give each dataset a single owner.
4. Temporal coupling. Service A cannot work unless B responds right now. Asynchronous messaging relaxes this.
5. Release coupling. Changes must ship together. If this exists, you are paying microservice costs without the benefit.

Reduce coordination on purpose

Several levers lower the cost:

• Align boundaries to business capabilities, such as billing or catalog, not technical layers such as UI team and database team.
• Own data end to end. One team owns each store and exposes it through an interface.
• Publish contracts and keep them compatible. Additive changes by default, explicit deprecation windows for breaking ones.
• Prefer asynchronous integration where business needs allow, so teams do not need synchronized availability.
• Provide self-service platforms. If every team needs to ask the infrastructure group for a database, you have built a queue. Offer templates and paved paths instead.

Coordination is sometimes worth paying

The goal is not zero coordination. A shared authentication model, common observability conventions and consistent security controls justify alignment because inconsistency is costlier. Splitting a small team into five services to avoid talking is a bad trade: you swap conversation for network calls, versioning and distributed debugging.

A practical rule is to keep tightly related things together and loosely related things apart. If two components change together nearly every time, they probably belong in the same module and under the same owner, whatever the diagram says.

Measure it

You can make this visible. Track the share of changes needing cross-team approval, lead time from commit to production, and how often a release depends on another team's release. Rising numbers indicate growing coordination debt. Use them in architecture reviews alongside latency and cost figures.

Key takeaways

• Coordination is a real, often dominant cost, and it grows faster than team size.
• Use Conway's law deliberately: boundaries and team structure should reinforce each other.
• Data coupling and release coupling are the most expensive; give data a single owner.
• Reduce coordination with capability-aligned boundaries, compatible contracts and self-service platforms.
• Do not split purely to avoid talking; measure cross-team dependencies and decide with evidence.