MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Teams and ownership

Conway's Law Lab

A product has four business capabilities, each built in five layers from the web app down to the data. The same features arrive every day. Change only who owns what, and watch how many teams each feature needs, how long work waits at handovers, and how much each team has to keep in its head.

Background: Inverse Conway Maneuver, Stream-Aligned Team, Platform Team.

Scenarios
Teams
Work

One new feature arrives every working day for 12 weeks. Each one changes the web and mobile apps, the BFF and the service of its capability, and half of them its data too. Every structure has the same people. A task waits 1 extra day when the layer below it was built by another team, and each team spends a quarter of a day per feature on every other team involved.

Starting
SEARCHBASKETCHECKOUTPAYMENTSWEBMOBILEBFFSERVICEDATAWebMobileBackendBackendDatabaseWebMobileBackendBackendDatabaseWebMobileBackendBackendDatabaseWebMobileBackendBackendDatabase

4 teams · work waiting

  • Web team1 stack, 4 domains0 days
  • Mobile team1 stack, 4 domains0 days
  • Backend team2 stacks, 4 domains · 86% speed0 days
  • Database team1 stack, 4 domains0 days
–Features shipped of 0 started
–Average lead time, days (open features count days waited)
100%Features needing 2+ teams
3.1Handovers per feature
0204060wk 2wk 4wk 6wk 8wk 10wk 12dashed: features started · blue: shipped · red: in progress
Guided experiments

Run these in order

  1. Organise by layer

    Give web, mobile, backend and the database a team each. Every feature needs three or four of them, and work waits at each handover from the database team to backend to the clients. Each team is expert in its stack, but nobody can ship a feature alone.

  2. Organise by capability

    Give each capability one team that owns every layer. Most features now need only one team, yet lead time gets worse: each team must master five stacks, and that cognitive load slows everyone down. Owning a slice end to end only works if the team is not carrying all the plumbing too.

  3. Add a platform

    A platform team provides each layer's foundations. The same capability teams now carry half the load per stack and work at full speed. Lead time roughly halves compared with layer teams. This is the combination of stream-aligned teams and a platform.

  4. Keep a central database team

    Leave the data layer with one shared team. Every feature that changes data now crosses a team boundary and waits in that team's queue. The architecture follows: a central database team tends to produce a shared database.

  5. Split into tiny teams

    Give every component its own team. Each team is simple, but a feature now needs four or five teams, coordination eats most of the capacity, and lead time is the worst of all. Smaller is not better when the work keeps crossing the boundaries.

  6. Let the work cross the boundaries

    Make 70% of features also change a second capability. With the best structure from step 3, handovers and lead time climb back up. Team boundaries only help when they follow how the work actually flows. If most features cross two teams, redraw the boundary.

This lab simplifies reality on purpose. Every feature is the same size, teams have no holidays or incidents, and coordination and cognitive load are reduced to two fixed numbers. Real teams also differ in skill, and a platform takes time and people to build, which the lab leaves out. The point is the shape of the results, not the exact days.