Thirteen times more releases, the same manual disk resize

The transferable part is the arithmetic. Four release events a year becomes about fifty-two, roughly thirteen times as many trips down the delivery path ^[19]. The Wehkamp engineers writing in InfoQ are explicit that the individual chores did not get slower: creating a database or changing a disk size cost what it always cost, but a small step inside one big quarterly release became a point of friction inside a large number of small ones ^[17]. That is how a platform falls behind while everybody is doing their job correctly. Per-release toil scales with release frequency, and release frequency is the thing the organisation is paying people to increase.

It also produces a scoping rule that is harder to game than a roadmap. The work worth absorbing is the work repeated across teams and across releases ^[3]; the rare cases are worth leaving outside, which is the practical argument for opinionated golden paths with well defined escape hatches rather than support for every possible use case ^[2]. The escape hatch carries the load there. Without one, every unusual requirement becomes an argument for widening the path, and widening the path is how a platform acquires features it cannot maintain.

There is a second instrument in the account, and it costs nothing to read. Wehkamp treats the drift in incoming questions and tickets, from basic usability towards edge cases and new features, as evidence the platform is working, alongside fewer incidents and better cost control ^[16]. Ticket mix is available every week, needs no survey, and cannot be inflated by shipping something nobody asked for.

Worth being clear about where the load came from. Zero-handoff engineering was a deliberate transfer: the teams that gained rollback and their own scaling decisions ^[12] also took on knowing more about the systems running their software, working with observability tooling, and sometimes debugging in live production ^[13]. That is the same bargain shift-left and DevOps struck at wider scope, buying flow at the price of higher cognitive load and duplicated testing, security and maintenance effort ^[6]. On that reading, capability added without abstraction cannot reverse the transfer; it only makes the transferred work more visible.

None of it terminates. Removing one class of toil promotes the next class to bottleneck ^[15], and in a company carrying decades of technical debt and cultural barriers the whole exercise is an order of magnitude harder than the greenfield version ^[7]. That is the honest case for treating the platform as a product under continuous revision from user feedback and changing organisational needs ^[4], rather than as a programme with a completion date. The account is one company's, published in InfoQ and drawn from a KubeCon EU 2026 talk in Amsterdam ^[8], at a Dutch retailer running software across logistics, data science and e-commerce with a legacy that had already produced siloes and duplicated engineering ^[9]. The mechanism, though, does not depend on the industry. If cadence rises and the recurring per-release work does not fall, the platform is growing in the wrong direction, whatever the feature list says.