To make the Inverse Conway Maneuver work in practice, you must change not just who is on which team, but how teams talk to each other. The communication style between teams directly determines the coupling between their services.
Intra-Team vs. Inter-Team Communication
There are two fundamentally different communication modes in a well-structured engineering organization:
- Intra-Team (Inside the Squad): High bandwidth. Face-to-face conversation, constant Slack, shared context, shared codebase access, shared on-call rotation. This creates tight coupling in the software — which is desirable inside a microservice, where cohesion is a virtue.
- Inter-Team (Between Squads): Low bandwidth. Defined contracts, public documentation, versioned APIs, formal feature requests. This creates loose coupling in the software — which is desirable between microservices, where independence is a virtue.
The coupling level in your software will mirror the communication bandwidth between your teams. This is Conway's Law in action, and you can use it deliberately.
Defining the Interface
If the "Checkout Team" needs something from the "Inventory Team," they shouldn't walk over and ask someone to change a variable or grant them direct database access. That informal, high-bandwidth interaction will produce tight coupling — the Checkout service will start depending on Inventory's internal implementation details.
Instead, the Checkout Team should treat the Inventory Team like a third-party vendor:
- Check the Documentation — Does the Inventory API already support what we need?
- Use the public API — Call the documented endpoint; don't reach into the database.
- Submit a formal Feature Request — If the API is missing something, open a ticket describing the need, not the implementation. Let the Inventory Team decide how to implement it.
This isn't bureaucracy for its own sake. It's enforcing the software boundary through the team interaction model. When teams interact like API consumers and providers, their services naturally develop clean, stable interfaces.
The Team API Concept
Team Topologies formalizes this as the Team API — the full set of ways a team interacts with the outside world: their service's API, their documentation, their on-call process, their versioning policy, and their communication channels. Treating all of these as a designed interface — not an afterthought — is what separates teams that produce maintainable services from teams that produce distributed monoliths.