practice

Prioritisation

Choosing what to work on when everything is important — by leverage, constraint and irreversibility rather than by urgency.

prioritisationleverageconstraintssequencingfocus

Definition

Architects face more legitimate work than capacity. Prioritisation is the discipline of deciding what not to do, and doing it explicitly rather than by default.

The criteria that matter

Leverage. Which work makes other work easier? A deployment pipeline, a data platform, a paved road — these multiply. A single feature does not. Foundational work is systematically under-prioritised because its benefit is diffuse.

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

Irreversibility. One-way doors deserve attention now; two-way doors can wait and be corrected. Decisions that get more expensive with time — data models, tenancy, boundaries — should be made before the cost rises.

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

Decay. Some work gets harder if deferred — a migration before more consumers integrate, a boundary before more code accumulates. Others do not.

What to deprioritise deliberately

  • 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 without a stated objective, which has no stopping condition.
  • Documentation nobody has asked for.

Saying no well

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 has been deprioritised and why, so it can be revisited when conditions change — and so 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.

Interview question

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