Deployment frequency when merges outpace decisions
The oldest of the four keys was a proxy for removed friction. Under the ADLC it becomes a proxy for something else entirely, and the difference matters more than the number.
Suppose a team of six merges forty pull requests in a week. Last year the same team merged twelve. Nobody was added. Nothing about the deployment pipeline changed. The only difference is that most of the code is now drafted by agents and reviewed by humans instead of written by humans and reviewed by humans.
Here is the question I would want answered before I celebrated: how many decisions did that team make last week, and how many did it make the year before?
I suspect the answer in most cases is roughly the same number. Maybe slightly more. The team still has one product manager, one design review a week, the same number of stakeholders with the same number of opinions, and the same finite capacity to work out what is actually worth building. What changed is not the rate at which the organisation resolves questions. What changed is the number of merges each resolved question now generates.
That is the whole of this piece, really. But the implications take a while to unpack, and some of them are not obvious.
Where deployment frequency came from
Deployment frequency earned its place because of what a low reading used to mean. If a team deployed monthly, that was almost never because they only had a month’s worth of work. It was because something stood between finished work and users: a release train, a change advisory board, a manual QA cycle, a shared staging environment with a booking spreadsheet, an ops team that had to be scheduled. The work existed. It was sitting in a queue.
So deployment frequency was a friction detector. Push it up and you were, mechanically, forced to remove the things that made deploying expensive: automated tests, automated rollbacks, feature flags, trunk-based development, smaller changes. The metric was valuable less for what it measured than for what chasing it obliged you to build.
The essential precondition was that producing the change was the expensive part and moving it through the pipe was the cheap part being made artificially expensive by process. Under those conditions, a rise in deployment frequency was unambiguously good news, because the only lever available to raise it was friction removal.
Now there is a second lever. You can raise deployment frequency by producing more changes. That lever is cheap, it is always available, and pulling it does not require you to fix anything.
The two components hiding inside one number
It helps to think of merges per week as a product of two things that used to move together and now do not.
The first is your organisation’s decision rate: how many distinct questions about what to build, and how, get resolved per unit of time. Product decisions, architectural decisions, “is this bug worth fixing” decisions. This is bounded by human attention, meeting capacity, stakeholder availability and the ordinary friction of getting a group of people to agree. Agents do not move it much. If anything, they load it, because more finished work arriving means more things needing acceptance.
The second is merges per decision: how many discrete changes a resolved question turns into. This used to be close to a small constant. A ticket became one branch and one pull request, maybe two if the work split naturally. Now it can be five, or fifteen, because splitting work into small pieces costs almost nothing when the pieces are drafted for you, and because iteration inside a poorly specified ticket also produces merges.
Deployment frequency is the product of these two. It rose. Which factor rose is the thing the metric will not tell you, and they mean opposite things.
If merges per decision rose because work is being decomposed better, that is a genuine improvement in delivery practice. Small changes are easier to review, easier to revert, and less likely to sit half-finished for a week. Teams have been told to do this for twenty years and the cost of doing it was the thing preventing them. That cost is gone. Take the win.
If merges per decision rose because agents are cycling around underspecified requirements, building, being corrected, rebuilding, then what you are measuring is rework wearing a deployment frequency costume. The number goes up. The organisation is doing more work per unit of value delivered, which is the definition of getting worse.
Both look identical on the slide.
merges/week = decision rate x merges per decision
roughly fixed the factor that moved (one PM, one (better decomposition, design review, or rework cycling on same stakeholders) underspecified work)</code></pre><div class="note">Deployment frequency is the product of these two. It rose. Which factor rose is what the metric will not tell you, and the two explanations mean opposite things: one is a genuine improvement in delivery practice, the other is rework wearing a delivery metric as a disguise.</div>
What a merge even means now
There is a second problem underneath the first, and it is about what event you are counting.
Deployment frequency, strictly, counts deploys to production. Almost nobody measures that directly, because production deploy events live in whatever CD system you happen to run and are a nuisance to extract consistently across teams. So most tooling, ours included, uses merges to the default branch as a proxy.
For a team on continuous deployment that proxy is exact. Merge and deploy are the same event. For a team that batches into a weekly release, the proxy is not just inexact, it is measuring a fundamentally different thing: production of finished work rather than delivery of it. And here is the trap. Under the ADLC, the proxy inflates precisely on the axis where it was already weakest. A batching team adopting agents will see its “deployment frequency” climb steeply while the actual cadence at which users receive anything stays exactly where it was, once a week, forever.
So a metric surface has to state its basis in the same breath as the number. Not in documentation, not in a tooltip, on the surface. “Deployment frequency: derived from merges to the default branch” is a different claim than “deployment frequency” alone, and the reader will use it differently. Every dashboard faces a temptation here, ours included: the number looks better naked, and the basis line makes it look qualified. It is also less true.
Merge as a proxy, batched release
Merges happen daily, deploys weekly
The number measures a different event entirely
Rises without a single extra deploy
Nothing on the dashboard says so
Merge as a proxy, continuous deployment
Merge and deploy are one event
The proxy is exact
The number means what it says
Basis stated on the surface, not in a tooltip
Same metric name, same number, two entirely different claims. The basis belongs next to the figure, in the same breath.
Reading it usefully anyway
I am not arguing you should stop tracking deployment frequency. I am arguing you should stop reading it as a single number and start reading it as a shape. Three habits make it useful again.
Watch the trend of merges per accepted outcome, not merges alone. You do not need new instrumentation for this. Merges you already have. Accepted outcomes you have on your board, with the caveat I will return to below. The ratio between them is the closest thing to a direct read on whether the extra motion is converting into resolved intent. A stable ratio with rising merges means you are genuinely shipping more. A climbing ratio means each decision is costing you more changes than it used to, and you should go and find out why before you decide whether to care.
Look at the distribution of merges across the week, not the total. A team producing a steady flow of small merges throughout the week is behaving differently from one producing a burst of thirty on Thursday afternoon. The burst pattern often indicates work that was accumulated by agents and then pushed through review in a batch, which is a review capacity problem in the making. The total is the same in both cases.
Track the share of merges with no linked work item. This one is unglamorous and enormously informative. Under the old model, an unlinked pull request was usually a small fix somebody did not bother to ticket. Under the ADLC, a rising share of unlinked merges is the clearest early signal that the record and the reality are separating. It is also the cheapest thing on this list to measure, because it is a join between two systems you already have.
None of these three is a replacement for deployment frequency. They are the context that makes deployment frequency mean something again.
Merges per accepted outcomeBoth numbers you already have. Watch the trend, not the level.
Distribution across the weekSteady flow behaves differently from a Thursday burst before a release.
Share with no linked work itemUnglamorous and the most informative of the three.
Three habits that need no new instrumentation. They are not replacements for deployment frequency; they are the context that makes it mean something again.
The uncomfortable version of the argument
There is a stronger claim available here and I want to state it clearly even though I hold it less confidently.
If merges per decision has become the dominant variable in deployment frequency, then deployment frequency has ceased to be an engineering metric at all and has become a measurement of how much your specification process is failing. Every extra merge that comes from iteration rather than decomposition is a merge that would not have existed if the requirement had been clear the first time.
Under that reading, a team with elite deployment frequency and vague acceptance criteria is not fast. It is thrashing efficiently. And the metric will reward it for exactly as long as nobody looks at the ratio.
I hold this loosely because I cannot cleanly separate iteration from decomposition in the data, and I distrust arguments whose conclusion happens to be that the thing my product measures is the important thing. But the mechanism is real, and the fact that it is hard to measure does not make it absent.
Where this breaks down
A few honest limits.
The most important one is that decision rate is not actually fixed. I have written as though human decision-making capacity is a hard ceiling that agents cannot raise, and that is too strong. Agents change what a decision costs to make, not just what it costs to implement. When exploring three approaches takes an afternoon instead of three weeks, some decisions get made faster and better, and some questions get answered by building rather than by arguing, which is often the right way to answer them. If your decision rate genuinely rose, then your deployment frequency rose for good reasons and my whole framing understates you. I do not think this is the common case yet, but I am confident it is not the null case either.
Second, the merges-per-accepted-outcome ratio leans on your board being an accurate record of what was accepted. The premise of this entire series is that boards drift under agent speed. Using a drifting artefact as your denominator will make the ratio wobble for reasons that have nothing to do with engineering. If your board is unreliable, the ratio is measuring your board. Fix the record first, then read the ratio, and expect the number to move when you do.
Third, everything here assumes merges are a reasonable unit. For teams doing infrastructure work through consoles, data work through notebooks, or configuration through low-code platforms, a substantial share of real change never appears as a merge at all. Deployment frequency computed from source control will under-report those teams badly, and no amount of careful reading fixes a metric that cannot see the work.
Fourth, I have been dismissive of the mechanical rise in the metric, and there is a version of that dismissal that becomes an excuse. A leader who responds to every improvement with “ah, but that is just merge inflation” has made their metrics unfalsifiable in the other direction. If you are going to discount good news, you need a stated rule for what would count as real improvement, agreed in advance. Otherwise you have not become rigorous, you have just become impossible to please.
The takeaway
Deployment frequency used to be a friction detector, and it worked because producing a change was expensive enough that nobody produced one by accident. That precondition is gone. The metric is now the product of your decision rate and your merges per decision, and only the first of those is the thing you actually care about.
Keep the metric. Make it declare whether it counts deploys or merges. Pair it with merges per accepted outcome, the weekly distribution, and the share of merges with no linked work item. Those four together tell you whether you got faster or just louder.
The next piece looks at lead time for changes, which is the key that agents distort most severely, and the one where the standard measurement window has quietly stopped containing the work.