Team design and delivery health
How your teams are split decides what your software looks like and how fast it can change. This lesson shows you how to draw clear team boundaries and ownership, how to measure delivery and developer experience with a few well-defined numbers, and how to use those numbers to learn without turning them into a ranking.
By the end you can
- Use Conway's law and an ownership map to find boundaries that slow your teams down
- Apply Team Topologies' team types, interaction modes and cognitive load to two small teams
- Define and calculate DORA's four key metrics from your own deploy data
- Combine survey signals (SPACE, DevEx) with system data to find where work waits
- Measure AI-assisted teams by outcomes and stability, and keep metrics away from individual rankings
The everyday picture
A busy restaurant kitchen has stations: grill, salads, pastry. Each station owns part of the menu. When the grill cook also has to take supplier deliveries, fix the cold room and cover pastry on Fridays, plates come out late and sometimes burnt. Nobody is lazy. The station simply holds more than one person can keep in their head during a rush.
A good head chef checks the health of the kitchen with two kinds of numbers: how long a ticket takes from order to plate, and how many plates come back. When tickets slow down, she walks the line and asks where plates are waiting. She never pins up a chart of "fastest chopper of the week", because she knows what would happen: cooks would chop fast and badly to win it. That is this lesson in one picture: design the stations, watch the flow, and use the numbers to find problems instead of people to blame.
Conway's law and the ownership map
In 1968 Melvin Conway published a short paper, "How Do Committees Invent?", in Datamation magazine. His argument became known as Conway's law: organisations that design systems produce designs that are "copies of the communication structures of these organizations".
The mechanism is simple once you see it. Where two people talk every day, the parts they build fit together tightly and change together easily. Where two teams rarely talk, the parts between them get a thin, formal interface that changes slowly, because every change needs a meeting, a ticket or a contract. So the lines on your org chart become the seams in your code, and the seams are where work waits.
You can see it in the Partner app. Until this year an outside agency, Lagoon Digital, built all of it. The invoicing module still sits behind an API that Lagoon owns, and every change to it goes through a ticket to Lagoon, an update to the contract and a test in Lagoon's staging environment. The "pay invoices with a mobile wallet" feature crosses exactly that seam. When Lagoon changed the invoicing API late, the feature slipped about three weeks. The code boundary is the contract boundary.
Conway's law works in both directions. If you shape teams to match the architecture you want, the architecture tends to follow. People call this the inverse Conway manoeuvre. It also means that splitting code into more services does not fix a team problem (Monolith, modular monolith, microservices). Fix who owns what, and how teams talk, first.
The tool for this is an ownership map: one table listing everything that can break or need changing, with exactly one owning team per row.
- List the things. Apps, backend services, scheduled jobs, databases, dashboards, alerts, vendor contracts. Ask each tech lead and look at your repositories and on-call pages.
- Give each row one owning team. "Shared" or "both" means nobody. The owner may accept changes from others, but they decide and they answer the pager.
- Add how others use it. As a service through an API, together for a time, or with help from another team.
- Mark the hand-offs. For the last sprint, count the tickets that needed another team or Lagoon before they could finish. If most of a feature's tickets cross one boundary, either the boundary is in the wrong place or the way the teams work across it has to change.
- Close the gaps. Every row with no owner gets one, or gets switched off. Review the map each quarter and whenever a team changes.
Quick check
The Store app team and the Partner app team both change the shared product catalogue service, and their changes keep breaking each other's app. Which fix follows from Conway's law?
One owner with a clear interface turns a messy shared seam into a clean one, and someone answers for it. A joint approval meeting adds a slow hand-off to every change and still leaves ownership unclear. Two copies drift apart and double the work. One team of eleven is too big to coordinate well and hides the problem instead of fixing it.