When Everything Is a Priority, Nothing Is: Leading Engineering Through Constant Change

Changing priorities isn’t the problem

Priorities change. That’s normal. Customers change their minds. A major deal suddenly needs something. Production breaks. Leadership learns something new. A competitor moves. An assumption we made three months ago turns out to be wrong.

A good engineering organization needs to be able to respond to all of that.

The problem isn’t changing priorities. The problem is changing priorities without acknowledging what the change costs.

Across more than two decades in software, as an engineer, a co-founder and CTO, and an engineering leader, I’ve seen teams fall into the same cycle. Something is the top priority on Monday. Something else replaces it on Wednesday. By Friday, everyone is asking why the first thing isn’t finished.

At that point, the problem isn’t engineering velocity. It’s the system around the team.

What does changing priorities cost an engineering team?

Mostly context. An engineer moved off a feature loses part of what they knew about it, and when they come back weeks later they have to rebuild that understanding before they can make progress. The cost rarely shows up in Jira, but across a whole team it adds up.

Software development isn’t a queue where you can keep rearranging tickets without consequences. An engineer working on a feature is carrying a lot in their head:

• Why the feature exists.
• How the existing system works.
• Which edge cases matter.
• What they already tried.
• What still needs to be tested.
• Where the risks are.

Move them to something else and some of that disappears. When they return three weeks later, they don’t simply continue where they stopped. They have to reconstruct the problem first.

That cost is real. And when it happens repeatedly across an entire team, it becomes significant.

The dangerous part is starting, not changing

When priorities keep changing, teams often respond by starting more things. Feature A is paused, so start Feature B. Something happens with a customer, so pause B and start C. A week later, A is important again.

Now the organization has three partially completed initiatives and very little delivered value.

This is why I pay so much attention to work in progress. Ten projects at 80% complete don’t provide the same value as eight finished ones. Partially finished work can’t reach customers, can’t earn revenue and can’t teach you anything.

So sometimes the right response to a new priority isn’t “Start this immediately.” It’s this:

If this is now the most important thing, what are we going to stop?

That second question changes the conversation.

Make the tradeoff explicit

When someone tells me something has become the new priority, I don’t think engineering should automatically push back. There may be a very good business reason.

What I want is for the tradeoff to be visible. If we’re moving engineers from Initiative A to Initiative B, we should be able to say something like this:

“We can move the team to B. That will likely move A from October to November.”

Now we’re making a business decision.

Without that conversation, organizations accidentally create the expectation that A and B will both still happen on their original schedules. Engineering absorbs the change while the rest of the business keeps operating against the old plan. Eventually the team looks slow, even though it may be doing exactly what it was asked to do.

It’s one of the practices I write about in how I work across product, QA and leadership: product gets honest options with the costs attached, so a roadmap change is a negotiation instead of a surprise.

Ask why the priority changed

Not all priority changes are the same, and they shouldn’t all be handled the same way.

Before changing direction, I want to understand what actually changed:

• Did we receive new information?
• Is revenue at risk?
• Is a customer blocked?
• Did a deadline move?
• Is there a regulatory or security issue?
• Did a previous assumption turn out to be wrong?
• Or did something simply become more interesting than what we’re doing now?

The answer matters. Changing priorities because the business learned something important is healthy. Changing priorities because the organization can’t maintain focus is not.

Protect the team without isolating them from the business

I’ve never liked the idea that engineering leadership should shield engineers from everything happening in the company. Engineers should understand why priorities change, because context helps people make better decisions.

If we suddenly need to move something because a customer launch depends on it, tell the team. If revenue is involved, tell them. If we’re testing an assumption, explain the assumption. People handle change much better when they understand why it matters.

Context is also how engineers grow. You can’t hand someone real ownership while holding back the reasons behind the work, which is a big part of why I mentor engineers until they can replace me.

What I want to protect the team from isn’t business context. It’s organizational noise. There’s a difference.

Separate interruptions from strategy

Some teams effectively run one priority system: everything goes into the same backlog. I prefer to recognize that different types of work behave differently.

Planned product work

The roadmap: what the team committed to building.

Bugs

Defects found after the work shipped.

Production incidents

Work that interrupts everything else until it’s resolved.

Technical debt

Shortcuts and aging code that slow down future work.

Customer escalations

Problems a specific customer needs solved now.

Security issues

Vulnerabilities and fixes that can’t sit in the queue.

Exploratory work

Spikes and experiments to learn something before committing.

Pretending all of that can be perfectly planned two weeks in advance creates frustration.

If a team historically spends 20% of its capacity on unplanned work, planning every sprint at 100% feature capacity isn’t ambitious. It’s unrealistic. Plan around the interruptions the team actually gets.

Understanding the team’s real operating pattern makes planning much more useful, and it stops urgent work from quietly eating the roadmap.

Don’t confuse urgent with important

One of the responsibilities of engineering and product leadership is helping the organization tell the difference between something that is loud and something that is strategically important.

The newest request naturally gets attention. The customer who emailed this morning feels more immediate than an architectural problem we’ve known about for six months. But urgency shouldn’t automatically decide where we invest.

Sometimes fixing an underlying platform problem will eliminate dozens of future urgent requests. Sometimes the customer request really does need to win.

The job isn’t to eliminate those decisions. The job is to make them deliberately.

Give people a stable goal, even when the path changes

Teams can handle a surprising amount of tactical change when the strategic direction stays clear. Say the goal for the quarter is this:

Reduce the time it takes a new customer to reach their first successful transaction.

Along the way, the team might discover that the original feature isn’t the right solution. That’s fine. Changing the implementation because we learned something isn’t failure. The work might move from feature A, to an onboarding improvement, to an API change, to automation. The implementation changed. The goal didn’t.

That’s very different from this:

• Monday: onboarding.
• Wednesday: reporting.
• Friday: AI.
• Next Monday: cost reduction.

That isn’t agility. It’s a lack of direction.

Track why work doesn’t finish

When I see significant sprint carryover, or initiatives repeatedly missing their expected dates, I don’t immediately conclude that engineers aren’t delivering fast enough. I want to understand the reason:

• Was the work underestimated?
• Did the requirements change?
• Did another team block us?
• Did production support consume the capacity?
• Did we discover unexpected complexity?
• Or did leadership change the priority halfway through?

Those are very different problems, with very different fixes.

If priority changes are responsible for a meaningful share of unfinished work, better estimation won’t fix delivery. The organization needs to improve how it makes decisions.

I go through each of those causes, and what actually fixes it, in what sprint carryover is actually telling an engineering team.

Slow or unpredictable delivery is one of the problems I help companies with through Yippify, and the reasons work doesn’t finish are where I start, before anyone talks about estimates or velocity.

Finish more. Start less.

One of the simplest ways to improve delivery is also one of the hardest: stop starting things.

When something new becomes important, first ask whether the team can finish something already close to done. Waiting two days to finish the current work is often much cheaper than abandoning it immediately. Emergencies are different, of course. But most business requests aren’t emergencies.

Reducing work in progress creates the thing organizations need most: finished work. Finished work can reach customers. It can generate revenue. It can produce feedback.

Half-finished work mostly produces status meetings.

It’s the same logic behind how I improve execution with small, safe changes. Smaller pieces of work finish sooner, and work that finishes sooner is cheaper to pause or redirect when priorities do change.

Leadership needs to own the consequences

Engineering teams shouldn’t be expected to magically absorb every priority change. If leadership changes direction, leadership should also own the resulting tradeoff. That might mean:

• A delivery date moves.
• Another feature gets removed.
• Scope gets smaller.
• More capacity is needed.
• A customer conversation needs to happen.
• A commitment needs to be renegotiated.

That isn’t engineering pushing back on the business. It’s engineering giving the business enough information to make a real decision.

How should engineering teams handle changing priorities?

Make the cost of the change visible. When priorities change, say why, name the single new priority, decide what stops or slips, decide what happens to work already in progress, and update the dates or commitments that no longer hold.

In practice, these are the five things I try to make clear every time:

1. Why are we changing? There should be a reason people can understand.
2. What is the new priority? Not one of twelve priorities. The priority.
3. What are we stopping or delaying? New work has a cost.
4. What happens to work already in progress? Finish it, pause it intentionally, reduce its scope, or cancel it.
5. Which expectations need to change? Dates, scope, capacity or commitments need to reflect the new decision.

That doesn’t stop priorities from changing. It makes the cost visible.

Agility isn’t constantly changing your mind

Engineering organizations should be adaptable. I want teams that can respond quickly when the business learns something important. But adaptability and instability aren’t the same thing.

An agile team changes direction quickly because it has clear ownership, small increments of work, good architecture and strong communication. A team that changes direction every few days because nobody can decide what matters isn’t agile. It’s just busy.

Architecture plays a bigger part than people expect. Clear boundaries let one part of a system change without touching everything around it, which is much of what I look for when I decide whether something should actually be a microservice.

Short answers