The Prioritisation Problem

Every engineering organisation operates under constraint. There is always more work than capacity, more requests than engineers, more ideas than runway. Prioritisation is the mechanism by which you decide what happens and what does not.

Done well, prioritisation creates clarity, protects team focus, and connects engineering effort to the outcomes that matter most. Done badly, it produces a list that everyone ignores, a backlog that represents wishful thinking, and a team that switches context every time a senior stakeholder asks for something.

The challenge is that prioritisation involves trade-offs that are genuinely difficult. How do you compare a feature that drives revenue against an infrastructure investment that reduces risk? How do you weigh a compliance requirement against a product improvement? How do you decide between two roughly equal business requests when you can only do one?

There is no formula that makes these decisions easy. There are frameworks that make them more consistent and more defensible.

Prioritisation Frameworks

Three frameworks are worth understanding: WSJF, ICE, and MoSCoW. Each has a different use case and different weaknesses.

WSJF - Weighted Shortest Job First

WSJF comes from SAFe (Scaled Agile Framework) and has roots in lean economics. The formula is: WSJF = Cost of Delay divided by Job Duration.

Cost of Delay has three components: business value (revenue impact, strategic importance), time criticality (is there a deadline, a market window, a dependency?), and risk reduction or opportunity enablement (what does this unlock or prevent?).

WSJF is most useful when you are comparing items of significantly different size and business impact. Its core insight - that doing smaller, higher-value items first maximises total value delivered - is sound. Its weakness is that quantifying Cost of Delay requires judgement calls that are hard to make consistently across teams.

ICE - Impact, Confidence, Ease

ICE is simpler. Score each item from 1-10 on Impact (what is the expected outcome?), Confidence (how sure are you the impact will materialise?), and Ease (how much effort does it require, inverted so lower effort scores higher). Multiply the three scores.

ICE is a useful lightweight framework for teams that need a quick mechanism for relative prioritisation without a full scoring exercise. It is less rigorous than WSJF but faster to apply. Its weakness is that the scores are subjective and can be gamed - if you want something to be prioritised, you can score it generously.

MoSCoW - Must Have, Should Have, Could Have, Will Not Have

MoSCoW is a classification framework rather than a scoring system. Items are sorted into four buckets based on their necessity for a given release or period.

MoSCoW is most useful for release planning and scope management, particularly in projects with a fixed deadline. It creates a clear conversation about what is non-negotiable versus what is desirable. Its weakness is that "Must Have" tends to expand - everything feels essential to whoever requested it, so the Must Have bucket fills up and the framework loses its forcing function.

Choosing the Right Framework

Use WSJF when you need rigour and are comparing work across multiple teams or a large backlog. Use ICE when you need speed and a shared basis for team-level decisions. Use MoSCoW when you have a fixed scope constraint and need to make explicit trade-offs about what goes in and what does not.

Most teams benefit from using one framework consistently rather than switching between them. The consistency matters more than the specific formula.

The Run, Grow, Transform Portfolio

One of the most useful lenses for investment prioritisation is the run/grow/transform split - a portfolio allocation framework that distinguishes between three types of engineering investment.

Run work: keeping the lights on. Incidents, maintenance, licence renewals, security patching, compliance requirements. This work has to happen. It is not optional and it does not deliver business value directly - it preserves existing value.

Grow work: incremental improvement to existing products and capabilities. New features for existing users, performance improvements, UX enhancements. This is where most product development sits.

Transform work: building genuinely new capability or changing the fundamental architecture of the system. New products, platform rebuilds, significant technical investments that enable future growth.

A useful exercise is to map your current engineering capacity to these three categories. Most organisations discover that run work is consuming more capacity than they realised - often 40-50% - leaving less for grow and transform than leadership expects.

The portfolio allocation should be a deliberate decision, not an emergent result. If you want to invest in transformation, you need to protect capacity for it. That means being explicit about what you are not doing in the run and grow categories.

Making the Case for Maintenance and Platform Investment

The hardest investment case to make is the one that does not produce a countable new feature. Technical debt remediation, platform investment, and observability improvements are all genuinely valuable and all genuinely hard to justify in business case terms.

The practical approaches:

Connect to reliability. If poor platform reliability is causing you to spend engineer time on incidents - and you are tracking incident cost in engineering hours - you can present the investment as buying back that capacity. Twenty engineer-days per quarter spent on incidents is a calculable cost.

Connect to velocity. Platform investment that reduces build times, simplifies deployments, or eliminates manual processes has a compounding effect on delivery speed. If your CI pipeline takes 45 minutes and you can get it to 15 minutes, you can estimate the time saving across your engineering organisation and the effective capacity that releases.

Connect to risk. Technical debt is a risk register item. Security vulnerabilities in unsupported dependencies are a quantifiable risk. Presenting technical investment through a risk lens - with probability and impact estimates - makes it legible to leadership in a way that "the code is messy" does not.

The Cost of Context Switching and Portfolio Overload

One of the most underappreciated costs in engineering prioritisation is the cost of working on too many things simultaneously. Teams that are spread across eight active initiatives simultaneously are delivering less total value than teams focused on three - even if the eight initiatives have more combined business value on paper.

Multitasking in engineering is not actually multitasking. It is context switching, and context switching is expensive. Every switch costs warm-up time, increases the probability of errors, and reduces the depth of thinking applied to any individual problem.

Portfolio overload - the organisational equivalent of individual context switching - manifests as lots of things in progress and nothing getting finished. Everything is 80% done. Cycle times are long. Teams are busy but delivery is slow.

The prioritisation discipline that addresses this is limiting work in progress. Choose fewer things, fund them to completion, and only start new things when previous things are done. This is counterintuitive to stakeholders who want to see their initiative in progress - but it produces better outcomes faster.

Saying No

Saying no to engineering requests is one of the most important skills an engineering leader needs and one of the least developed. Most organisations have implicit norms that make it socially costly to decline requests from senior stakeholders, which means nothing ever gets deprioritised explicitly - it just gets delayed indefinitely, which is more dishonest and more damaging.

Saying no effectively requires:

A clear basis for the decision. "We cannot do this because it would displace X, which has higher priority because Y" is a defensible no. "We do not have capacity" is not - it invites the response "what if I give you more people?"

A genuine alternative. Where possible, offer a path. "We cannot take this on in Q1, but if it is still a priority in Q2 we can plan for it then" is a no with a route forward. "Never" is rarely the right answer.

Alignment on the trade-off. If a stakeholder wants to reprioritise their request above something that is currently planned, be explicit about what moves down. This creates accountability for the trade-off rather than leaving the decision invisible.

Connecting Engineering Investment to Business Outcomes

The governance conversation that sits above individual prioritisation decisions is about how engineering investment connects to business strategy. Engineering leaders who can demonstrate this connection earn more trust and more autonomy in their prioritisation decisions.

This means being able to answer: what is engineering delivering this quarter, what business outcomes does that support, and how does that connect to the company's strategic priorities?

This does not require a complex measurement framework. It requires maintaining a clear link between the engineering roadmap and the business objectives it serves, and being able to articulate that link in language that leadership understands.