Monday morning, the team is told that a tender needs to be submitted first.
But on Tuesday, attention needs to shift to an important quotation.
On Wednesday, another request becomes urgent.
And by Thursday, the team is being asked why the tender has not been completed.
From the founder’s perspective, the team may look scattered.
Why does everything take so long? Why can nobody seem to stay focused? Why do important tasks remain half-finished?
But there may be another explanation.
The team understood Monday’s priority, but by the time they started to act on it, Tuesday’s priority was handed over to them. And when they started doing Tuesday’s work, Wednesday’s work landed on their plate.
The problem is not always that people do not know what matters, or that they are incapable of doing the work. Sometimes, what matters keeps changing before the work has had enough time to move.
When this becomes routine, changing priorities at work stops being an occasional response to new information.
It becomes the way the business operates.
And over time, the team begins to adapt to that instability.
COSMOS OPERATIONAL PATTERN
The Moving Target
A priority is something that deserves attention before everything else competes for it.
But when priorities are repeatedly changed mid-cycle, the signal begins to weaken.
The team may respond to every new instruction. They may stop one task, move to another, and then move again when the next request arrives.
It is not because they lack focus; but it is because their target is constantly being moved.
And every time it moves, some work suffers. It can be:
a task already started
context that has to be rebuilt later
a handoff that is interrupted
a deadline that quietly shifts
another piece of work that remains partially complete
Over time, the team learns that today’s priority may not survive tomorrow. They hesitate to commit fully. Deadlines become less reliable. Half-finished work starts to accumulate. Eventually, the plan loses credibility.
And when that happens, the newest instruction starts winning.
The team is no longer working to a stable priority. It is working to the latest signal.
A priority that changes too easily stops behaving like a priority.
Every Priority Change Leaves Something Behind
Changing priorities does not simply move work from one position on a list to another.
Once the team starts work, they may already have opened files or folders, gathered information, coordinated with others, prepared documents, scheduled follow-ups, or completed part of the task.
They are already in.
When they are asked to shift priority, they have to stop the current work and repeat many of those same activities for the new priority.
Later, when they return to the original task, they do not simply continue from where they left off. They have to remember what was planned, rebuild the context, reconnect the handoff, and work out what has changed since then. Research on task switching also shows that moving between tasks carries a measurable switching cost, particularly as the work becomes more complex.
Imagine the time that gets lost, and the opportunity cost.
The business pays once to stop the work, and again to restart it.
The problem is not always how much work people are doing. It is also how efficiently the business allows that work to move.
Frequent reprioritisation can make a busy team look strangely unproductive.
When the Plan Stops Being Believed
At first, the team keeps adjusting to the changing priorities. Work keeps moving. Everyone appears flexible.
But when agreed priorities repeatedly get replaced before they are completed, the plan begins to lose authority.
The team becomes less willing to trust dates, sequence their work confidently, or make downstream commitments based on the current plan.
The business may still have a plan, but the team may stop referring to it.
Because if the plan changes too easily, it loses credibility.
And the team then responds to the “Priority of the Day,” which eventually starts defining how their entire day is spent.
That is when changing priorities stops being an occasional management decision and starts weakening execution itself.
Not Every Priority Change Is a Problem
Priorities will change, because situations change.
New information may emerge. A customer issue may become critical. A dependency may fail. A commercial opportunity may genuinely deserve faster attention.
The problem is not the change itself. The problem begins when every new request is allowed to reopen the plan.
A useful priority change should begin by answering one question:
What has changed enough to justify changing what had already been agreed?
There needs to be a clear reason for the priority to shift. But then the business must also decide what happens to the work being displaced.
Because reprioritisation is not simply choosing something new. It is also consciously choosing what will now have to wait, and when that work will return to the plan.
The Business should have a Rule for Changing Priorities
A priority should not change simply because a new request has appeared.
There need to be some rules, some questions that the business should clear before the shift decision is made:
What changed? What new information makes the current priority less important than it was before?
Who needs to be heard before it changes? The founder may make the final decision, but the people doing the work need to surface what is already underway, what may be delayed, and anything important that may not currently be visible to the founder.
What stops? A new priority should not simply be added on top of everything already underway.
What happens to the displaced work? It needs a clear owner, status, and point at which it returns to the plan.
Who needs to know? Everyone affected by the change should receive the same priority signal.
Where is the change recorded? The plan itself should change, not just the conversation around it.
This also means the team should not simply accept every new instruction and quietly abandon the existing plan. If important work is already underway, that needs to be made visible before the priority is reset.
This does not need to become a complicated approval process.
It simply means that reprioritisation becomes a conscious operating decision, rather than a new instruction dropped into the middle of existing work.
Because a business does not only need a way to decide what matters. It also needs a way to decide when what matters is allowed to change.
A priority change should create a new plan, not just a new instruction.
Structure: It is unclear how a priority change should be challenged, confirmed, or communicated before work is redirected.
Systems: The current workload, work in progress, and effect of the change are not visible enough when the new instruction is given.
This is partly a Structure issue: the business needs clarity around how agreed priorities are challenged, confirmed and changed.
The founder may still make the final call. But the system should make sure that the decision is made with enough information to answer:
If this becomes the priority now, what are we consciously moving down?
That small discipline changes reprioritisation from a reaction into an operating decision.
Changing a priority is a leadership decision. Making the consequences visible is what turns it into a system.
The Goal Is Not Stability. It Is Credibility
Changing priorities is part of running a business.
The problem begins when the team cannot tell whether today’s priority is a real decision or simply the latest instruction.
When priorities change without a clear reason, without visibility of the work already underway, and without deciding what will now wait, execution becomes unstable.
The team may still be busy.
But busy work is not the same as dependable progress.
A strong priority system gives the team enough stability to finish important work, while still allowing the business to respond when circumstances genuinely change.
Because the goal is not to make priorities permanent.
The goal is to make them credible.
Frequently Asked Questions
Because changing priorities often creates stop-start work. People have to pause what they are doing, shift context, begin something new, and later return to unfinished work. The more often this happens, the more time is lost rebuilding context and restarting interrupted tasks.
There is no fixed number. Priorities should change when new information, risk, customer needs, or business conditions genuinely justify it.
The important question is not how often priorities change, but whether each change is deliberate and whether the effect on existing work is understood.
The founder or designated business leader may still make the final decision.
But the people closest to the work should first make visible what is already underway, what may be delayed, and what other important commitments may be affected.
The business should decide what the new priority replaces, what work will pause, who still owns that work, and when it will return to the plan.
A new priority should not simply be added on top of everything else.
Teams need more than a list of priorities.
They need a clear way to surface current work, understand why a priority is changing, record the new decision, and know what happens to the work being displaced.
The goal is not to prevent change.
It is to make sure everyone is responding to the same priority signal.
Want to Build Clearer Priorities Into the Way Your Business Operates?
When priorities keep shifting, the problem may sit deeper than the task list.
Use the COSMOS 4S Systems Checklist to identify where Structure, SOPs, Systems, or Scale may be creating hidden operational gaps.
COSMOS 4S SYSTEMS FRAMEWORK™
Has Your Business Outgrown Informal Operations?
Take the free COSMOS 4S Systems-Maturity Self-Check
to identify whether Structure, SOPs, Systems or Scale
needs attention first.
Looking for a different starting point?
Explore free checklists, starter kits, guides and ready reckoners in the
COSMOS Vault →
Related Reading
If changing priorities are only one part of a wider execution problem, these COSMOS resources may help:
The COSMOS 4S SME Systems Framework™ and COSMOS 5R Leadership Framework™ are proprietary tools developed by Chhavi Jain, Director, Cosmos Consulting. These frameworks are unregistered trademarks (™) and may not be copied, reproduced, or repurposed without explicit written permission.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
