Chapter 16 — Team Topologies and the Economics of Review

The only intervention that raises the constraint is the one no team has an incentive to fund.

16.1 The constraint, restated

Chapter 3 established the economics. Generation is elastic — a team multiplies its output by adding tokens. Verification is not. Review capacity does not scale with headcount, for the reason Brooks published in 1975 and nothing has repealed: reviewers need context, contexts diverge, and coordination cost grows faster than the people you add.

Chapter 3 then enumerated the four responses available to a saturating review queue and showed only one raises capacity: mechanise part of verification. Chapter 14 §14.4 sharpened the finding by eliminating the most popular alternative — enlarging batches leaves utilisation exactly where it was while destroying reviewability.

So the answer is known. Build sensors, install a graph, adopt structure, run the steering loop. Parts II and III have spent eleven chapters on how.

And almost nobody does it. Chapter 7's evidence: Context Files in 90.6% of repositories, Hooks in 0.9%–3.2% — the mechanism that puts a computational sensor inside the agent loop is the least adopted of eight [A]. Chapter 15 showed the whole field parked at Level 1.

Chapter 7 explained this with a cost gradient operating on individuals: markdown costs an afternoon, a wired check costs a quarter and an owner. That explanation is correct and incomplete. It accounts for what one engineer chooses on a Tuesday. It does not account for why an organisation with a stated strategy, a platform group, and a budget still ends up at Level 1.

For that you need the second explanation, and it is economic.

16.2 Nobody funds a public good

Consider the harness as an economic object.

It is non-rivalrous: my team using a lint rule does not consume it or diminish its availability to yours. It is non-excludable within the organisation: once a check exists in the shared pipeline, teams benefit whether or not they contributed. Those two properties define a public good, and public goods are systematically under-provided by decentralised actors — not through negligence, but because each actor rationally weighs its full cost against its partial share of the benefit.

This is the wrong side of a free-rider problem, and it is worth being precise that this is under-provision rather than a tragedy of the commons. Nothing is being overused. Something is not being built.

Three consequences follow, and the third is the one that changes what a leader should do on Monday.

Exhortation cannot work. Telling stream-aligned teams that harness work matters does not alter the arithmetic in Figure 16.1. They already know it matters; they are correctly observing that they capture a fraction of the return. A strategy whose implementation step is "teams should invest in quality tooling" has misdiagnosed the failure as cultural.

Neither can decentralised ownership. If every team builds its own harness, you get under-provision and N-fold duplication and — per Chapter 8's Ashby constraint — N separate regulators each sized to its own variety, which is the most expensive possible arrangement.

So central provision is structural, not a preference. Public goods get funded centrally or not at all. This is the economic case for a platform team owning harness work, and it is stronger than the usual efficiency argument, because it says decentralisation does not merely cost more — it produces nothing.

And it reframes Chapter 15's distribution. The field is at Level 1 not because engineers lack judgment but because Level 1 is the only level a single team can fully fund and fully capture. A context file is a private good: your team writes it, your team benefits, the boundary is clean. Levels 2 through 4 are public goods, and the field's distribution is exactly what the theory predicts.

16.3 Who owns the harness

Four arrangements, three of which fail.

Nobody. The default, and Chapter 4 diagnosed its mechanism: the work has no trigger. Drift detection, drills, and retirement are not prompted by any ticket, so they lose every prioritisation contest to work that is. The harness decays until an incident promotes it briefly, then decays again.

Every team its own. §16.2. Under-provision plus duplication plus N regulators.

A central team builds everything. The classic platform failure: the group furthest from the work decides what the work needs, and builds an apparatus that stream teams route around. This one fails for a reason worth naming precisely — the harness encodes failure modes, and failure modes are local. A platform team can build the machinery of a check; only the stream team knows which check.

Platform provides templates; streams own instances; enabling teams move the laggards. This is the arrangement that works, and §16.4 develops it.

To which one role must be added, because Chapter 11 §11.9 requires it. That chapter argued accountability follows the autonomy decision and the harness, not the individual approval — since approval is the gate Chapter 5 showed had collapsed. Accountability requires an accountable party, so:

Every service has a named harness owner. Accountable for: harness coverage against drills, the retirement arm, the autonomy policy and its review date, and the escape rate of §16.7. Not accountable for individual diffs.

This is the "standing role" Chapter 15 priced into Level 3, and it is the smallest organisational change in this book with the largest effect. It converts an ownerless activity into someone's job, which is the only known remedy for work that nothing triggers.

16.4 Four team types, mapped

Skelton and Pais's Team Topologies proposes four team types — stream-aligned, enabling, complicated-subsystem, and platform — and three interaction modes: collaboration, X-as-a-Service, and facilitating. The framework maps onto harness work cleanly enough that the mapping is worth stating rather than improvised.

Two observations that are not in the original framework.

The enabling team is how the Level 1 → Level 2 transition actually happens. Chapter 15 showed the field parked at L1 and argued the move is sideways rather than up: one blocking sensor and a trace store. But that move requires skills a stream team does not have and will not acquire from a document, and it is a one-off — once the first hook exists, the second is easy. That is precisely the profile Team Topologies designs enabling teams for: a temporary, facilitating engagement that raises capability and then withdraws. An organisation that funds a platform team but no enabling team will produce excellent templates that nobody is equipped to adopt.

X-as-a-Service silently requires the variety-reduction commitment. A harness template can only be consumed self-service if it fits the consumer without negotiation. Chapter 8 §8.3 established that a bounded regulator cannot govern an unbounded generator, and Chapter 15 priced the consequence into Level 4: templates require the organisation to commit to a limited set of service topologies. So:

You cannot ship harness templates X-as-a-Service without first bounding the topologies. Attempt it without that commitment and the interaction mode silently degrades to collaboration — the platform team co-developing with each stream team, which does not scale and is how platform groups become bottlenecks.

That is Ashby's constraint arriving as an organisational design failure rather than a technical one, and it explains a pattern most engineering leaders will recognise: a platform team that started as a service and became a queue.

16.5 Review by exception, costed

Everything in Part III assumes review by exception — the reviewer attends to what the sensors cannot express. Chapter 12 built it into the Verify phase; Chapter 13 made it the foundation of a re-founded A2. Chapter 3 promised this chapter would cost it. It has not been costed anywhere, and the arithmetic is unforgiving.

Start from what is measured. In the twelve-month enterprise study, per-capita throughput rose 2.09× and per-reviewer load roughly doubled [B]. If review previously consumed a fifth of an engineer's week, it now consumes something near two-fifths.

To return review to its former share, sensors must absorb roughly half of what reviewers currently do. That is the target, and it is a large one.

Now the question nobody asks: what has to be true for a sensor to remove review time rather than add it?

The mechanism is simple once stated: review by exception saves time only if the reviewer can skip reading. A defect caught after the human has already read the diff has cost review capacity, not saved it. So a sensor reduces load only when it is (a) blocking, so the bad state never reaches a human, and (b) trusted enough to license not looking, which requires the drill evidence of Chapter 8 §8.9.

There is a suggestive datum for this. The enterprise organisation adopted automated review heavily — bots reached roughly 38% of review events and about half of all comment events — and per-reviewer load still roughly doubled [B]. Heavy deployment of review automation coincided with no relief of human review load.

I must state the confound honestly: the study does not decompose review load by cause, and it is entirely possible load would have tripled without the bots. The observation is consistent with Figure 16.3 rather than proof of it. But it is the only organisational-scale evidence available on the question, and it points the same way as the mechanism.

The practical consequence is sharp enough to act on:

Adding a review agent to comment on pull requests will not reduce your review load. It will improve defect detection and increase reviewer workload. To reduce load you must move the control to blocking, and then persuade reviewers to stop reading what it covers — and the second half is the hard part, because it asks people to trust an instrument with their name on the approval.

Which is why §16.7's escape-rate measurement matters: it is the only thing that can make that trust rational rather than merely requested.

16.6 The input you meter is not the input that is scarce

An organisational-design observation that follows directly from Chapter 3's elastic/inelastic distinction, and that almost every organisation gets backwards.

Cost per accepted change decomposes into roughly four terms:

An engineer-hour costs orders of magnitude more than an hour of inference, and the gap is widening in the same direction. So any token expenditure that reliably removes review minutes pays for itself by a wide margin, and the reliability qualifier is doing the work — Chapter 2's iterative search is the standing reminder that spending more can make things worse.

But subject to reliability, the conclusion is uncomfortable for most budgeting practice:

Token frugality is optimising the abundant input. Run more sensors. Run more inferential review passes on the classes where judgment is needed. Run drills. Point agents at the harness rather than only at the product. All are cheap against the constraint, and an organisation economising on them while its reviewers absorb double the load has metered the wrong thing.

Two organisational moves follow.

Report review load as a first-class number. Chapter 14 defines it: hours spent reviewing, per engineer, per week. Until it appears next to token spend in the same review, the two will not be traded off, and the expensive one will keep losing by being invisible.

Fund harness work from the review budget, conceptually. A blocking sensor that removes an hour of review per engineer per week has a return computable in the same units as the salary it protects. This is the argument that wins funding for §16.2's public good, and it is available to any organisation that starts measuring the denominator.

16.7 Can the gate be rebuilt?

Chapter 5 §5.3 established that a pull request was a checkpoint by cost rather than by design, that effort no longer evidences care, and that every surviving gate is computational while every failing gate is social. It then left an open question and said this chapter would gesture at it:

Can review's authority be reconstructed on demonstrated understanding rather than inferred effort? If it can, much of Part III becomes simpler.

Here is a better answer than a gesture, and it arrives with a limit that matters more than the answer.

What does not work. Measuring attention — time in file, scroll depth, whether the diff was opened. These are proxies for effort again, one layer down, and they are gameable in an afternoon. Rebuilding a debased proxy on a weaker proxy is not progress.

What does work, partially: sampling audit. Borrow from statistical process control. You cannot afford to review everything deeply. You can afford to re-review a small random sample of already-approved changes, deeply, and count what was missed. That does not restore the gate. It restores something the gate used to provide incidentally: knowledge of how much is getting through.

And: consequential accountability. Skin in the game, in Taleb's exact sense — the approver bears a share of the consequence, through on-call rotation or by being named in the incident review. This does not measure understanding. It makes misjudging it costly, which is a different and more robust mechanism, because it does not require the organisation to observe anything about the reviewer's cognition.

Now the limit, which is severe and which I would rather state than bury.

So the honest answer to Chapter 5's question is no, with a useful consolation:

The gate cannot be rebuilt. Effort was a free, per-change signal of care, and nothing replaces a free per-change signal. What can be rebuilt is measurement of the gate's leakage — coarse, organisational, and slow — plus accountability that makes leakage costly to the person best placed to prevent it.

And Part III does not become simpler. It becomes, if anything, more necessary: since per-change assurance is unavailable, assurance has to come from controls that act on every change mechanically, which is the whole argument of Part II arriving at the organisational layer.

One thing does improve. §16.5 said the hard part of review by exception is persuading a reviewer to stop reading what a sensor covers. An escape-rate measurement is what makes that a rational decision rather than a leap of faith — you are not asking someone to trust a sensor, you are showing them what gets past it. That is a small thing and it is the difference between a practice that spreads and one that is resented.

16.8 Shapes that work

Pulling it together. Three arrangements, and what distinguishes them.

The one that fails quietly: platform team, no enabling team, no named owners. Templates get built and adoption stalls, because stream teams lack the skills for the Level 1 → Level 2 move and nobody is accountable for making it. The platform team concludes the teams are not serious; the teams conclude the platform is not useful. Both are wrong and the harness does not get built.

The minimum that works. A platform team funding the public good — templates, trace capture, drill infrastructure, the graph. A named harness owner in each stream team, accountable for coverage, retirement, and autonomy policy. And a small enabling capability that embeds to do the first blocking sensor and the first trace store, then leaves.

What it costs. Chapter 15 priced the levels; this is the organisational version. Level 3 costs a named owner per service — a fraction of a role, but a standing one. Level 4 costs a platform team plus an architectural commitment to bounded topologies that is an executive decision, not a technical one, and that will be resisted by every team that wants to choose its own stack. A leader who funds the platform team without making that commitment has bought the cost of Level 4 without its precondition.

Which is where Part III ends, and it ends on a claim about organisations rather than tools.

Chapter 3 identified the constraint. Parts II and III described the apparatus that raises it. This chapter says the apparatus is a public good, that public goods require central provision, that the transition to using them requires a capability most organisations do not staff, and that the whole arrangement rests on measuring an input — review load — that almost nobody currently reports.

None of that is a technology problem, and none of it is solved by better agents.