concept

Statutory Change Treadmill

also called Mandatory Change Annuity, Regulatory Maintenance Floor

The recurring, externally specified change a system must absorb every cycle regardless of business demand, which sets a floor under the cost of keeping it and is usually the strongest single input to a disposition decision.

business casestatutory changerepurchaserun costdisposition

A payroll application absorbs a statutory change every April. A reporting platform implements a new regulatory return each year. An e-invoicing integration tracks a tax authority's schema revisions. None of this work is requested by the business, none of it differentiates the organisation, and none of it can be deferred: the deadline is set by someone else and missing it is a compliance event.

This is the cost that does not go away when demand for new features goes away. A team that believes its legacy system costs almost nothing to keep, because nobody is asking for changes, is usually not counting the two engineers who spend a third of the year staying level with published rules.

Named properly, it reframes the disposition argument. The question stops being "is this system worth rewriting" and becomes "should we be the ones implementing a specification somebody else writes".

Why it matters

The treadmill converts a capital decision into a recurring one. Eight engineer-months a year is roughly 0.7 FTE of permanent capacity, about £75k to £90k fully loaded in 2025 terms, committed indefinitely with no output the organisation can sell. Over a seven-year horizon that is more than half a million pounds spent on standing still, which is often larger than the replacement cost the business case was arguing about.

It also concentrates risk in people. The statutory change is the hardest work the system takes, so it is done by whoever understands it best - typically two or three people. The treadmill is therefore the mechanism by which knowledge concentration becomes a compliance risk. And because the external deadline consumes the same window every year, a programme that does not plan around it loses one quarter in four.

Implementation patterns

  • Measure it before deciding anything. Pull the last three cycles from the ticket system: elapsed weeks, people involved, and what else was displaced. The displaced work is the real number.
  • Separate the treadmill capability from the rest of the application. Where payroll calculation, tax determination or regulatory reporting can be isolated behind an interface, it becomes independently repurchasable, and the disposition decision stops being all-or-nothing.
  • Prefer repurchase for the commodity part. A vendor amortises the published rule change across its customer base and carries it as a contractual obligation. Keep in-house only the rules that are genuinely the organisation's own - collective agreements, unusual premia, bespoke cross-border splits.
  • Put the treadmill in the programme budget, not in business-as-usual, so each year of deferral has a visible price to the person deferring it.
  • Schedule modernisation milestones outside the mandatory window and say so in the plan, rather than discovering it in year two.

Industry example

Public-sector tax systems make the pattern legible because the obligations are published. The US Government Accountability Office reported that the IRS began developing CADE 2 in 2009 to replace the Individual Master File, its authoritative record of individual taxpayer accounts; that a key milestone slipped nine years from 2014 to 2023; that cost, schedule and scope goals were revised seven times between 2016 and 2019; and that in June 2021 the IRS planned full retirement of the master file by 2030. The filing season is the treadmill: it arrives on a statutory timetable every year and protecting it is the correct call each time, which is how a programme accumulates two decades of individually rational deferrals.

Failure scenarios

  • The invisible run cost. The system is reported as cheap because the treadmill is charged to the team's baseline capacity rather than to the system, so the business case understates the saving from retiring it.
  • Bus-factor compliance failure. The two people who implement the April change leave in February. Nothing has broken yet, and the deadline is unmovable.
  • The deferral loop. Modernisation is paused each year to protect the mandatory change, and the pause is never costed, so it recurs indefinitely.
  • Vendor treadmill substitution. Repurchase succeeds, and the organisation discovers the vendor implements the change six weeks after the deadline for a market it considers secondary. The treadmill moved rather than disappearing.
  • Partial repurchase with no boundary. The commodity part is bought while the bespoke part still reads the old data model directly, so both must change together every April.

Trade-offs

Choose Gains Pays
Repurchase the commodity capability The obligation becomes contractual; knowledge concentration ends; capacity returns Vendor dependency on something you cannot be without for one cycle; 12 to 24 months of parallel running; a data cleanse
Keep and modernise in place Full control of unusual rules; no migration risk The treadmill continues through the whole programme, at its full cost

The honest position is that repurchase trades a controllable internal cost for a less controllable external one. That trade is good when the rules are published and universal, and bad when the organisation's competitive position depends on the detail.

When not to use it

Do not let the treadmill decide the disposition when the capability encodes genuine differentiation. A pricing engine that must respond to regulation and expresses the firm's own risk appetite is not a commodity, and buying it buys a competitor's model of the business.

It is also the wrong lens when a harder constraint exists. If a data-centre lease ends in seven months, the disposition is whatever gets the workload out in seven months, and the treadmill argument waits for the next cycle. And for a system taking one small mandated change a year in a day or two, the floor is real but trivial - do not build a business case on it.

Interview question

Q: Your payroll system is 19 years old, three people understand it, and every April a statutory change consumes four months of two of them. The CFO says it has been reliable for a decade and asks why we would touch it. What do you say, and what evidence do you bring?

What a strong answer covers: reframing reliability (availability) against change cost (the treadmill) · the arithmetic, with the displaced work named · the knowledge concentration as a compliance risk rather than an engineering preference · repurchase as the disposition, with the boundary between commodity rules and the organisation's own rules drawn explicitly · what it costs - parallel running, data cleanse, export and exit terms negotiated before signature · and the conditions under which the answer flips, so the recommendation is falsifiable.

Quick check

Quiz: Why is a statutory change a stronger input to a disposition decision than the system's age? Because it is a recurring, externally scheduled cost with no differentiating output, so it sets a floor under the cost of keeping the system that no amount of internal prioritisation can remove.

Flashcard: What single property makes repurchase the right disposition rather than refactor? - The specification is written outside the organisation and changes on its schedule, so a bespoke implementation re-does published work every cycle with no output the business can sell.