Against the ten-x claim, in all its forms
A tenfold productivity claim never names its denominator, which is what makes it unfalsifiable and useful to the person making it. The measurable truth is stranger: one stage collapsed and another got dramatically slower.
The claim arrives in three costumes. A vendor says their tooling makes engineers ten times more productive. An executive says the team should now be capable of ten times the throughput. A colleague says they personally shipped ten times as much last quarter.
All three are the same sentence and all three have the same defect: there is no denominator. Ten times what, measured over which interval, counting which stage of the work. Without those, the claim cannot be checked, which is not a bug in how it is stated. It is the reason it gets stated.
My position: refuse the multiplier framing entirely, in both directions. Do not accept it from vendors, do not repeat it upward, and do not let it become the standard your engineers are quietly measured against. What replaced it is more useful and more interesting.
The three versions, broken differently
“This tooling makes engineers ten times more productive.” Productivity is output over input. The output unit is never named, and the only ones that can be counted, lines and merged changes, are the ones nobody wants to be measured on for good reason. If the claim were about generation speed specifically it might be defensible and it would also be uninteresting, because generation was not where the time went.
“The team should deliver ten times as much.” This one at least has a unit, roughly features per quarter, and it is testable. It also assumes every stage of delivery scales with generation speed. Design decisions, review, environment contention, security sign-off, migration windows and the meeting where three people disagree about scope do not get faster because code appears sooner.
“I shipped ten times as much.” Usually true and usually about a real change in personal experience. It is also the version that does most damage, because the moment it circulates it becomes an expectation applied to people whose work is mostly in the stages that did not speed up. The engineer maintaining the ten year old integration nobody understands is not going to produce that number, and they are frequently doing the most valuable work in the building.
What actually happened, measured
The honest picture is more specific and more useful than any multiplier.
Look at that and the multiplier stops being a slight exaggeration and becomes a category error. The system did not get uniformly faster. Its shape changed, and the change moved work from a stage that scaled cheaply into stages that scale badly.
That is why teams report both experiences honestly at once: individuals genuinely producing far more, and delivery calendars that have barely moved. Both observations are correct and the multiplier language cannot hold them together.
What to ask for instead
When someone offers you a multiplier, the useful reply is not scepticism, it is a request for a denominator. Three questions do most of the work.
Which stage got faster, measured from what event to what event? Show me the distribution rather than the average, because the tail is where delivery dates come from. And what happened to the stage immediately downstream of the one you improved?
For your own organisation, that translates into a small amount of work with a large payoff. Instrument the boundaries you already have: ticket created, first commit, pull request opened, first review action, approval, merge, deploy. Report each interval as a distribution over the last two quarters. You will get an argument you can actually have, and usually a surprise about which stage is eating the calendar.
The surprise is frequently pickup time, the wait between a change being ready and anyone looking at it. It is nobody’s metric, it appears on no standard dashboard, and it is where a large share of the elapsed time now sits.
The damage the framing does to teams
This is the part I care about most, and it is not a measurement argument.
Once a multiplier becomes the ambient expectation, it sets a standard that individuals are judged against without anyone ever writing it down. The people who meet it are the ones whose work is concentrated in the stage that collapsed: new surfaces, well-specified features, greenfield paths. The people who cannot meet it are working on old systems, ambiguous problems, cross-team coordination and everything with a regulatory constraint attached.
Run that for three quarters and you have taught your organisation that the valuable work is the work that generates well. Meanwhile entry-level postings are down around 40 percent, partly on the same reasoning, and the multiplier claim is doing more work in those decisions than any measurement ever did.
An expectation that cannot be measured still gets enforced. It just gets enforced by vibe, which is worse than a bad metric because there is nothing to argue with.
Where this breaks down
Something real is being described. I have spent this article attacking the number and I will not pretend nothing changed. For a well-specified task on a codebase an agent has good context on, the production stage genuinely improved by a large factor. Dismissing the whole claim because the framing is sloppy is its own kind of error, and it makes you look like you have not tried the tools.
Multipliers are how executives communicate. “We reduced the ninetieth percentile of the review interval” does not survive a board meeting. There is a real cost to refusing the shorthand, and if you refuse it without offering something transmissible you will simply be replaced in the conversation by someone who does not. Offer one number, honestly bounded, and name the stage in the same sentence.
Stage instrumentation invites gaming. Publish pickup time and pickup time will improve, sometimes by people opening pull requests later or clicking approve faster. Every measurement I have recommended here is corruptible, and the defence is that several of them are corruptible only in opposite directions, so you watch them as a set.
Some organisations really did see order of magnitude change. A small team building new surfaces with no legacy, no compliance load and short review chains may genuinely be operating at a wildly different rate than a year ago. My argument is that this does not generalise, not that it never happens.
And delivery people are constitutionally suspicious of good news. That is a fair charge. The test I would offer is not my reasoning but your own calendar: compare features actually delivered per quarter against two years ago. If it went up tenfold, I am wrong and I would like to see the data.
The takeaway
A multiplier with no denominator cannot be checked, which is why it travels so well. The measurable reality is that one stage of delivery collapsed and the two stages after it got worse, and averaging those into a single figure throws away everything useful.
Ask which stage, measured between which events, and what happened downstream. Then measure your own intervals as distributions, because the answer is usually not where anyone expected.
If you take one thing into next week: measure the interval between a change being ready and a human first looking at it. If nobody in your organisation currently owns that number, that is why the calendar has not moved.