Changing Direction: How to Make Your Team Do Something They Dislike

Excerpted from How to Deliver Bad News and Get Away with It: A Manager’s Guide by Mahesh Guruswamy

A good manager should aim for bottom-up thinking 99.9% of the time. As a leader, you come up with a set of problems that are aligned with your company’s goals, and your team comes up with creative ways to solve those problems. Let your team self-organize and find solutions. However, there will be moments when you have to force your team to do something they don’t want to.

There are two versions of this. The first is when you have to realign your team in a direction you know they will hate, but you firmly believe in the new direction. For example, you are going to sunset (stop a project midway) a project your team loves to work on; it isn’t contributing positively to the bottom line, so you decide to kill it.

The other version of this is when you do not agree that the thing you are going to do is the right thing, and you know your team will dislike it, but you have to do it because your boss (or their boss) has made a corporate decision and you have decided to disagree and commit. Examples would be a mandatory return to the office, bonuses slashed because of macroeconomic conditions, and so forth.

The third and last version of this is when you have to go back on a promise you made to the team. Examples could be compensation changes you promised but had to walk back because of exogenous changes, promotions you promised but had to walk back, and so on.

Organizing for Clear Communication

The first thing you should do is sit down and organize your thoughts into a structured communication plan. The communication plan should address the following (at the minimum):

1. What is changing?
2. Why is it changing?
3. Why is it changing now?

Here is an example document that I wrote for myself when I decided to decentralize the on-call rotation and spread it across all product development teams:

1. What is changing? Starting on mm/dd/yyyy, the Operations Team will not be the first-line responder for paging events generated by our automated system monitors. Instead, the team that owns a specific subsystem will start responding to pages directly. This means that our team will now be directly responsible for responding to paging events 24×7, starting mm/dd/yyyy.
2. Why is it changing? The Operations Team owns only a specific part of our system, specifically the hosting infrastructure. They have little knowledge about how various customer-facing features work, and typically, they turn around (introducing delays) and end up calling/texting/paging the tech lead of the product development team to actually fix the issue. As our systems grow larger and our teams grow correspondingly larger, the only logical solution is to decentralize first-line support. Last, the Operations Team is not incentivized to fix any long-term subsystem issues that the paging events surface, because they don’t own those subsystems. The product development teams do.
3. Why is it changing now? It is changing now because of two things. First, our application footprint has considerably grown both in size and in complexity over the last few years. Second, the production engineering team is getting paged multiple times every day, including nights and weekends. An operationally burdened team that has no means to reduce its paging burden will eventually burn out.
4. How does it affect the daily rhythms of the team? The engineering managers will work with their teams to come up with an on-call rotation and runbooks for their services. All teams here at [company name] have more than five engineers, so assuming a weekly rotation, most engineers will have to go on-call once a month. The engineering managers will be in the escalation chain; for example, if both the primary and secondary on-call don’t respond to the page in fifteen minutes, the system will automatically page their managers. I will be the final node in the escalation chain.
5. Can I opt out of this? No, everybody in engineering will be part of the on-call process. If you have paid time off scheduled on an on-call week, you can swap slots with somebody else on your team.
6. What does success look like? The end goal is to increase the overall stability of the systems we manage. Currently, the team who is handling the alerts can’t fix the underlying issues that caused the alerts, because they don’t own those systems. As a result, the alerts keep occurring and the underlying stability issues don’t get fixed. With this change, the team getting paged can fix the issue causing the alerts, which will eventually lead to higher overall stability.
7. Will we prioritize production stability over product development? In most cases, yes.

Stick to Your Plan

Change is hard. Most adults do not like to be told what to do. Resistance to directives is as old as humanity itself. Most people want to experience life in their own way. Stumbling along, failing, learning, adapting, and eventually evolving into better versions of themselves. Business teams are no different. They want to figure things out on their own. They want to experiment with new technologies, to learn from their mistakes, and to become a better team. So, when a leader gives them a directive, expect resistance. The resistance will come in many forms. The employees will characterize you as an outsider. They will accuse you of being authoritarian. Finally, they will portray you as somebody who is trying to change the culture of the organization. All of those will hurt.

As you roll out these changes, make sure you’re available to your teams to answer any questions or concerns they might have. In those conversations with employees, resist the temptation to revisit decisions. There will always be a group of people who will be passionately opposed to any meaningful change. If you have people-pleasing tendencies like me, you might be tempted to go back and change the decision you have made to please those groups of people. Resist it at all costs. Organizational changes take time to show results. You won’t know if you made the right decision in a day or two. It will take weeks and months and sometimes even years. Also, going back on your decision will cause whiplash, and soon your team will start feeling that you are not a decisive leader, further deteriorating their trust in you. Listen to everybody’s concerns sincerely, but make it clear to everybody that you intend to stick to the decision you have made for at least six months or longer. Give everybody a voice but not a vote.