An architect has more improvement proposals than the organisation has capacity. What sequencing rule matters most?

The rule that matters most

Do the enabling work first, even though it has no direct benefit.

Observability before optimisation, because you cannot optimise what you cannot measure. Contract tests before service decomposition. Deployment automation before increasing deployment frequency. Attribution before cost reduction.

Teams routinely sequence by visible benefit and then find each improvement harder than it needed to be, because the enabling capability was missing. The enabling items look like overhead and are the highest-leverage things on the list.

The dimensions to rank by

• Cost of inaction per quarter — incident time, change lead time × change volume, features refused. An item with no stated cost of inaction always loses to one with a stated benefit, which is why most improvement backlogs never move.
• Leverage — does it make other work easier? A change enabling five subsequent improvements is worth more than its direct benefit.
• Time sensitivity — data model, interface and tenancy changes get more expensive as datasets, consumers and tenants grow, so their cost of inaction rises.
• Reversibility and risk, since a cheap reversible change with uncertain benefit is worth trying.

The practices that make it work

• Reserve a fixed protected proportion of capacity rather than negotiating each item, so improvement work survives roadmap pressure.
• Sequence by dependency, not by enthusiasm.
• Kill items proposed three times and never prioritised — they are not going to happen, and a list containing them misleads about capacity.
• Present a portfolio, not a backlog: a small number of items with stated costs of inaction, a sequence, and an expected measurable outcome for each.

The framing that gets it funded

"Changes in this area take six weeks instead of one, across forty changes a year, and here is what fixing it costs" competes for funding. "We have technical debt" does not.