How would you apply Conway's Law to design team structures?

What's really being asked

This question tests your understanding of the socio-technical nature of software development. It's not about reciting the definition of Conway's Law, but about demonstrating how you would proactively use it as a strategic tool—the 'Inverse Conway Maneuver'—to shape your organization and achieve a desired architectural outcome like microservices. It separates candidates who see architecture as purely technical from those who understand it's deeply intertwined with people and communication.

The full answer

A good answer covers four key points. First, briefly define Conway's Law: organizations design systems that mirror their communication structures. Second, state the core principle of not fighting the law, but using it. Third, explain the 'Inverse Conway Maneuver' for microservices: structure teams around specific business capabilities or bounded contexts. Each team should have full ownership of their service(s), from development to deployment and operations. Fourth, describe the desired outcome: these small, autonomous teams with limited, well-defined communication channels will naturally produce small, autonomous services with limited, well-defined API boundaries.

The mistakes people make

A common wrong answer is to simply define the law and stop, or to describe fighting it. For example, suggesting you can mandate a microservices architecture while keeping teams structured by technical layers (e.g., a UI team, an API team, a database team). This structure will always pull the architecture back towards a layered monolith, as cross-team communication is required for every single feature, creating high coordination overhead and tight coupling. Another red flag is treating Conway's Law as an unbreakable, negative force rather than a neutral observation that can be leveraged for positive outcomes.

What usually comes next

Expect follow-ups about the practical challenges. For example: 'How would you handle cross-cutting concerns like authentication or logging in this team structure?' or 'What do you do when a feature requires changes across three different service teams? How do you manage that dependency?' or 'How do you decide on the team boundaries? What if you get them wrong?'

A concrete example

To achieve a microservices architecture for an e-commerce site, you wouldn't have a 'frontend' team and a 'backend' team. Instead, you would create a 'Payments' team, a 'Product Catalog' team, and a 'User Profile' team. The Payments team owns the entire vertical slice of their domain: the UI, API, and database for processing payments. Their communication with the Product Catalog team is limited to a formal API call to get product prices. This organizational boundary enforcement encourages the creation of a distinct, loosely coupled Payments microservice.