Tell me about a time when you had to communicate a change in direction that you anticipated people would have concerns with.
Asked at:
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle delivering unwelcome or risky news when people may disagree, worry, or feel disrupted by it. They are usually looking for more than presentation skill: they want to see judgment about the change itself, empathy for the audience, and whether you managed the transition rather than just announcing it. For senior candidates especially, this question often reveals how you lead through uncertainty, resistance, and trust-sensitive moments.
“Describe a time you had to announce a decision or plan change that you knew people might resist.”
“Tell me about a situation where you had to deliver unwelcome news about a project's direction.”
“Have you ever had to pivot a team or project and explain that shift to people who were invested in the original plan?”
“What's an example of a time you had to communicate a change that affected other people's work and wasn't likely to be popular?”
Key Insights
- Don't frame this as 'I told them and they eventually accepted it.' You need to show that you understood why people would have concerns and treated those concerns as legitimate inputs, not obstacles.
- You should explain why the direction changed, how you tailored the communication, and what you did after the announcement. Many candidates stop at the meeting itself, but interviewers care a lot about follow-through.
- If the change was unpopular, name the tradeoff clearly. Strong answers show that you can communicate hard decisions honestly without sounding defensive, dismissive, or overly political.
What interviewers probe atlevel
Top Priority
You want to sound neither passive nor bulldozing: listen to concerns, respond to them, and help the work move forward.
Good examples
🟢I invited questions, clarified what was fixed versus still flexible, and adjusted task sequencing based on a valid concern about deadline risk.
🟢I listened to my teammate's concern about redoing work, and while the direction stayed the same, we agreed on a smaller first step to reduce wasted effort.
Bad examples
🔴Once I explained the decision, I told the team we should stop revisiting it so we could make progress.
🔴I asked if anyone had concerns, but when a teammate disagreed, I said we'd already decided.
Weak answers either shut concerns down or let them drift; strong answers acknowledge concerns and channel them into constructive next steps.
You do not need to solve every concern alone, but you should show that you listened and understood what made the change hard for others.
Good examples
🟢I knew the concern wasn't really the code change itself; they were worried we'd miss our deadline if we reworked it.
🟢Before presenting the update, I talked to the people affected and learned they were concerned about losing work they'd already put in.
Bad examples
🔴People were mainly resistant because they don't like changing how they work, so I just explained that this was the new plan.
🔴My teammate pushed back, but I knew the change was right, so I focused on getting them to stop debating it.
Weak answers reduce concern to stubbornness; strong answers identify the underlying risk, incentive, or emotion driving the concern.
Valuable
Don't end the story at the announcement; show what you did next to help the change actually work.
Good examples
🟢After the discussion, I updated the task list, checked in with the teammate most affected, and helped with one part of the rework so we stayed on schedule.
🟢I wrote down the revised plan and followed up a few days later to make sure the confusion points were actually resolved.
Bad examples
🔴After I told everyone, I moved on to my tasks and assumed the team would adapt.
🔴Once the direction changed, there wasn't much else for me to do besides wait for people to update their work.
Weak answers treat communication as the finish line; strong answers show ownership of adoption and execution.
Pick a real change that affected how work got done for more than just a few minutes, even if the scope was small.
Good examples
🟢I had to tell two teammates that we were cutting a feature from our sprint after testing showed we couldn't finish it reliably.
🟢I explained to my project group that we needed to rework part of our implementation because our first approach was creating repeated bugs.
Bad examples
🔴I told my teammate we should rename a few variables because the style guide changed, and they were a little annoyed, so I explained it.
🔴Our standup time moved by 15 minutes and I had to let the intern know because they preferred the old time.
Weak stories use a minor update that doesn't test real judgment; strong stories involve a change with visible impact on plans, effort, or expectations.
Example answers atlevel
Great answers
During an internship project, I had to tell two other interns that we needed to drop one part of our planned feature and rework another part because our testing showed the original approach was causing a lot of errors. I knew they'd be concerned because we'd already spent time building it, and one of them was worried we'd miss the demo deadline. Before our team meeting, I checked the results with my mentor so I was confident about the reason for the change, and in the meeting I explained what we found, what we were changing, and what work could still be reused. I also made sure to ask for concerns, and one teammate raised that the rework might be too big, so we agreed to do a smaller version first and keep the rest as optional. Afterward I updated our task list and took on part of the cleanup work myself. We made the demo on time, and the smaller version was much more stable.
At my first job out of college I was the only frontend developer assigned to build a landing page for a nonprofit, and the product manager plus the client wanted a large autoplay carousel in the hero to match their brand. When I tested it, the carousel caused clear accessibility problems for screen readers and drastically slowed page load on low-end phones, so I anticipated they would be upset about changing the visual idea. I did a quick accessibility check and performance timing, and prepared two alternatives: a static hero with subtle transitions and an accessible manual slider that preserved motion but required user control. In the meeting I explained the specific accessibility and performance issues, showed before-and-after measurements, and walked them through mockups of both alternatives so they could judge the look. They worried about losing the brand impact, so I proposed launching with the static hero to hit our deadline and then A/B testing the manual slider later, and I volunteered to build the accessible slider myself. We shipped on time, the client liked the finished page, and the later accessible slider improved engagement without sacrificing usability.
Poor answers
On a class project, I had to tell my teammates we were changing our approach because I thought my design would work better. Some of them had concerns since they'd already started on the first version, but I explained that changing now would save time later. I posted the new plan in our group chat and asked everyone to switch over. There were still a few questions, but once they saw the finished result, it was fine.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid February, 2026
Meta
Manager
Early October, 2025
Meta
Manager
Late August, 2025
Meta
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.