The Absorption Constraint: When AI-Accelerated Delivery Outruns the Business
A team burned a twelve-month roadmap in four. That is not a success story until the rest of the company can absorb what was built. The absorption constraint, why pushing product discovery onto engineers is the wrong fix, and what the CTO should measure instead.
The most useful engineering-leadership discussion of the last month was not published as research. It ran in the CTO Craft Slack and was summarised in Tech Manager Weekly #495 on 17 August 2026. The subject was what engineers should do with the capacity that AI-assisted delivery has freed up, and one leader described a team that had been paired directly with domain areas and had burned through a twelve-month roadmap in four. The number is the kind that goes into a board update unqualified. The warning attached to it is the part worth keeping: speed without matching go-to-market capacity produces Homer’s Car, a thing assembled from everything anyone asked for and useful to nobody.
That is the failure mode this page is about, and it is not an engineering failure. The engineering organisation did what it was asked to do, faster than it has ever done it. The constraint simply stopped being there.
The constraint moves out of engineering
The throughput-versus-velocity argument covers what happens inside the delivery pipeline when one stage gets faster and the others do not: the bottleneck moves downstream, usually to code review, and most of the headline gain is absorbed there. The organisations that fix that one properly, by expanding review capacity and senior density along with the tooling, get a real team-level gain and then meet the next constraint. The next constraint sits outside engineering entirely.
Call it absorption. It is the rate at which the company can turn shipped software into used software, and it is the sum of positioning, pricing, documentation, enablement, support capacity, onboarding, and the change management that has to happen inside the customer’s own business before a feature is worth anything. Every one of those functions is staffed against last year’s delivery rate. None of them got faster because the engineering organisation adopted Claude Code.
The mechanism is unremarkable once stated and it is consistently missed at board level, because the reporting line that surfaces delivery speed is not the reporting line that surfaces absorption. Engineering reports features shipped, cycle time, deployment frequency. All three improve. Adoption, revenue attribution and support load are reported elsewhere, on a different cadence, usually by someone who has not been told that delivery volume is about to double. The gap between the two reports is where twelve-month roadmaps get burned in four and nobody notices for two quarters that the burn produced surface area rather than value.
Surface area is not free. Every shipped feature carries a maintenance obligation, a support obligation, a security obligation and eventually a deprecation cost. A feature with no adoption carries all four and returns none of them. An organisation shipping past its absorption rate is not moving faster than its competitors, it is accumulating a liability at a faster rate than it is accumulating a business.
Why “make the engineers do discovery” is the wrong read
The obvious response, and the one the Slack thread opened with, is that if discovery is now the bottleneck and engineers have capacity, engineers should do discovery. Pair them with domain areas, give them the customer contact, let the roadmap be shaped by the people building it.
This works, sometimes, and it does not generalise. The counter-argument in the thread was the correct one: not every engineer has the product instincts for this, and the real unlock is building platforms and guardrails that let domain experts build for themselves. I would put it more strongly. Discovery is not a capacity problem that spare engineering hours can be poured into. It is a judgement problem, and the judgement is a function of accumulated customer exposure that most engineering organisations have spent a decade deliberately structuring away, through product managers, through account teams, through support tiers. Handing discovery to the function that was insulated from the customer on purpose does not transfer the judgement along with the task.
What it transfers is confidence. An engineer with AI-assisted delivery capacity and no discovery evidence will produce features quickly, coherently and with the same evidentiary basis as before, which is to say a hypothesis and a hunch. The output looks like progress at every checkpoint an engineering organisation is instrumented to observe. That is precisely the shape of Homer’s Car: it was not built carelessly, it was built exactly to specification by someone with no exposure to the customer.
There is a narrow version that does work, and it is worth naming so this does not read as a blanket refusal. An engineer who already has deep exposure to a domain, paired with that domain, with a real discovery process and a product partner still in the loop, is a strong pattern. It is a staffing decision about specific people, not an operating model. The failure comes from promoting it to policy.
What the tiny-teams forecast is conditional on
The analyst version of the same argument arrived six weeks earlier and gets quoted with the condition stripped off. Gartner’s July forecast has 60% of organisations on smaller software engineering teams by 2029, against 15% in 2026, with a tiny team defined as a product manager, a UX or AX designer and at least one AI-native engineer. Four to five people today, two to three becoming common.
Two things in that release do the real work and neither survives the secondary coverage. The first is the condition: the 80% figure for 2030 is attached to adoption of AI-native development platforms, which is to say the forecast is contingent on an internal platform layer existing underneath the small team. The second is the analyst’s own framing that this is not a cost-optimisation tactic, which is the opposite of how the prediction gets repeated in every write-up and in most board conversations that follow.
Note where that lands relative to the practitioner thread. Gartner arrives at platforms and guardrails from a forecasting model. The CTO Craft members arrive at platforms and guardrails from a team that had already run the experiment. Two independent routes to the same dependency is a materially stronger basis for a planning decision than either one alone, and it is the argument I would take into a board discussion rather than the percentage.
The platform-engineering operating model page covers what that layer costs to build. The number that matters for sequencing is twelve to eighteen months in most organisations, which means a company planning a tiny-teams restructure for 2028 has a platform decision due now, in this planning cycle, ahead of the org-design decision it enables. Reversing that order produces small teams without the substrate that makes small teams work, which is not tiny teams, it is understaffing with a citation.
Measuring absorption
The reason this constraint stays invisible is that no standard engineering metric contains it. Deployment frequency, lead time for change, change failure rate and time to restore are all internal to the delivery pipeline and all four can improve while adoption falls. Three additions make the constraint visible, and none of them require new instrumentation:
The adoption share of recent releases. Of the features shipped in the last two quarters, what proportion has meaningful usage against whatever threshold the product organisation already uses. If shipping volume rises and this proportion falls, the constraint has moved and further delivery investment does not pay.
Time from release to first customer use. This measures the queue on the far side of engineering. When it stretches while cycle time shortens, work is finishing and then waiting, which is inventory, not progress.
Go-to-market lead time for a release. The interval between feature-complete and the positioning, pricing, documentation and enablement being ready. This is the absorption rate stated directly. Holding it flat while delivery speed doubles is the definition of the problem, and it is usually a headcount and process question in functions the CTO does not own, which is why it needs to be raised at the executive table rather than solved inside engineering.
The CTO framing of this decision is the one that matters for who acts. Delivery speed is the CTO’s to improve and absorption is not, but the CTO is the only executive who can see the gap forming early enough to be useful. Reporting a doubling of delivery capacity without naming the absorption question makes the eventual failure an engineering failure in the board’s reading of it, however clearly the capacity was delivered.
The verdict
Faster delivery is worth having and it is not self-justifying. Past the point where the business can absorb it, additional engineering throughput converts into maintenance liability, and the conversion is invisible on every dashboard the engineering organisation owns. The fix is not to push discovery onto engineers who were structured away from the customer, and it is not to slow down. It is to build the platform layer that lets the people who hold the domain judgement build for themselves, to sequence that build a planning cycle ahead of any restructure that depends on it, and to put the absorption number in front of the board before the roadmap gets burned rather than after.
What this connects to
The parent software-engineering hub covers the discipline shifts this argument sits on top of. The AI for engineering teams page covers the inside-the-pipeline version of the same mechanism, where the bottleneck moves to code review rather than out of engineering entirely, and the two should be read in that order because the code-review constraint binds first. The platform-engineering page covers the cost and shape of the layer this page argues is the actual unlock. The CTO page covers the accountability question, including the specific failure mode where a forecast reaches the board as a cost opportunity and the CTO has no position prepared.
Sources
- CTO Craft, Tech Manager Weekly #495, 17 August 2026 — the practitioner discussion this page opens with: engineers absorbing product-discovery work as AI accelerates delivery, the twelve-month-roadmap-in-four-months account, the Homer’s Car warning, and the platforms-and-guardrails counter-position
- Gartner, “60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029,” press release, 7 July 2026 — the adoption forecast, the composition of a tiny team, the AI-native-platform condition on the 2030 figure, and the analyst’s own statement that this is not a cost-optimisation tactic
- DORA — State of DevOps Report — the four delivery metrics referenced in the measurement section, none of which contain the absorption constraint
- Related: software-engineering hub, platform engineering, AI for engineering teams, AI for the CTO
Methodology: the empirical weight on this page sits with the two named public sources, both cited in full above and neither behind a paywall. The absorption framing and the three measurements are drawn from fractional CTO and CIO engagements where delivery capacity rose faster than the surrounding functions were staffed for; the pattern is consistent enough to write down and the thresholds are not, which is why no threshold is given for any of the three. If your organisation has measured this properly, that data is worth more than this page and I will fold it into the next revision.
