Chapter 14 — Metrics for Delegation

Report the horizon with the metric, or the metric is not a claim.

14.1 What a metric must earn

Metric chapters fail the same way process chapters do: fifteen plausible indicators, none justified, all gameable, and no team implements more than three. So the standard, applied to every metric below without exception.

1. A decision. Name the choice this number changes. A metric that informs no decision is a report, and reports accumulate until nobody reads any of them.

2. A guardrail. Chapter 3 showed the mechanism precisely: an enterprise hit its target of merged pull requests per engineer while average pull-request size grew by roughly a third [B]. Nobody gamed anything. The metric was met honestly, and meeting it honestly required the batch growth that made the underlying goal harder. A count is not a measure unless its unit is fixed, so every count in this chapter is paired with the guardrail that holds its unit still.

3. A window. Chapter 3 established that "no quality penalty" means nothing without "measured over twelve months on merge and revert rates," and Chapter 4 showed the acute and chronic proxies disagree because they sample different horizons. Every metric here carries a window, and §14.8 explains why mixing them on one screen is actively harmful.

4. A stated gaming mode. Goodhart's law is not a risk to be managed; it is a certainty to be pre-empted. If you cannot say how a metric will be corrupted, you have not understood it well enough to publish it.

14.2 Keep the four keys

First, what does not change.

Chapter 5 §5.8 argued that ADLC contains DevOps rather than replacing it, and DORA's own 2025 finding is the evidence: AI is an amplifier, and the seven capabilities determine whether its benefits reach the organisation at all [C]. That makes the capability base necessary and insufficient — not obsolete.

So deployment frequency, lead time for changes, change failure rate, and time to restore stay. Two of them matter more than before:

• Change failure rate, because DORA 2025 found AI adoption raising throughput and delivery instability simultaneously. This is the metric on which the trade shows up.
• Lead time for changes, because §14.3 uses its decomposition to measure the constraint.

Anyone selling ADLC as a replacement for the four keys is selling something this book does not endorse. What follows is additive.

14.3 Measuring the constraint

Chapter 3 established that verification capacity is the binding constraint, modelled the team boundary as a queue, and then admitted a gap: the account was "a model fitted to reported symptoms, not an estimate from instrumented queues," and that nobody has published review utilisation as a first-class metric. This section pays that debt.

The quantity of interest is ρ = λ/μ: arrival rate of review-demanding work over review service capacity. As ρ approaches 1, time in system diverges, which is why "we doubled output" and "delivery did not improve" are the same sentence.

The obvious approach — count arrivals, estimate capacity from headcount and hours — fails immediately. Reviewer capacity is not headcount × hours; it is the rate at which reviews can be completed at adequate quality, and adequate quality is exactly the thing that silently degrades under load. Any μ you compute from staffing is a fiction that assumes away the phenomenon you are trying to detect.

So do not measure ρ directly. Infer it from the queue's behaviour, which is observable.

The signature of an approaching saturation point is not that waits are long. It is that waits respond disproportionately to arrivals. Below the knee, a 20% increase in arrivals produces roughly a 20% increase in waiting. Near the knee, the same 20% produces 60% or 100% or more, because the queue's response is convex.

Definition. Over a fixed window, compute the percentage change in λ (review-demanding items arriving) and in W (time from open to first human review — excluding automated review events, per the enterprise study's own methodological choice [B]). Their ratio is the saturation elasticity.

The decision it informs: whether adding generation capacity will produce any delivery at all. Above 2, it will not — additional arrivals convert into queue rather than into throughput, and the correct action is on μ (Chapter 3's valve 4, mechanising verification) or on the work itself.

The guardrail: batch size, for the reason §14.4 derives.

The gaming mode: W collapses to near zero if reviews are performed nominally — the Review Collapse of Chapter 21. So W must be paired with a scrutiny proxy: human review comments per unit of change, or first-pass acceptance rate. A W that falls while acceptance rate stays flat is capacity relief. A W that falls while acceptance rate rises is a warning, not a win.

Window: quarter on quarter, because the elasticity is a comparison of two periods.

14.4 Batching is a false relief valve

Chapter 3 listed four responses to a saturating queue, and observed that a real enterprise pulled two of them: it enlarged batches and it mechanised review. The first deserves an analysis it did not get there, because the result is stronger than "big pull requests are hard to review."

Take utilisation ρ = λ/μ, where μ is measured in the same units as λ — items per unit time. Now halve the number of pull requests by doubling their size.

• λ halves. Fewer items arrive.
• Service time per item roughly doubles. So μ, in items per unit time, roughly halves.
• ρ = λ/μ is unchanged.

Batching does nothing to utilisation and everything to reviewability. It feels like relief because the queue is visibly shorter, and the queue is shorter because each item is bigger.

Two consequences.

This is why small batches is a capability rather than a preference. DORA identifies working in small batches among the seven capabilities that determine whether AI's benefits reach the organisation [C] — an empirical correlation. Figure 14.2 supplies the mechanism: batching is the intuitive response to queue pressure, it does not work, and it costs reviewability, which is the thing under pressure. A team that batches under load has taken the one action that looks like relief and provides none.

And it constrains how the Chapter 3 evidence should be read. The telemetry showing +98% merged pull requests, +91% review time, and +154% average pull-request size [D] is consistent with service-time growth from larger items rather than queue-wait explosion — if "review time" there denotes per-item cycle time rather than queue wait, which the source does not make explicit. Both are ρ increases; they have different remedies, and the elasticity in §14.3 distinguishes them only if W is defined as wait, not as duration. That distinction is the single most important definitional choice in this chapter.

So: batch size is not a health metric. It is the guardrail on every count in this chapter, and the indicator that the false relief valve has been pulled.

14.5 Delegation metrics

Four. Each answers a question Chapter 13 raised and could not settle.

Three notes.

Rework rate is the guardrail that makes acceptance rate honest, and it is an adaptation of GitClear's churn concept — newly added code revised within a short window, which they measure at 5.5% (2020) → 7.9% (2024) [C]. A first-pass acceptance rate rising while rework rate rises with it is not an improvement; it is work moving from before the merge to after it.

Escalation quality is the most under-appreciated metric here. Chapter 13 makes A3 conditional on an agent behaving sensibly within a topology, and the behaviour that matters most is stopping. An agent that never escalates is not confident; it is unable to recognise the boundary of its competence, which is precisely the failure Chapter 8's behaviour harness cannot catch. Track both the rate and the precision, because either alone is gameable.

Autonomy mix is the metric that reveals theatre. An organisation reporting enthusiastic adoption whose merged work is 95% A1 has bought tooling and changed nothing about its process. This is the number I would ask for first.

14.6 Harness metrics

This is the family the field does not have, and Chapter 8 named its absence as an open problem in the literature — how do we evaluate harness coverage and quality, analogous to code coverage metrics?

Harness coverage. Chapter 8 also supplied the constraint that makes it real rather than vain:

Harness coverage = known recurring failure modes with a control that has demonstrably fired in a drill within the review window ÷ known recurring failure modes.

The phrase demonstrably fired is doing all the work. Without drills, coverage degenerates into a count of configuration entries — the number of rules in a context file — which measures effort rather than effect and is exactly the vanity metric Chapter 8 warned against. A control that has never been shown to fire is Böckeler's silent sensor, and by observation it is indistinguishable from an absent one.

And now the honest limit, which I would rather state than have discovered:

Harness coverage measures diligence, not safety. The denominator is known failure modes — the ones you have already met. It is silent about everything you have not yet encountered, and it can read 100% while you are fully exposed to a class of failure nobody has imagined.

That is Taleb's silent evidence in a denominator. Coverage tells you whether you acted on what you learned. It cannot tell you what you have not learned, and any organisation treating a high coverage figure as assurance has made exactly the error Chapter 11 §11.7 identified about benchmarks.

The other three:

Time-to-control is the outer loop's own clock, and it is the metric that tests Chapter 12 §12.7's uncomfortable finding. That section argued a monthly outer loop cannot regulate an inner loop running dozens of times a day — roughly a thousand-to-one mismatch. Time-to-control makes that measurable: if the median is a quarter, the steering loop is a historian. If it is a week, it is a regulator. I know of no organisation that measures this, and it is the one number that would tell a platform team whether its steering cycle is real.

Guide contradiction count is currently unmeasurable and belongs here anyway, because a metric with no detector is a standing statement about a missing tool. Chapter 7 established the exposure: repositories layering CLAUDE.md, AGENTS.md, rules, and instructions, with CLAUDE.md pointing to AGENTS.md in 301 cases [A]. Galster's authors call for research into detecting and resolving these conflicts; Böckeler poses the same question independently. Until somebody builds the detector, this row's honest value is zero and its honest purpose is to make the gap visible on a dashboard rather than in a footnote.

And Chapter 11's security column. Harness coverage takes a second denominator: coverage over the read set — for each artefact class an agent consumes, has a drill placed a payload there and verified the outcome? With the asymmetry that chapter established intact: a failed security drill is no evidence the attack cannot occur, because the adversary does not sample from your distribution.

14.7 Economics

Three, and they are the ones that survive contact with a finance function.

Cost per accepted change = (tokens + compute + human review minutes) ÷ changes merged without rework. The denominator is deliberate: changes that were merged and then reworked within 14 days are not accepted, they are deferred. Decision: is delegation economic for this class of work? Gaming mode: excluding review minutes, which is the dominant term and the hardest to instrument. Window: monthly.

Review load per engineer per week — hours spent reviewing, per person. Chapter 3 identified this as the true capacity constraint, and the enterprise study measured per-reviewer load roughly doubling [B]. Decision: staffing, and whether valve 4 is working. Gaming mode: load falls because reviews became nominal, so pair with the same scrutiny proxy as §14.3. Window: weekly, trended quarterly.

Context efficiency = tokens consumed per accepted change. This is Chapter 6's budget made measurable, and it has a property most cost metrics lack: it moves in the right direction for two different good reasons. It falls when the payload gets better curated (Chapter 6's dilution reduced) and it falls when the graph replaces exploratory search — LocAgent reported an ≈86% cost reduction from exactly that substitution [B]. Decision: whether Ground is working. Gaming mode: cheaper models, so hold model constant or normalise. Window: monthly.

14.8 Health guardrails, and the horizon problem

Chapter 4 was explicit about what these are: "track these as guardrail metrics, not vanity metrics" — you do not optimise them, you watch the shape of the curve, and a guardrail with no threshold and no owner is decoration.

Three: complexity trend, duplication trend, and batch size. The first two are Chapter 4's chronic proxies; the third is §14.4's false-relief-valve indicator and the unit-stability guard for everything else.

Each needs a threshold and an owner, or it is a chart. The threshold does not need to be principled — "if duplication rises for two consecutive quarters, the platform team opens an investigation" is a perfectly good rule and vastly better than watching.

Now the design problem nobody names.

This is Chapter 3's turkey problem in dashboard form. The fast proxies are the ones whose window closes before the documented damage becomes visible, and putting them beside the slow ones trains everyone to read stability as safety.

14.9 What not to measure

The via negativa half, and in this domain it may do more good than everything above.

The last one deserves a sentence because it is the most requested. Every executive wants time saved, and it is the one quantity that cannot be measured at all — it requires comparing against a world that did not happen. Chapter 4 showed the same structure defeats debt measurement. Offer cost per accepted change and review load instead: both are real, both are decisions, and neither requires a counterfactual.

14.10 A minimum viable dashboard

Nobody implements twenty metrics. Here is the set I would start with, chosen so that each is cheap to instrument and none is a vanity number.

Two implementation notes that determine whether this works.

Metric 5 requires failure-mode labels, and that is the genuinely hard part of this chapter. Chapter 12 §12.7 argued recurrence detection must be automatic, and Chapter 12's open questions conceded that classifying failures into modes across sessions is a clustering problem over execution traces with no published method. Until that exists, time-to-control is measured by hand on a sample — which is worth doing, because a hand-measured median from twenty incidents is enormously more informative than nothing.

All five depend on Chapter 12 §12.8's artefacts. A team that does not capture traces, sensor reports, and escalations cannot compute any of them. This is why that section called trace capture the cheapest high-value investment in Part III: it prevents no defect on its own and every measurement here is downstream of it.