How to Reduce Friction With Engineers When Priorities Keep Changing
Recently at an event, someone asked me: "How do you reduce friction from engineers when leadership changes direction or often shifts priorities?"
A lot of PMs immediately jump to stakeholder management tactics. Frameworks. Communication templates. Escalation paths.
But before any of that: check the fundamentals.
TL;DR: Most PM-engineer friction isn't caused by priority changes. It's caused by a lack of trust built up over months of small failures. Fix the foundation first (respect commitments, give context, do proper due diligence). Then when changes happen, explain the why, be transparent about who made the decision, and make trade-offs a discussion rather than a directive.
Before expecting trust, check the basics
This is where most PMs get it wrong. They treat engineer pushback as a communication problem. "If I just frame it better, they'll be fine with the change."
No. If the day-to-day experience of working with you is painful, every single change becomes friction. Even small ones.
Before expecting engineers to gracefully accept shifting priorities, ask yourself:
- Do you respect your own commitments? If you said "this is the priority for the quarter" and changed it three times already, why would anyone believe the fourth time?
- Do you do enough due diligence before writing specs? Half the "priority changes" engineers deal with aren't real pivots. They're PMs realizing mid-sprint that they didn't think things through. That's not leadership changing direction. That's you creating churn.
- Do you give engineers context instead of just tasks? "Build this feature" vs. "Here's the user problem, here's how we validated it, here's why this solution makes sense" are completely different experiences for the person building it.
- Do you respect their inputs and constraints? When an engineer says "this will take 3 weeks," do you hear them out? Or do you immediately push for 1 week because "leadership needs it sooner"?
These are not soft skills. These are the foundations of professional credibility. If you're failing here, no amount of stakeholder management technique will save you when priorities shift.
Why priority changes create friction in the first place
People don't get frustrated because work changes. Work changes all the time in every company. Engineers know this.
They get frustrated when work appears random.
When there's no visible logic behind why last week's "critical" feature is suddenly deprioritized for something nobody was talking about a month ago. When they feel like they wasted two weeks of focused effort on something that apparently doesn't matter anymore.
The frustration isn't about the change itself. It's about the feeling of being on a treadmill where nothing you build seems to matter long enough to ship.
That's what you need to solve. Not the fact that priorities shift. The feeling that the shifts are arbitrary.
Now assume the foundations are strong
You respect your commitments. You do proper due diligence. You give context. You listen to engineering constraints.
Leadership still changes direction. Priorities still shift. That's the nature of the job.
What do you do now?
1. Explain the why, not just the what
This sounds obvious, but watch how most PMs actually communicate priority changes:
What most PMs say: "We're pausing the notifications feature and moving to payments integration instead. Sprint starts Monday."
What engineers hear: "Everything you've been working on doesn't matter. Start over."
What actually helps: "The board reviewed Q2 numbers and retention is dropping faster than expected. Payments integration directly impacts conversion, which is the lever leadership wants to pull this quarter. The notifications work isn't wasted, it's just moving to next quarter."
Connect every change to something concrete:
- Customer impact
- Business goals
- Revenue implications
- Metrics that the team already cares about
When people understand the reasoning, the same change feels 10x more reasonable. Not because you convinced them. Because they can see the logic themselves.
2. Don't own decisions that aren't yours
This is a subtle but critical mistake I see PMs make constantly.
A PM walks into standup and says: "I've decided we need to shift focus to X." The engineers push back. The PM gets defensive. Now it's a fight between the PM and the team.
But the PM didn't decide anything. Leadership did. The PM is the messenger.
Be transparent about that. Not to deflect blame, but to create clarity.
Instead of: "I changed priorities."
Say: "Leadership wants us to optimize for X because of Y. Here's the context they shared with me. Here's what I think it means for our sprint."
You're creating clarity, not acting like a command center. Engineers respect honesty about where decisions come from. They don't respect PMs who pretend every top-down change was their brilliant strategic insight.
The nuance: this doesn't mean throwing leadership under the bus. "The CEO is being unreasonable again" is not transparency. "The board wants to see revenue numbers improve before Series C, so we're prioritizing monetization features" is transparency.
3. Make trade-offs a discussion
This is where most of the avoidable friction lives.
The wrong way: "Drop the search improvements and build the admin dashboard instead."
Why it creates friction: You just told someone their work doesn't matter while simultaneously adding more work. And you didn't ask for input.
The better way: "We have a new priority from leadership. Given this change, what should we deprioritize? What's the cost of pausing what we're working on?"
Engineers usually resist arbitrary work. They rarely resist thoughtful trade-offs.
When you bring a priority change as a trade-off discussion:
- They feel respected (their opinion matters)
- They see the full picture (not just "do this new thing")
- They often find better solutions ("actually, we can ship a lighter version of both")
- They own the plan (instead of feeling like it was imposed)
Every new priority has a cost. Acknowledge that cost openly instead of pretending the new thing is free.
The trust bank account
Think of your relationship with engineers as a bank account. Every day, small actions either deposit or withdraw trust.
Deposits:
- Following through on what you said you'd do
- Shielding the team from unnecessary churn
- Giving them credit publicly
- Explaining context before asking for work
- Defending their time estimates to leadership
Withdrawals:
- Changing direction without explanation
- Saying "just trust me" when asked why
- Presenting their work to leadership without crediting them
- Overcommitting timelines without consulting them
- Treating specs as final when you haven't done proper discovery
When your account is full, priority changes are easy. People assume there must be a good reason. They give you the benefit of the doubt. They adapt quickly because they trust the process.
When your account is empty, even small changes become battles. Because every change confirms what they already suspect: this PM doesn't have things under control.
The PMs with the least friction
The product managers with the least friction from their engineering teams are not the ones who convince people the best. They're not the best communicators. They're not the most charismatic.
They're the ones who build enough trust that people assume there must be a good reason when things change.
That trust doesn't come from a single great presentation or a well-crafted Slack message. It comes from months of consistent behavior. Respecting commitments. Doing due diligence. Giving context. Listening to constraints. Being honest about where decisions come from.
The priority shift conversation is the exam. Everything before it is the coursework.
Putting this into practice
If you're a PM dealing with frequent priority changes (and most of us are), here's the playbook:
- Audit the foundation. Are you creating unnecessary churn through poor due diligence or flip-flopping? Fix that first.
- Build the trust account. Small, consistent actions over weeks and months.
- When changes come, lead with why. Connect to outcomes the team already cares about.
- Be transparent about decision sources. Don't pretend top-down decisions are yours.
- Make it a discussion. Ask "what should we deprioritize?" instead of dictating.
This isn't about being a better communicator. It's about being a better collaborator. The communication just reflects what's already true about the relationship.
How ProductResume helps
This kind of PM maturity, building trust, communicating trade-offs, leading through change, is exactly what hiring managers look for on a product manager resume. If you're showcasing leadership and cross-functional collaboration on your resume, make sure your bullets reflect this depth. Score your PM resume to see how well your experience translates on paper, especially around the Leadership & Impact dimension.