← The ADLC library
Live debates · 34

Small teams, big blast radius

A six-person team now ships at a volume that used to require sixty people, and it is doing it with none of the coordination machinery sixty people were forced to build. The risk profile changed. The controls did not.

Small teams have always been the recommended shape, and for good reasons. Less coordination overhead, faster decisions, everyone knows what everyone else is doing. That last clause was never a cultural nicety. It was a control, and it was doing more work than anyone gave it credit for.

My position: the informal controls that made small teams safe were the first thing agentic delivery broke, and they broke silently, because nothing about the team changed. The headcount is the same, the standup is the same, the vibe is the same. Only the volume moved, and every implicit control in a small team is a function of volume.

The control you never wrote down

Ask a six-person team how they prevent two people from making incompatible changes to the same subsystem in the same week. You will not get a process. You will get “we would know.”

They would have. Six people producing at human typing speed generate a number of changes per week that fits inside a fifteen-minute standup and a shared channel. Everyone hears everything. The coordination cost is near zero because the coordination happens as a side effect of being a small group of people talking.

Large organisations do not have that, which is why they built the machinery: ownership registers, change advisory, architecture review, release trains. That machinery is slow and much of it is theatre, but it exists because implicit coordination fails past a certain volume of change, and large organisations hit that ceiling first.

Now a small team hits the same ceiling without growing.

What scaled with headcount

  • Salary cost
  • Meeting load
  • Onboarding overhead
  • Communication paths
  • Political friction

What scales with change volume

  • Chance of two changes colliding
  • Surface area touched per week
  • Number of decisions nobody discussed
  • Time to reconstruct what happened
  • Blast radius of a bad Friday
Teams optimised hard against the left column. Everything that actually hurts you lives in the right one, and it moved without the left column moving at all.

What the numbers do while this happens

This is the part that makes it hard to catch. Your delivery metrics improve.

Deployment frequency goes up. Lead time goes down. Change failure rate holds, at first, because the individual changes are fine. Nothing on the dashboard says a six-person team is now operating a surface area it cannot collectively describe.

The signal shows up somewhere else, and usually late: in the character of your incidents. Not the count, the character. Incidents that used to be “we shipped a bug” become “two changes interacted”, “a dependency changed underneath us”, “this was configured for a case that no longer exists”. Those are coordination failures, and coordination failures are what large-organisation machinery exists to prevent.

If you want an earlier signal, count changes per week per person who read them. Not per engineer. Per reader. That ratio is the honest measure of whether your implicit control still functions, and in most teams that have adopted agents seriously it has moved by a factor nobody chose.

The trap on both sides

The wrong response is to install the machinery. A six-person team that adopts change advisory boards has taken on the cost structure of an enterprise to solve a problem it has one instance of. You will lose the speed that made the team worth having and you will not get the safety, because the machinery large organisations run mostly works through the people it forces into a room, and you already had those people in a room.

The other wrong response is to insist nothing has changed, which is what most teams are doing, because the standup still feels fine.

What actually helps is picking the smallest number of explicit artefacts that replace the specific implicit control that broke.

An ownership map that fits on one screenSubsystem, one named person who could explain it, date last verified. Not a RACI. The point is to make the empty cells visible.
A named blast-radius classOne short list of change types that get a second pair of eyes regardless of size: auth, money, data deletion, anything touching a shared contract. Everything else runs at full speed.
A change record with the decision attachedWhat changed, under which ticket, on whose authority. This is what replaces "we would know" once you no longer would.
A weekly ten minutes on surface, not statusNot what everyone did. What areas got touched this week that nobody expected to be touched. Different question, different answers.
Four artefacts, none of them a process. Each one exists to replace a specific thing that used to happen by accident when the volume was lower.

Why the last one matters most

The weekly ten minutes on surface area is the one teams skip, and it is the one that recovers the most.

The implicit control was never really about knowing what people were working on. It was about noticing when something unexpected got touched. A standup answers “what are you doing”, which is now a question about intent, not about effect. The effects have multiplied and detached from anyone’s stated intent, because the intent was a ticket and the effect was a change set nobody enumerated.

Ask instead which parts of the system moved this week. Then ask whether anyone expected them to. In a healthy week the answer is boring. In the week before an incident, it usually is not, and somebody in the room notices.

Where this breaks down

Small teams may genuinely be safer, not less safe. Fewer people means fewer conflicting mental models and a shorter path from symptom to the person who knows. Some of what I have described as a lost control was really a lost illusion, and the small team’s real advantage, that everyone can be got hold of in five minutes, is intact.

I am arguing from incident character, which is soft evidence. “Our incidents feel more like coordination failures” is not a measurement. I believe the pattern is real and I would not present it as a finding. If your incident review data can tell coordination failures from ordinary defects, trust that over my impression.

The machinery I am dismissing sometimes works. Change advisory boards are an easy target, and yet organisations with genuinely large blast radii, in payments or in clinical systems, run them because the alternative failed expensively. If your worst case is severe enough, the enterprise answer may simply be correct and my lightweight version is a comfortable evasion.

Every artefact I recommended decays. An ownership map is accurate for about a month. A blast-radius class list gets padded until it covers everything and stops meaning anything. I have described the artefacts as if writing them is the work, and maintaining them is the work.

Volume alone may not be the variable. It could be that what changed is the ratio of changes to comprehension, and a team that reads carefully at high volume is fine. If so, my headline is wrong and the real advice is simply about reading. I think volume dominates, but I hold that loosely.

The takeaway

Small teams were safe because of a control nobody wrote down, and that control was a function of how many changes happened per week. The changes per week moved. The team did not.

The fix is not to become an enterprise. It is to make explicit the two or three things that used to happen by accident: who owns what, which changes deserve a second reader, and what surface area actually moved this week.

If you take one thing into next week: work out your changes per week per person who reads them, then compare it to the same figure from a year ago. That ratio is what your informal coordination is now being asked to absorb.