"Conway's law and team boundaries"

How organisations shape architecture and why staff-level interviews care: Conway's law, aligning services with teams and domains, ownership and on-call, platform teams, contracts between teams, the cost of coordination, and how to discuss team structure in a system design interview.

Reading is half of it. See this used in a real interview: walk through Design DoorDash →

"Organisations design systems that mirror their own communication structure." Conway's law, from 1967, is still one of the most useful ideas in architecture. Systems built by three teams tend to have three big components; teams that do not talk produce interfaces that do not fit. At staff and principal levels, interviewers expect you to consider who builds and runs each part of a design, not just what the boxes do.

Why it holds

Designing an interface between components requires the people on each side to communicate. Where communication is easy (one team), boundaries blur and coupling grows; where it is hard (different teams, time zones, companies), boundaries harden into formal APIs. Over time the architecture converges on the organisation chart, whether planned or not.

The inverse manoeuvre

If structure shapes architecture, you can shape architecture by designing the structure: organise teams around the boundaries you want. For example, if you want independent services for search, ordering and payments, create teams that own each end to end, with clear interfaces between them. See microservices.

Aligning services with teams

Good boundaries follow business domains (ordering, payments, catalogue, logistics), not technical layers (a "database team", a "frontend team"):

• A team owns a service end to end: code, data, deployment, on-call, roadmap.
• Each service owns its data; other teams use its API or events, never its database. See event-driven architecture.
• Team size limits service count: a team of six cannot responsibly own twenty services.

Layered teams force every feature to cross several teams, multiplying coordination and slowing delivery.

Contracts between teams

Where teams meet, invest in interfaces:

• Versioned APIs and event schemas with compatibility rules. See schema evolution and serialization.
• Data contracts for datasets other teams depend on. See data quality and data contracts.
• SLOs that describe what consumers can rely on. See SLIs, SLOs and error budgets.
• Consumer-driven contract tests so providers know when they would break someone. See testing distributed systems.

Platform teams

Cross-cutting capabilities (deployment pipelines, observability, data infrastructure, identity, payments integration) are built once by platform teams and offered as self-service products to stream-aligned teams. This prevents every team from rebuilding the same plumbing and keeps standards consistent. See Kubernetes for system design interviews and observability and operations.

The cost of too many boundaries

Every boundary adds network calls, failure modes, versioning and coordination. Splitting a small organisation's product into dozens of services creates a distributed monolith that is harder to change than the original. Start with fewer, well-chosen boundaries; split when a team's scope or the system's load demands it. See migrating legacy systems with the strangler fig pattern.

Ownership and operations

• Every service, dataset, queue and dashboard has an owning team in a service catalogue.
• On-call follows ownership: the team that changes the code carries the pager. See incident response and postmortems.
• Shared components without owners decay; give them owners or retire them.

In the interview

At senior levels, a sentence or two is enough: "Ordering, payments and dispatch are separate services owned by separate teams, communicating through versioned events, so each can deploy independently; the payment team owns the ledger and exposes an API rather than shared tables." At staff level, you might discuss phasing ("one team builds the first version as a modular monolith; we split payments out when a second team forms") and platform investments. See Design DoorDash, Design a Payment System and what interviewers expect at each level.

Checklist

• Expect architecture to mirror team communication.
• Draw service boundaries along business domains, owned end to end.
• Services own their data; integrate through APIs and events.
• Contracts, SLOs and contract tests at team boundaries.
• Platform teams for shared capabilities.
• Fewer, better boundaries; split when teams and load require.
• Clear ownership and on-call for everything.