You have capacity for two of five legitimate architectural initiatives. How do you choose?

What is being tested

Whether you prioritise by leverage and constraint rather than by urgency or by who asked loudest.

The criteria, in order

1. Which is on the constraint? What currently limits the organisation? Optimising anything other than the bottleneck changes nothing. If delivery is limited by review latency, a faster build helps nobody.

2. Which has the most leverage? Which work makes other work easier — a deployment pipeline, a data platform, a paved road? These multiply across everything after them and are systematically under-prioritised because their benefit is diffuse and unattributable.

3. Which decays if deferred? Some work gets harder with time: a boundary change before more code accumulates, a migration before more consumers integrate, a data model change before more data exists. Others are equally easy in a year.

4. Which is irreversible? One-way doors deserve attention now; two-way doors can wait and be corrected.

5. Risk-weighted impact. Probability times consequence. An unlikely catastrophe may outrank a likely inconvenience.

What that usually eliminates

• Work that is interesting but not on the constraint.
• Modernisation of things that work, are supported and rarely change. Age is not a defect.
• Optimisation with no stated objective, which has no stopping condition.

How to say no

Not "no", but "not now, and here is what it displaces". Making the trade-off visible converts a refusal into a decision someone else can take, and it protects the relationship.

Keep an explicit list of what was deprioritised and why, so it can be revisited when conditions change and nobody has to argue for it from scratch a second time.

The failure specific to architects

Being pulled into everything. An architect present at every discussion adds latency and diffuse value. Choosing a small number of decisions to be genuinely involved in, and trusting teams with the rest, is more effective — and it requires having developed judgement in those teams, which is the argument for mentoring being a prioritised activity rather than a residual one.