Change happens. Maybe it’s a new strategic mandate, or altered priorities from customers, or realization that a technical approach won’t work. Your vendor disappears in a puff of smoke, you can’t be ready for unveiling at a conference so the deadline moves, your customer adds more requirements, your executive staff decide the feature should be a licensed extra. As a product manager, you get to be the bearer of bad news to a team that’s been busting hump to make the old plan happen.

The nicest, most reasonable, and most innovative human is still wrapped around an inner primate that doesn’t like change and reacts emotionally. Sometimes that reaction is suppressed, and sometimes it explodes all over everyone, igniting fires in weird places. Here are some tips for handling this situation.

Communicate the change clearly and without emotion. This is hard because you are also human, and have to process your own emotions before you can help the team. So, step one is to use your schedule. Do not be a fast pipe of bad news. Take the news, go yell at your cat or run around the park or do what you need to do, and then communicate to the team. The goal of this is not to make you feel better. Rather, it is to get you out of your own head so you can effectively communicate what the team needs.

Don’t take too much time on this, because your upstream chain of command is going to assume that everyone is cheerily working to the new plan instantly from the point when they made a decision. Some people in charge of oil tankers think they’re steering ski boats, oh well. You’ve probably got half a day or so to prepare your message. Assuming it wasn’t delivered for you in an all-hands or by your engineering manager counterpart.

Now, the medium. It doesn’t matter if you’re in office or full remote or hybrid, what matters is synchronous or asynchronous. News that affects everyone’s schedule should be synchronous, so that everyone who’s available gets it together. That rules out anything using a keyboard: don’t just post in the team slack channel unless you enjoy drama. If you’ve got a standup meeting or call, use that. If you don’t, set one up. You need to get as much of the team as you can, but focus on the engineering manager and team lead, plus project manager and quality assurance lead if you have those. You just need a few minutes, so don’t book an hour.

Review the iron triangle before this meeting starts and figure out what features or dates will get shifted. Adding or changing a feature means something is not getting done: either pick one, or make a short list of candidates to review.

The meeting: “We have a change to handle. Here’s what it is, here’s why, and here’s a rough plan for how to make it happen.” If you’re lucky, this goes smoothly, you answer a couple of questions and let everyone get back to it. If you’re not, there’s fireworks. Maybe directed at the company, or managers, or you, or software engineering in general. Whatever. The important thing is to figure out if these people are trying to have a conversation or just venting.

There’s a useful concept to consider here, amygdala hijack. People who are highly invested in a project may have stronger reactions to project change than you expect. This is a good thing! But it’s also something you need to navigate carefully. The signs may not be clear, either. Culture, gender, neurological differences, hierarchical positions, and more factors will play in. One engineer may shout for an hour and then accept and move on, while another sits silently with gritted teeth applying for new jobs.

Don’t engage with people who are in fight or flight mode. You aren’t going to have a rational exchange of views with someone experiencing amygdala hijack. Hear them, acknowledge their feelings, but do not under any circumstances argue with them. Especially don’t engage in a group setting because fight-or-flight is contagious. You know that advice to ask the quiet people for input? If you’re at all conflict-averse, you should probably save that for next meeting. This call is to impart news and start processes.

“I know it sucks, but this is the situation. Let’s discuss the details tomorrow.”

Now send the email or team Slack to confirm in writing what you said in the meeting. Also, close the loop with your leadership: “I talked with the team, and here’s the rough plan. We can get detailed ASAP.”

On the next standup, you’re looking for confirmation and details. Present your backlog changes and ask for ideas. Team members will probably have calmed down, and even if they’re not happy they’ll at least be able to talk rationally. Your leadership is probably not happy that changing things means deferring older goals, so is there any way to strip them down and retain something still useful?

Ideally that next meeting has you all back on track, solving problems and enabling customers. In order to make sure that’s the case, we help the team process between the announcement meeting and the next standup: if my engineering counterpart is good with people, then I can let them handle it. If they’re not, then I do it. This task has four parts:

• wait. Give them an hour or so.
• contact. A one on one text to let them know you’re open to hear concern.
• listen. Actively listen, repeating back what you’re hearing.
• respond. Aside from change-aversion, the meat of remaining issues probably comes down to there being too much to do. The best thing you can do as a product manager to help with that is to defer tasks from this cycle. So do what you can to make that happen, or explain the situation and build slack time into the next cycle.

One last thing… what if, after all the drama has passed, your team is still convinced this is a bad change? What if you’re convinced too? Then it’s time to plan a push-back. More on that in another post.

Hopefully this will help you get past your next organizational curveball!