Flowstate - Prioritisation & trade-offs

The job

You’re looking at a spreadsheet with twenty-three initiatives on it. The VP of Product says the new onboarding flow is critical — churn is killing them. The Head of Sales says the enterprise API is the difference between closing a $2M deal and losing it. The CTO wants to address the technical debt that’s been slowing everyone down for two years. Your CFO is asking why engineering costs went up 30% when output feels flat.

Every single one of these people is right. Every initiative is legitimate. And you can do maybe six of them well.

This is the job. Not ranking things — any idiot with a spreadsheet can rank things. The job is making the decision to not do legitimate, valuable work, communicating that decision without destroying relationships, and having the conviction to hold the line when someone tries to sneak their initiative back in through the side door.

Most engineering organisations are bad at prioritisation not because they lack frameworks. They’re bad at it because they can’t stomach the politics of saying no. So they say yes to everything, spread their teams across too many initiatives, finish nothing properly, and lose trust with everyone.

The irony is brutal: trying to please everyone is the fastest way to disappoint everyone.

Why it matters

The cost of bad prioritisation isn’t that you do the wrong things. It’s that you do too many things, poorly.

I’ve worked with an organisation — 200 engineers, well-funded, talented team — that had forty-one active initiatives in a single quarter. Forty-one. Most teams were spread across three or four projects. Nothing was getting proper focus. Releases were buggy because nobody had time for thorough testing. Engineers were exhausted from context-switching. And leadership was frustrated because “with 200 engineers, why can’t we ship faster?”

The answer was obvious to everyone in engineering and invisible to everyone outside it: 200 engineers working on 41 things is not 200 engineers. It’s 41 teams of 4.8 people, each too small to make meaningful progress.

Here’s what happens when you can’t prioritise:

You finish nothing. Twelve things at 80% done is worth less than six things at 100% done and shipped. Unshipped work has zero value. It’s pure cost.

Your best people leave. Good engineers want to build things that matter. When they’re spread across three projects and can’t make real progress on any of them, they start looking at job boards. You’re not losing them to better compensation — you’re losing them to organisations that let them focus.

Leadership stops trusting engineering. When you promise twenty things and deliver eight, it doesn’t matter that those eight were excellent. The narrative becomes “engineering can’t deliver.” And once that narrative takes hold, it’s incredibly hard to shift.

When prioritisation works — when you commit to fewer things and actually finish them — everything compounds. Teams build momentum. Quality goes up because people have time to do things properly. Leadership sees results and gives you more autonomy. Engineers feel the satisfaction of shipping. It’s a virtuous cycle, and it starts with the courage to say no.

What good looks like

Organisations that are good at prioritisation share a few traits:

They have a small number of active bets. As a rule of thumb, you should have fewer active initiatives than you have teams. If you have twelve teams and fifteen initiatives, at least three teams are split across multiple projects. That’s a smell. The best organisations I’ve seen run at roughly one major initiative per two teams, with the remaining capacity explicitly allocated to support, maintenance, and small improvements.

They distinguish between categories of work. Not all work competes for the same pool. Typically you need:

Strategic bets (new capabilities, major features) — 50-60% of capacity
Keep the lights on (support, incidents, maintenance) — 20-25% of capacity
Debt and platform (technical debt, infrastructure, tooling) — 15-20% of capacity

These ratios aren’t sacred, but having them explicit means you’re not constantly relitigating whether technical debt “counts” as real work. It does. It has a budget. Move on.

They make decisions, not rankings. A prioritised list is not a priority framework. If your list has twenty items ranked 1-20, you haven’t prioritised — you’ve sorted. Prioritisation means drawing a line and saying “everything above this line gets resourced, everything below it doesn’t, and here’s why.”

They review and adjust. Priorities aren’t set in stone. The best teams revisit their priorities every six weeks (not every six days — that’s thrashing, not responding). If the market changes, if a key assumption is invalidated, if a competitor makes a move, you adjust. But you adjust deliberately, not reactively.

They can explain their reasoning. If you can’t explain to a stakeholder why their initiative didn’t make the cut, your prioritisation process isn’t working. The explanation doesn’t have to make them happy — it has to be honest and logical. “We chose X over Y because X directly impacts our biggest growth bottleneck and Y, while valuable, addresses a problem that’s stable” is defensible. “We just didn’t have capacity” is not.

The approach

Step 1: Establish the strategic frame

Before you prioritise anything, you need to know what you’re optimising for. This comes from your planning cycle — the two or three things leadership has agreed matter most this quarter.

Without this frame, every prioritisation discussion becomes a shouting match between stakeholders defending their own corners. With it, you have an objective filter: “Does this initiative directly advance our top priorities?”

Write it on the wall. Refer back to it every time someone proposes adding something to the plan. “That’s a great initiative. How does it connect to our focus on reducing churn?” If the answer is tenuous, it goes below the line.

Step 2: Force-rank on impact, not urgency

Urgency is the enemy of prioritisation. Everything feels urgent when someone’s shouting about it. But urgency is a function of who’s asking, not what matters.

Instead, evaluate each initiative on:

Impact on the strategic priority. Not theoretical impact — quantified impact. “This will reduce churn by an estimated 15% based on our analysis of why customers leave” beats “this will improve customer experience.”
Confidence in the estimate. A high-impact initiative with low confidence might need a scoping exercise before it earns full investment. Don’t rank things you don’t understand.
Cost of delay. What happens if you do this next quarter instead of this quarter? If the answer is “nothing much,” it’s not a priority. If the answer is “we lose the market window” or “the technical debt compounds,” that changes the calculus.
Reversibility. Prefer bets you can unwind over bets you can’t. An investment in a new feature can be measured and stopped. A full platform rewrite can’t easily be reversed midway.

I deliberately haven’t mentioned scoring matrices here. I’ve seen too many organisations hide behind a weighted scoring model that produces a number everyone argues with anyway. The number gives a false sense of objectivity. What actually works is structured discussion among people with context, using the criteria above as a guide. The goal is a decision, not a score.

Step 3: Draw the line

This is the hard part. You’ve ranked the initiatives. Now you need to map them against your actual capacity (see Capacity Planning) and draw the line between “doing” and “not doing.”

The line should be conservative. If you think you can do eight things, commit to six. The buffer isn’t laziness — it’s realism. Things take longer than expected. People get sick. Incidents happen. Critical bugs appear. If you plan at 100% utilisation, any disruption blows the plan.

Below-the-line initiatives need an explicit status. Not “deprioritised” — that’s weasel language that lets people hope. Try:

“Parked until Q3.” Clear, time-bound, honest.
“Needs a scoping exercise before we can prioritise it.” Acknowledges value, identifies the gap.
“Not aligned with current strategic priorities.” Direct. Might sting. But it’s fair.

Step 4: Stress-test with stakeholders

Before you announce priorities, socialise them with the key stakeholders whose initiatives didn’t make the cut. This is not a negotiation — you’ve made the decision. But giving people a heads-up, hearing their concerns, and letting them feel heard goes a long way.

The conversation is simple: “Here’s what we’re prioritising and why. I know this means [your initiative] isn’t happening this quarter. Here’s my reasoning. I wanted to tell you directly rather than have you find out in an all-hands.”

Some will push back. That’s fine. Listen. If they have new information that changes the calculus, great — incorporate it. If they’re just lobbying harder, hold the line. “I understand this is frustrating. The constraint isn’t willingness — it’s capacity. If we do yours, we have to stop something else. Which of these would you cut?”

That last question is devastatingly effective. Most people, when asked to make the trade-off themselves, acknowledge the difficulty.

Step 5: Communicate and protect

Announce the priorities. Be clear about what’s in and what’s out. Then — and this is the part most leaders skip — actively protect the priorities for the rest of the quarter.

This means:

Saying no to mid-quarter additions unless they genuinely trump an existing priority (and making the swap explicit).
Pushing back on “just a small thing” requests that accumulate into a death-by-a-thousand-cuts problem.
Escalating when a senior stakeholder tries to override the process. “I’m happy to add that initiative. Which of our current commitments should I stop? Let’s make that decision together.”

If you don’t protect priorities, having them is pointless. They become a wish list that dissolves on contact with reality.

The conversations

Prioritisation conversations are where careers are made or broken. The language matters enormously.

Telling a senior stakeholder their initiative isn’t happening

This is the conversation everyone dreads. Here’s how to handle it:

Trust-building: “I’ve looked at this carefully, and I think it’s the right initiative — just not the right time. Right now, our biggest lever for [strategic goal] is [chosen initiative]. I’d love to revisit yours for Q3 planning. In the meantime, is there a lightweight version — something we could do in two weeks — that would test the core assumption?”

What this does: validates their thinking, provides clear reasoning, offers a path forward, and demonstrates strategic maturity.

Trust-eroding: “We just don’t have the capacity right now.” (This is lazy. It invites the response “well, hire more people” and doesn’t demonstrate any strategic thinking.)

Catastrophically trust-eroding: “Sure, we’ll try to fit it in.” (Saying yes when you mean no is the fastest way to lose trust. When you inevitably don’t deliver, you’ve confirmed that engineering can’t be relied upon.)

When everything is P1

Every engineering leader has been in the meeting where someone says “we can’t deprioritise any of these — they’re all critical.”

Trust-building: “If everything is P1, nothing is P1. Let me put it differently: if I could only ship one of these things this quarter, which one would it be? Start there.”

Or, more pointedly: “We have capacity for six initiatives. There are twelve on this list. I need you to help me decide which six we’re not doing. I can make that decision myself, but I’d rather make it with the people who understand the business context.”

Trust-building (with data): “Here’s what happened last quarter when we tried to do everything. We committed to fourteen initiatives and shipped seven, all with quality issues. This quarter, I’m proposing we commit to seven and actually finish them. Which seven should they be?”

With your team

Trust-building: “I know there’s a lot on the wish list. Here’s what we’re actually doing, and more importantly, here’s what I’ve said no to so that you can focus. If anyone outside this team asks you to work on something that isn’t on this list, send them to me.”

This is leadership. You’re taking the political heat so your team can focus on delivery.

With your CFO

Trust-building: “Here’s our investment portfolio for the quarter. We’re putting 60% of engineering capacity into three strategic bets, each with a measurable outcome. 25% is keeping the platform stable. 15% is paying down the technical debt that’s slowing us down. Here’s what we expect to deliver and here’s how we’ll measure it.”

This language resonates with finance because it frames engineering as an investment portfolio, not a cost centre. They understand portfolio allocation. They understand risk management. Speak their language.

Common failure modes

The HiPPO problem. Highest Paid Person’s Opinion. The CEO walks into a meeting and says “we should build X” and suddenly X is the top priority regardless of the strategic frame. If your prioritisation process can be overridden by anyone’s opinion — no matter how senior — it’s not a process. It’s a power dynamic. Push back, respectfully. “I hear you. Let me show you what we’d need to stop doing to accommodate that.”

Priority creep. You start the quarter with six initiatives. By week four, you have nine. Nobody explicitly added three — they just appeared. A “quick request” from sales. A “small project” from the CEO’s visit to a customer. A “minor integration” that turned into a six-week effort. This is why protecting priorities is an active discipline, not a one-time decision.

Confusing priority with sequence. “We’ll do A first, then B, then C” is sequencing, not prioritising. If B and C are both P1 and you run out of time after A, you’ve delivered one-third of your priorities. Real prioritisation means acknowledging that C might not happen and being okay with that.

The peanut butter problem. Spreading resources evenly across all initiatives — “every team gets a bit of everything” — so that nothing gets enough investment to succeed. This feels fair and democratic. It’s actually a recipe for universal mediocrity. Better to fully fund four initiatives and park the other eight than to half-fund all twelve.

Retrospective prioritisation. Waiting until you’re already overwhelmed to prioritise. By that point, you’ve made commitments you can’t keep and the conversation is about damage control, not strategy. Prioritise proactively, at the start of the cycle, when you still have choices.

Prioritising what’s easy over what matters. The quick wins feel good. They pad the metrics. But if your biggest challenge is platform reliability and you spend the quarter shipping small features because they’re easier to deliver, you’ve prioritised optics over outcomes. Sometimes the right priority is the hardest one.

Getting started

If your organisation currently says yes to everything and finishes nothing, here’s how to start building the muscle:

This week: Count your active initiatives. Literally count them. Every project, programme, and “small thing” that has an engineer working on it. The number will probably horrify you. Write it down.

Next week: For each initiative, write one sentence describing its impact on your top strategic priority. If you can’t write that sentence, the initiative shouldn’t be active. Mark those for review.

This month: Draw the line. Using your capacity data, determine how many initiatives you can realistically resource well. Pick the top ones. For everything below the line, have the conversation with the stakeholder. Use the language from this play.

This quarter: Run a six-week review. Look at your active initiatives. Are they on track? Should any be stopped? Should anything below the line move up? Make these decisions as a leadership team, not in ad hoc Slack threads.

The first time you cut an initiative, it’ll feel uncomfortable. The stakeholder will push back. They might escalate. That’s okay. Hold the line, explain your reasoning, and point to the results you’re delivering on the initiatives you did prioritise.

Within two quarters, something remarkable happens: people stop trying to sneak things onto the priority list because they know the process works. They bring their best proposals to planning, make their case, and accept the outcome. The political energy that used to go into lobbying and back-channelling gets redirected into actually doing the work.

That’s what good prioritisation buys you. Not just better outcomes — a better culture.

Running Effective Planning Cycles — The cadence that sets the stage for prioritisation decisions.
Initiative Scoping — How to properly size and define the initiatives you’re prioritising.
Investment Framing — Presenting your priorities in the language of financial investment.