Service per Team
Context
Section titled “Context”You have a sound set of services, drawn around capabilities and subdomains and designed to run autonomously. The point of all that work was speed — teams shipping in parallel without waiting on each other. But ownership has been left vague. Several teams touch the Order service; a shared “platform” team is the only one allowed to deploy Billing; and a change to Shipping needs sign-off from a group that does not really work on it. The architecture is decomposed, but the organization around it is not, and the promised autonomy never arrives.
Problem
Section titled “Problem”Conway’s law observes that a system’s structure tends to mirror the communication structure of the organization that builds it. This is not a slogan but a constraint: if three teams build one service, the service grows three teams’ worth of seams and every change requires three-way negotiation; if one team must touch four services to ship a feature, those four services quietly couple to that team’s release schedule. Shared ownership turns every deployment into a coordination problem — who is allowed to merge, who must review, whose tests must pass, who is on call when it breaks. The cost of a change comes to be dominated not by the code but by the number of people who must agree.
So the forces are: you want each service to be changed and deployed quickly and confidently, but ownership spread across many teams (or many teams crammed onto one service) reintroduces exactly the cross-team coordination that decomposition was meant to remove.
Solution
Section titled “Solution”Service per Team makes ownership explicit and exclusive: each service is owned by exactly one team, and a team owns a small, related set of services end to end — design, code, test, deploy, and operate. No other team deploys your service; no service has two masters. Crucially, you do not let the org chart fall out by accident — you treat Conway’s law as a design tool (the inverse Conway manoeuvre) and deliberately shape teams to match the service boundaries you want.
A team is sized to own its services comfortably — small enough to coordinate within itself, large enough to carry the on-call and delivery load. Teams collaborate the way services do: through stable, published APIs and contracts rather than through shared code or shared deployment pipelines. When team A needs something from team B’s service, it asks across a versioned interface, not by editing B’s code.
The result is that the organization and the architecture reinforce each other. Aligned boundaries mean most changes stay inside one team’s services, so that team can decide, build, test, and release on its own cadence — which is the autonomy the whole exercise was for.
flowchart TB
subgraph TeamA[Team Checkout]
direction TB
SA1[Order Service]
SA2[Cart Service]
end
subgraph TeamB[Team Billing]
direction TB
SB1[Billing Service]
SB2[Invoice Service]
end
subgraph TeamC[Team Fulfilment]
direction TB
SC1[Shipping Service]
SC2[Inventory Service]
end
TeamA -. published API .-> TeamB
TeamA -. published API .-> TeamC
TeamB -. published API .-> TeamC
Note[One team owns each service end to end;<br/>teams collaborate only through stable contracts] Resulting context
Section titled “Resulting context”What you gain:
- Real autonomy and speed. A team that owns its services end to end can design, build, test, and deploy without waiting on anyone, so most changes ship at the team’s own pace.
- Clear accountability. Exactly one team owns each service, which removes the “who is responsible?” ambiguity — for code review, for the deploy pipeline, and for the pager when it breaks.
- An architecture that matches the organization. By shaping teams to fit the desired service boundaries, you stop fighting Conway’s law and start using it; the seams in the system land where the seams between teams already are.
What it costs you:
- Coordination is pushed to the boundaries. Autonomy within a team comes at the price of disciplined contracts between teams. A change that crosses a service boundary still needs cross-team agreement, so badly placed boundaries simply relocate the coordination pain rather than removing it.
- Reorganization is hard and political. Aligning teams to services may mean changing reporting lines and headcount — an organizational change that is slower and more sensitive than any code change.
- Risk of coupling and duplication. Without care, teams either couple through shared libraries and databases (recreating the distributed monolith) or duplicate effort because no one owns the common ground; both need active governance to avoid.
Related patterns
Section titled “Related patterns”- Decompose by Business Capability — capabilities map cleanly onto teams, making ownership easy to assign.
- Decompose by Subdomain — bounded contexts give each team a self-contained slice to own.
- Self-Contained Service — runtime autonomy and team autonomy reinforce each other; a team that depends on no one at deploy time also wants services that depend on no one at runtime.
| Benefit | Trade-off |
|---|---|
| Clear service ownership — no two teams fighting over the same service | Team topology has to be designed before service boundaries |
| High team autonomy — deploy without waiting on another team | A service can outgrow a team that’s too big for it |
| Clear accountability — if a service breaks, you know who owns it | Conway’s Law cuts both ways — reorganizing the org forces you to reshape services |
| Less governance overhead | A new team can inherit a legacy service that’s hard to work with |
Common mistakes
Section titled “Common mistakes”A service nobody owns — a service “owned by everyone” means owned by no one. Symptoms:
- A bug in the service has no team that picks it up.
- No team is on call for it.
- Technical debt piles up because nobody feels ownership.
Team silos — teams work separately while their services are still tightly coupled. Symptoms:
- Deploying service A requires team B’s approval.
- There’s no contract between the services’ interfaces — things break often.
💡 Real-world examples
Spotify: its “Spotify Engineering Culture” post describes the “Squad” model — each squad owns a full-stack slice of the product and can deploy independently. Spotify itself is careful to add: “this is a journey in progress, not a journey completed,” and the picture it paints doesn’t necessarily hold for every squad at every point in time (Spotify Engineering: Spotify Engineering Culture).
Amazon: CTO Werner Vogels said in a 2006 ACM Queue interview, “You build it, you run it” — the team that builds a service also operates it, which puts them in direct contact with customer feedback and makes them care more about reliability (ACM Queue: A Conversation with Werner Vogels).