An architecture team has more improvement proposals than capacity. How should they be prioritised?

The dimensions that matter

1. What does not doing it cost, per quarter? Incident time, change lead time, cost, opportunity. This is the strongest input and the one most often left unquantified — an item whose cost of inaction is unstated will always lose to one with a stated benefit.

2. Leverage. Does it make other work easier? A change enabling five subsequent improvements is worth more than its direct benefit. Contract testing, observability and deployment automation are typically high-leverage because everything downstream depends on them.

3. Reversibility and risk. A cheap reversible change with uncertain benefit is worth trying; an expensive irreversible one needs stronger evidence.

4. Time sensitivity. Some items get more expensive with delay — data model changes before the dataset grows, interface changes before more consumers exist, tenancy changes before more tenants. A migration deferred is a migration that costs more, and the growth rate determines how much.

5. Team capacity and expertise, including whether the work can proceed in parallel or contends for the same scarce people.

The sequencing rule that matters most

Do the enabling work first, even though it has no direct benefit. Observability before optimisation, since you cannot optimise what you cannot measure. Contract tests before service decomposition. Deployment automation before increasing deployment frequency.

Teams routinely sequence by visible benefit and then find each improvement harder than it needed to be, because the enabling capability was missing.

The practical method

• Express each item as a cost of inaction per quarter, even roughly. This makes items comparable and surfaces the ones that are cheap to state and expensive to ignore.
• Identify the two or three highest-leverage items and do them first, accepting that they will look like overhead.
• Reserve a fixed capacity for improvement work rather than negotiating it per item — a percentage of team capacity protected by policy, so it survives roadmap pressure.
• Sequence by dependency, not by enthusiasm.
• Kill items that have been proposed three times and never prioritised. They are not going to happen, and a list containing them is misleading about capacity.

The framing for the funding conversation

A portfolio, not a wish list. A small number of items with stated costs of inaction, a stated sequence, and an expected measurable outcome for each — which is fundable in a way that a backlog of technical improvements never is.