Every organisation insists it has a prioritisation problem.
More often, it has a reluctance problem.
Backlogs swell, roadmaps crowd, and teams stay busy. Activity is not the issue. Direction is. Releases ship, progress updates circulate, yet the organisation struggles to point to outcomes that materially changed its trajectory. This tends to be framed as a delivery challenge. In practice, it is a decision problem wearing an operational disguise.
Prioritising development work is rarely about identifying the single most important thing, but accepting, explicitly and publicly, the cost of ignoring everything else. That acceptance feels uncomfortable, occasionally political, and sometimes personal. Unsurprisingly, many organisations attempt to dilute it through process, delegation, or ritualised planning cycles.
What emerges looks like prioritisation. What it avoids is choice.
The Backlog Is Not a Queue
Most backlogs pretend to be neutral. They present themselves as orderly lists of work awaiting attention, ranked with professional care. In reality, they function as cultural artefacts. They show, with quiet accuracy, what an organisation finds hardest to refuse.
A backlog dominated by “small but necessary” items often signals risk aversion. One filled with internal requests usually reflects weak product authority. A backlog that never meaningfully shrinks suggests that prioritisation has been confused with sequencing.
Having many potential initiatives is not the problem. Trouble begins when “could” quietly turns into “should”, then slips, without ceremony, into “will, eventually”. At that point, prioritisation stops being an act and becomes a promise no one remembers making.
Boards assume that items on the backlog have been assessed. Teams assume that items near the top matter. Both assumptions fail more often than anyone admits.
Urgency Is a Persuasive Liar
The fastest way to secure development attention is not to demonstrate value, but to manufacture urgency. Deadlines help. Escalations help more. Regulatory language, customer commitments, and the phrase “we’ve already communicated this externally” are particularly effective.
Urgency, however, performs poorly as a proxy for importance.
Organisations that reward urgency gradually optimise for interruption. Roadmaps behave less like plans and more like weather systems. Engineers learn, entirely rationally, that the safest work is the work that looks immediately necessary, even when it contributes little to long-term outcomes.
Over time, a distortion sets in. High-leverage work becomes harder to schedule precisely because it lacks a forcing function. Platform investments, architectural improvements, and structural simplifications do not shout. They wait patiently while louder requests pass them by.
When everything arrives labelled urgent, very little turns out to be consequential.
Prioritisation Collapses When Accountability Spreads
Few phrases predict prioritisation failure as reliably as “we agreed as a group”. Groups excel at generating lists. They struggle to own trade-offs.
Committees tend to prioritise through accumulation. Each stakeholder successfully advocates for their own concern, and the combined result grows longer while remaining strangely flat. Inclusion replaces choice. Nothing is rejected, and therefore nothing is truly selected.
Effective prioritisation requires a single point of accountability: someone who can be wrong in public. Without that, decisions default to consensus. Consensus defaults to safety. Safety, in turn, favours incrementalism.
This is not an argument against collaboration, more a reminder about responsibility. When no one owns the outcome, the organisation optimises for harmony rather than progress.
Engineers Usually Know What Matters. They’re Just Rarely Invited to Say It.
A persistent myth places prioritisation safely upstream from engineering, where strategy supposedly lives untouched by implementation detail. In practice, engineers often hold the clearest view of what will compound and what will quietly decay.
They see where shortcuts have become structural. They know which systems creak under load, which processes waste effort, and which investments would repay themselves many times over. What they often lack is not insight, but licence—permission for that insight to influence decisions.
When teams are excluded from prioritisation, they compensate by optimising locally. They deliver exactly what is requested, even when they suspect the request is misguided. This behaviour is professional, predictable, and expensive.
Inviting engineering judgement into prioritisation does not slow delivery, but reduces the risk of shipping misunderstandings with impressive efficiency.
A Roadmap Should Create Mild Unease
A comfortable roadmap usually tells the truth about effort and lies about ambition. If everything fits neatly, nothing meaningful has been traded off.
Good prioritisation creates tension. It leaves capable people working on fewer things than they could. It produces visible gaps where reasonable requests were declined. It invites second-guessing, particularly from those whose initiatives did not make the cut.
That tension is not a failure mode. It is evidence that prioritisation occurred.
Leadership’s role is to narrate discomfort. Clear explanations of why certain work matters now, and why other work does not, build trust even when decisions disappoint. Silence, by contrast, encourages folklore.
Sequencing Does Not Magically Become Strategy
A familiar escape route involves declaring that everything matters, just not simultaneously. The claim sounds pragmatic. Often, it merely postpones conflict.
If two initiatives compete for the same constrained resources, a prioritisation problem already exists. Placing one “later” without acknowledging the opportunity cost does not create neutrality. It creates ambiguity.
Strategy appears when sequencing decisions are explicit, intentional, and defended. Not everything deserves a phase two. Some things deserve to stop.
What Tends to Work Instead
Organisations that improve prioritisation adopt a handful of unfashionable habits.
- They cap active work aggressively, even when capacity appears available.
- They revisit priorities less often than stakeholders prefer, and with more intent than teams expect.
- They treat removing work from the plan as progress rather than retreat.
- They explain decisions plainly, without hiding behind scoring models or elaborate frameworks.
Most importantly, they recognise that prioritisation never finishes. It operates as a continuous act of organisational self-definition.
Every development choice answers a quiet question: what kind of company are we becoming? Over time, that accumulated answer matters far more than any single release.
A Final, Slightly Awkward Observation
The hardest part of prioritising development is accepting that choosing it will inconvenience, frustrate, or disappoint someone who is entirely reasonable.
Avoiding that moment feels considerate. It usually proves expensive.
Clarity, even when it narrows options, settles organisations over time. Teams move with greater confidence. Conversations shorten. Progress becomes easier to recognise. Motion stops masquerading as direction.
Prioritisation does not simplify development. It sharpens outcomes. And in executive settings, that quiet sharpness remains one of the most valuable deliveries available.
Discover more from Diary Of A CTO
Subscribe to get the latest posts sent to your email.
