How Do You Communicate Changing Priorities to Employees?
You changed the plan — your teams didn't.
To communicate changing priorities to employees, explain the new priority, the work it replaces, the reason, and what changes for each team. Ask affected leaders to explain a concrete tradeoff in their own words. Then check roadmaps, commitments, and capacity to see whether the announcement changed the work.

Then check the choices teams make. An acknowledgment confirms that the message arrived; it doesn't tell you whether anyone changed the queue. Ask what loses when the old request and the new priority compete for the same person.
The new priority has old work attached
Leadership is prioritizing mid-market onboarding. The product queue still includes new SMB customization.
- Compare
- Current priority ↔ active work
- Clarify
- Protected obligation or stale priority?
- Human next step
- Confirm what pauses and who communicates it
A mismatch is a question to resolve, not a verdict on the team.
What should stop when company priorities change?
“Mid-market is our focus” leaves several questions open. Does the team stop accepting small-business requests? Are existing customers still supported? Which roadmap commitment moves? Who can approve an exception?
Without answers, each function has to fill in the gaps. Sales may change its prospect list while Product finishes the earlier small-business roadmap. Both teams can be doing their jobs carefully and still end up on different plans.
Write the tradeoff before drafting the announcement. If leadership cannot name any displaced work, clarify whether the change is a real priority shift, an additional responsibility, or an aspiration. Those require different messages and different capacity decisions.
A five-step priority cascade that reaches the work.
Use these five checks to turn the announcement into different work.
| Step | What to write or ask | What counts as an answer |
|---|---|---|
| Name the change | What takes precedence now, and from when? | One ordered priority statement |
| Name the displaced work | What stops, pauses, or reduces in scope? | Specific work and any protected obligations |
| Translate team impact | What must each affected function do differently? | A change to a queue, commitment, or decision |
| Check understanding | If two requests conflict tomorrow, which wins? | A concrete choice in the team's own words |
| Check the work | What actually changed after the announcement? | Evidence from current plans and commitments |
Keep the company-level statement consistent. Let functions translate it into their work, but ask them to show that translation. You need compatible choices, not a company-wide recital.
What should a priority change message include?
Use this message structure when new-customer focus moves from small businesses to mid-market buyers.
Subject: Mid-market onboarding now comes before new SMB features
From Monday, our product priority is reliable onboarding for mid-market
customers. Recent implementation reviews showed that onboarding needs
work before we expand the promises we make to that segment.
We will pause new SMB customization work. Existing support obligations
remain in place; this is not a change to signed customer commitments.
Product: publish the revised queue and identify displaced items.
Sales: use the approved onboarding scope in new proposals and flag
existing promises that conflict with it.
Customer Success: bring unresolved onboarding dependencies to Product.
The COO owns exceptions. Send the customer obligation, proposed work,
and tradeoff before accepting an exception.
By Thursday, each functional lead should confirm what changes in their
team's work, what stays, and which decision is still missing.
At next week's operating review, we will compare those changes with
the current roadmap and customer commitments.
Use your own evidence for the reason. Name the displaced work and the obligations that stay protected.
A thumbs-up is not a tradeoff.
A reaction emoji or “understood” confirms receipt. To check understanding, ask each lead privately or separately: “A new SMB customization and a mid-market onboarding dependency compete for the same engineer. What happens next?”
Compare the answers before bringing everyone together. Independent answers can show whether leaders are using different exception rules, customer definitions, or dates. A group discussion alone can hide that difference once the first person supplies a plausible answer.
Treat a mismatch as a question to resolve. A team may know about a signed obligation that leadership missed. The information needs to travel upward as well as downward. The company plan may need a correction; the team may need context; sometimes both are true.
How do you check whether a priority announcement changed the work?
To check whether a priority announcement changed the work, inspect the roadmap, customer promises, and capacity allocation, then compare teams' answers to the same tradeoff question. Choose a follow-up date that fits the work. A week is a useful starting point for a weekly operating cadence, but urgent commitments need attention sooner.
| Check | Evidence to inspect | If it still conflicts |
|---|---|---|
| Roadmap | Items added, paused, or reordered | Ask Product to state the unresolved tradeoff |
| Customer promises | Approved proposal language and exceptions | Route conflicting commitments to their owner |
| Capacity | Work actually assigned | Confirm who can change allocation |
| Team understanding | Responses to the same tradeoff question | Clarify the rule and update the message |
Keep the earlier decision and its effective date available. Otherwise a person acting on an old message may look uncooperative when they simply never received the change.
If the same announcement keeps coming back, stop treating distribution as the whole problem. If the message is clear but a dependency prevents the change, resolve the dependency. Communication cannot supply engineering capacity or authorize a commercial exception.
What is Decided?
Decided is an AI operating alignment layer for fast-moving SaaS companies. Clara runs recurring private 1:1 AI voice check-ins about priorities, blockers, decisions, and commitments. Decided compares the answers and prepares an alignment map, a weekly leadership brief, and context for follow-up.
A mismatch is a question to resolve, not a verdict on the team.
People review the context and make the decisions. Before rollout, explain what is captured, who sees the output, how it is used, and whether participants can review notes. Private 1:1 describes the format, not anonymity. Decided is not hidden monitoring, employee scoring, or an automated employment decision system.
Explore Decided for SaaS companies. Try a live voice check-in to see how it works.
Sources.
15Five's guide to communicating workplace change discusses evidence, transparency, and follow-up. Atlassian's weekly team updates play describes a written update practice.
