Priority Whiplash: Why Your Best Engineers Are Updating Their CVs
Stop. Changing. Our. Priorities.
That’s what your engineering team is saying. Not to your face—they’ve learned that’s pointless. They’re saying it in the pub after work. They’re saying it in one-on-ones with their line managers. They’re saying it in Slack DMs. And the really good ones? They’re saying it to recruiters.
I know this because I hear it constantly in my advisory work. I walk into organisations where the engineering team is demoralised, cynical, and exhausted—not from hard work, but from the relentless churn of changing priorities. They start something, get halfway through, and leadership pulls them onto something else. The old thing sits half-finished. The new thing hasn’t been properly thought through. Two weeks later, leadership changes direction again.
Nothing ever gets finished. Nothing ever ships. And the team stops believing that anything they start will ever see the light of day.
TL;DR: I’ve been the idiot. Early in my career, I planned at the individual developer level and constantly bumped engineers between tasks to satisfy the latest priority. It was exhilarating for me and devastating for the team. I now see this pattern everywhere in my advisory work, and it’s almost always a symptom of absent capacity visibility and weak governance—not bad intentions.
The fix isn’t complicated: small squads, visible capacity, protected roadmaps, and a CPO with the spine to let the CEO’s exuberance cool down for 48 hours before acting on it.
What Priority Whiplash Looks Like
You’ll recognise the symptoms immediately.
The Monday Morning U-Turn
The CEO went to a customer event on Friday. By Monday morning, there’s a new top priority. The team that was mid-sprint on something else is told to pivot. The PM scrambles to rewrite the brief. Engineers open a codebase they haven’t touched before and spend two days just understanding the context.
By Wednesday, momentum on the old initiative is gone. By Thursday, the new priority turns out to be less urgent than initially claimed. By the following Monday, there’s a different new priority.
The Infinite In-Progress Board
Open Jira. Count how many items are “In Progress.” If the number is more than double your team size, you’ve got a problem. These aren’t items being worked on—they’re items that were started, interrupted, and left in limbo. Each one represents context that someone loaded into their head, work that was partially completed, and momentum that was lost.
Half-finished work isn’t an asset. It’s inventory. And like all inventory, it depreciates.
The Thousand-Yard Stare
Ask an engineer in one of these organisations what they’re working on. Watch their face. There’s a particular expression—part resignation, part dark humour—that says: “I’ll tell you what I’m working on today, but we both know it’ll change by Thursday.”
These are talented people. They didn’t get into software engineering to shuffle between half-understood tasks. They want to build things that matter, ship them, and see the impact. Priority whiplash turns product teams into feature factories —except worse, because feature factories at least finish things.
The “Most Recent Conversation” CEO
Let me describe someone you’ve probably worked with.
They’re smart. They’re charismatic. They care deeply about the product and the customers. They’re also utterly incapable of holding strategic context when confronted with a compelling anecdote.
They visit one customer out of four thousand and come back declaring that whatever that customer said is now the top priority for the entire engineering organisation. They confuse the intensity of a single conversation with the importance of a strategic decision.
This isn’t malice. It’s exhilaration. There’s a dopamine hit in declaring a new priority, marshalling the troops, and feeling like you’re responding decisively to market signals. It feels like leadership.
It isn’t. It’s the opposite of leadership. Leadership is having the discipline to hear that feedback, contextualise it against your existing data and priorities, and make a measured decision about whether it warrants changing direction.
But experienced CEOs aren’t the only culprits. I’ve seen CTOs do it after reading a Hacker News post. I’ve seen CPOs do it after attending a conference. The pattern is the same: someone senior gets excited, and the excitement cascades into a reprioritisation that nobody below them asked for.
Why This Destroys Teams
Software development is a zero-sum game. Every hour spent on New Priority X is an hour not spent on Existing Priority Y. Leaders who don’t internalise this will keep piling work on, believing their teams can absorb it.
They can’t. Here’s why.
Context Switching Is Brutally Expensive
Research by Gloria Mark at UC Irvine shows it takes an average of 23 minutes to return to a task after an interruption. Not to complete it—just to get back to where you were. When you reprioritise a team mid-sprint, you’re not losing a few hours. You’re losing days of productive work as engineers unload one problem from their heads and load another.
This isn’t a productivity hack to optimise. It’s a fundamental cognitive constraint. For more on the mathematics, see our deep dive into why WIP limits are the most important rule in product planning .
Half-Finished Work Goes Stale
When you pull a team off something mid-flight, the work-in-progress doesn’t pause gracefully. It rots. Code that was half-written diverges from the main branch. Design decisions that were almost finalised lose their context. Discovery insights that informed the approach fade from memory.
When you eventually come back to it—and you will, because it was on the roadmap for a reason—the team has to re-learn everything. The two weeks they spent before the interruption? Largely wasted.
It Makes Leadership Look Incompetent
Here’s the thing nobody tells the CEO: every time you change priorities, your team’s faith in your strategic judgement decreases. Not increases—decreases.
Engineers are pattern-matching machines. After the third U-turn, they’ve identified the pattern: leadership doesn’t know what it’s doing. They stop engaging with the “why” behind priorities because they know it’ll change. They stop investing emotionally in outcomes because outcomes require consistency to achieve. They do the minimum, collect their salary, and interview elsewhere.
The engineers don’t just blame the CEO. They blame the entire ExCo—CEO, CPO, CTO—because all three are complicit. The CEO initiates the chaos. The CPO fails to protect the roadmap. The CTO fails to push back on behalf of the engineering organisation.
Discovery Falls Apart
When you reprioritise mid-sprint, the new priority almost certainly hasn’t been through proper discovery. The team doesn’t understand the problem space. They don’t know what solutions have been considered and rejected. They don’t have validated assumptions to build on.
So they’re building in the dark, on a priority that might change again next week, with no confidence that the work will ever ship. That’s not product development. That’s busy work.
As we discuss in the dual track agile article , discovery itself generates work in progress. Premature discovery on things you won’t build for months is wasteful. But NO discovery on things you’re about to build is reckless.
The Structural Failures That Enable This
Priority whiplash isn’t just a behavioural problem. It’s a structural one. Certain organisational patterns make it almost inevitable.
No Visible Capacity
If leadership can’t see what teams are working on and how much capacity is consumed, adding “just one more thing” feels costless. There’s no forcing function that makes the trade-off visible.
In organisations with capacity-based planning , reprioritisation requires answering: “What are we taking OUT to put this IN?” That question alone kills 80% of impulsive reprioritisations. Without it, priorities accumulate like credit card debt—easy to add, painful to service.
Giant Squads
When you have a squad of 10-12 people, it’s genuinely hard to visualise what they’re all doing. The team is already juggling so many items that one more feels like a rounding error. “What’s one more thing for a team of twelve?”
But when you structure your organisation into 3-4 person squads , suddenly each squad has at most 1-2 things in flight. Adding a new priority to a squad of three obviously displaces something. The trade-off is visceral.
Planning at the Individual Level
Early in my career, I made this exact mistake. I was allocating work to individual developers rather than squads. “Sarah, drop what you’re doing and pick up this thing.” It felt responsive and agile. It was actually chaos with a veneer of control.
When you plan at the individual level, you create a system where any single person can be redirected at any time. The team has no collective focus. There’s no shared objective. Everyone is doing something different, and any of those things can be swapped out on a whim.
No Governance Cadence
Without a regular planning cadence—quarterly at minimum —there’s no natural checkpoint where priorities are reviewed and adjusted deliberately. Changes happen ad hoc, driven by whoever shouted loudest most recently.
A quarterly cadence creates a rhythm: we set priorities, we execute for 13 weeks, we review and adjust. Mid-quarter changes are possible but treated as exceptions that require explicit justification, not the default operating mode.
The CPO’s Job: Protecting the Team
If you’re a CPO or Head of Product, this is your moment. Your most important job isn’t writing product specs or running discovery. It’s protecting your engineering organisation from organisational chaos.
When the CEO comes back from a customer visit buzzing with a new priority, your job is NOT to immediately cascade that into the engineering backlog. Your job is to:
Listen and acknowledge. The CEO’s insight might be genuinely valuable. Don’t dismiss it.
Let the exuberance cool. Sit on it for 48 hours. Seriously. Half the time, by Wednesday the CEO has moved on to something else. You’ve just saved your team a week of disruption by doing nothing.
Contextualise against existing data. Is this one customer’s feedback representative? Does it align with what you’re hearing from the other 3,999 customers? Does your data support the urgency?
If it’s genuinely important, schedule discovery. Don’t throw it at the team raw. Run it through discovery first. Understand the problem space. Validate the assumptions. THEN decide whether it warrants a roadmap change.
If it warrants a change, make the trade-off explicit. Don’t add it to the roadmap. SWAP it onto the roadmap. Show what gets displaced. Let leadership make that decision with full visibility of the cost.
This takes courage. Telling your CEO “let’s wait a few days before we act on this” is not a comfortable conversation. But it’s infinitely better than the alternative: a demoralised team, a graveyard of half-finished work, and your best engineers on LinkedIn.
The Fix: A Practical Playbook
When I walk into an organisation suffering from priority whiplash, here’s what I do.
Step 1: Restructure Into Small Squads
If you have teams of 8-12, break them into squads of 3-4. This alone transforms priority visibility. A squad of three can work on one thing with full focus, or two things with split attention. There’s no room to hide scope creep.
Step 2: Allocate a Third of Capacity to KTLO
Before layering in any strategic work, reserve roughly a third of your capacity for keeping the lights on —maintenance, support, bug fixes, infrastructure, and the “brilliant basics” that keep customers happy. This isn’t glamorous, but it’s essential. It also prevents the fire-fighting that often triggers reprioritisation in the first place.
When your systems are stable, fewer fires break out. Fewer fires mean fewer “urgent” priority changes.
Step 3: Layer In Strategic Initiatives
With the remaining two-thirds of capacity, allocate your highest-priority outcome-based objectives to squads across the quarter. Make it visual. Make it explicit. Each squad-sprint cell shows what that team is working on and how much capacity it consumes.
Step 4: Have the Honest Conversation
Now pull up the grid and show leadership the reality. Every cell is allocated. There is no spare capacity. If you want to add something, something else must come out.
This is usually a sobering moment. Leaders who’ve been casually adding priorities suddenly see the mathematical impossibility of their expectations. The grid doesn’t judge. It just shows the truth.
Step 5: Establish a Governance Cadence
Agree that priority changes happen at defined checkpoints—quarterly planning, monthly reviews—not on Monday morning because the CEO went to a dinner party on Saturday. Emergency changes are possible but require explicit justification: “What changed in the market/regulatory environment that makes this genuinely urgent?”
If the answer is “I talked to a customer,” that’s not an emergency. That’s an input to the next planning cycle.
When Reprioritisation IS Justified
I want to be clear: I’m not saying priorities should never change. Sometimes they must.
Regulatory or compliance deadlines that emerge unexpectedly can force legitimate reprioritisation. When the regulator says “fix this by March or we revoke your licence,” that’s not priority whiplash—that’s reality.
Genuine market shifts—a competitor launches something that fundamentally changes your position, or a major customer threatens to churn and takes 15% of your ARR with them—can justify mid-quarter changes.
Critical production incidents that affect large numbers of customers may need to displace planned work temporarily.
The test is simple: would this change survive 48 hours of scrutiny? If yes, it’s probably legitimate. If it wouldn’t survive a weekend of reflection, it’s probably the “most recent conversation” problem.
What Your Engineers Actually Want
Your engineers aren’t asking for a stress-free life. They’re not asking for zero change. They’re asking for three things:
Consistency. Let me finish what I started before you give me something new. Let me see work through to production and measure its impact.
Honesty. If priorities must change, tell me why. Show me the data. Don’t pretend every pivot is strategic when we all know it’s reactive.
Competence. Show me that leadership has a plan. Show me that someone did the maths on capacity. Show me that the roadmap reflects reality, not fantasy.
These aren’t unreasonable demands. They’re the bare minimum of effective product leadership.
Conclusion
Priority whiplash is one of the most damaging patterns in product organisations—and one of the most fixable. It’s not caused by bad people. It’s caused by invisible capacity, oversized teams, absent governance, and leaders who mistake reactivity for decisiveness.
Your best engineers—the ones you absolutely cannot afford to lose—are the ones most sensitive to this pattern. They’re the ones who care most about finishing things, shipping quality work, and seeing the impact. When you deny them that by constantly changing direction, they don’t complain forever. They leave.
The fix starts with making capacity visible, structuring teams small enough that trade-offs are obvious, and establishing a planning cadence that creates discipline without rigidity.
And if you’re a CPO reading this: the next time your CEO comes back from a customer visit with a “game-changing” new priority, take a deep breath. Acknowledge it. Write it down. And then wait 48 hours.
Your team will thank you. Your roadmap will thank you. And your retention rate will thank you.