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

What's really being asked

This question tests your understanding of the 'Inverse Conway Maneuver'. It assesses if you can think strategically about the relationship between organizational structure and software architecture. Interviewers are looking for senior candidates who see software development as a socio-technical system, where team design is a powerful lever to achieve technical goals. It separates candidates who simply observe Conway's Law from those who know how to use it as a tool.

The full answer

A strong answer addresses four key points in order. First, start with the desired architecture. For microservices, this means identifying the bounded contexts that will become services. Second, explicitly name the 'Inverse Conway Maneuver' and state the goal: to structure the organization to produce that desired architecture. Third, propose creating small, autonomous, cross-functional teams (e.g., 5-9 people) and assign each team full ownership of one or more services. Fourth, emphasize that inter-team communication must mirror the desired inter-service communication. That is, it should be formal, asynchronous, and via well-defined interfaces, just like API calls.

The mistakes people make

A major red flag is suggesting you can 'fight' or 'ignore' Conway's Law. This shows a lack of experience with how human systems behave. Another common mistake is proposing activity-oriented teams (e.g., a 'frontend team', a 'database team'). This structure directly encourages the creation of a layered monolith, which is the opposite of the desired microservices architecture. Finally, a weak answer might suggest creating many small teams without considering the new communication overhead, which simply trades one problem for another.

What usually comes next

Expect questions like: 'How would you transition a large team on a monolith to this model?' (Hint: Apply the Strangler Fig pattern to the organization, peeling off one small team at a time to own a new service). Or, 'What are the costs of this approach?' (Hint: Coordination overhead, potential for duplicated effort, tooling complexity). Or, 'Does this apply to a 10-person startup?' (Hint: No, a single team with high-bandwidth communication will naturally build a monolith, which is often appropriate at that scale).

A concrete example

An architect leading a project with six teams in six different cities made their first decision: 'There will be six major subsystems.' They did this before knowing what the subsystems were. They recognized that the high communication friction between cities would make tight coupling impossible. By pre-deciding on six subsystems, they forced an architecture that respected the communication boundaries of the organization, leveraging Conway's Law from day one.