How To Represent Decisions You Disagree With

How To Represent Decisions You Disagree With
Georg Perlberg: Fishermen before the storm (1845)

Last week I talked with a friend whose organization is going through a cultural change, apparent from decisions that seem to be against company values. I’m not going to go into details to protect confidentiality, but this discussion gave me a good opportunity to write about the topic and the role of a manager in similar turbulent situations.

Let’s take this hypothetical example: You, as an Engineering Manager, were part of a high-level decision that's going to impact your team. An important project is being shut down, somebody is asked to move to another team, the product will take a new architectural direction, etc. You disagree with this, you raised your concerns, argued and debated, but eventually a decision was made, you accepted it, and now it’s time to “disagree and commit”.

But committing is much harder when you have a leadership role. You need to represent this decision, something that you’ve disagreed with, in front of the team. Furthermore: you need to motivate people to support this change to increase the chance of organizational success.

How can you solve this paradox without compromising your image?

However you handle it, this is probably going to be a stressful time for you and the team. Focus on accepting the change and mitigating its impact on people, setting expectations properly, and you’ll get through this easier. Here's what to pay attention to.

Be a Shock Absorber, not a Shield

Managers who see their role as protectors can imagine themselves as shields that isolate the team from all the bad that goes on outside. The expression “shit umbrella” does a great job of conveying this idea visually. I have multiple problems with this interpretation of the role, to sum it up: it treats team members as children who need protection, it hides useful context that could be helpful for them to accept and work with change, and puts unsustainable pressure on the manager.

I prefer a different analogy: the Shock Absorber. Ed Batista in his article here does a great job explaining this concept, so I’ll just summarize it here: cushion the blows by giving context and reframing; provide the appropriate level of resistance (to both directions!); and pay attention to your own resilience.

Being an efficient shock absorber means there’s a constant, smooth, and controlled level of change in your team (as opposed to rare big bang events that turn everything upside down). This is easier on the team and the chance of success of changes is better overall. To maintain this way of working, and help your team get used to constant, low-level change, Will Larson in his book An Elegant Puzzle advises to do exactly one thing differently (not more and not less) in every new project. Beyond increasing resilience, I like this for the experimentation and innovation aspect too. By implementing this, you will already have a small seed of change management in your processes that can help with change anxiety too.

Not trying to be a shield for your team and being efficient at conveying the organizational context will help you in setting expectations too. I experienced a CTO trying to protect their teams from a micromanaging CEO by asking them to come up with pros and cons in a build vs buy debate, eventually having to walk back on the implicit promise of committing to whatever the results will be when the team came to different conclusions to what the CEO had in mind from the beginning. It was a huge waste of time and morale dropped when people found out they had to work on implementing something they advised against. A shock absorber attitude would’ve meant the CTO trying to convince the CEO first before going to the team, but when failing, explaining doing the in-house project as a constraint, and framing it as an exciting green-field technological exploration that’s going to give valuable experience to its participants.

Disagree, commit, but create a valve to let some steam off

There are extremes in how managers represent decisions they disagree with: some push down their internal doubts and put up a charade of fake enthusiasm; others add wood to the fire of disagreement in their team as an attempt to build companionship and distance them from the decision. You need to find a more nuanced approach by disagreeing and committing. Disagreeing and committing is probably even harder for the less senior people on your team, and the best way for them to learn it is by seeing it practiced by their leader, you. Be objective and clear about the arguments of both sides, but explain that the time to debate is over, we need to move on so we can progress and eventually learn from this decision.

Use empathy with the members of your team, people process change differently. Create a safe space for them on 1:1s where you hear them out without judgment. Avoid starting with counterarguments against their concerns. It’s more important to let them share their unfiltered frustrations first and acknowledge that they feel upset (without agreeing with them - you might, but that's not the point now). When they are ready, you can start discussing the details. They will probably be more cooperative after the initial reactions - but if their frustrations persist, check my earlier article on How to Deal with Negative Behavior for tips on mitigating the situation.

Dealing with this can be extremely stressful for you too. Don’t vent to your team, it’s unfair and unproductive. They need you to set an example of disagreeing and committing. Still, be mindful of what this means for your health. Look out for help if the pressure is getting to be too much to handle. It can be tempting to let some steam off in safer spaces like 1:1s with folks on your team. While having a common adversary builds camaraderie, the long-term effects can be much worse. You’re effectively building an “us vs them” culture, which will push the team away from collaboration and will eventually erode their morale and efficiency. Maintain a group of peers, managers, and outside friends you can trust and share your frustrations with from time to time without a negative impact on your team.

Build a Culture of Transparency

There’s a trap that maximalist people who like to control the narrative often fall into: “I don’t want to share until it’s certain to avoid the unnecessary drama” or “I can’t break the news of this topic because I don’t have all the answers yet”. I know, because in my weaker days, I tend to be one of those people. The trap is even more dangerous because there are rare cases when this delayed approach seems to work: the manager can spend a lot of time building a perfect announcement covering all the questions, and the team moves on with a shrug, mostly unscratched.

However, the risks of delaying information are bigger (and they happen more frequently):

  • The later the team knows about a new direction, the longer they operate the old way, and the harder it will be for them to implement the change.
  • If the team finds out news from somewhere else, you’re forced to be reactive and defensive in a sudden — the opposite of controlling the narrative.
  • Witnessing an example where their manager was not sharing information destroys trust and gives anxiety to the team. They will start thinking “What else is being worked on without me knowing?!”.
  • When people lack information, they assume the worst, and the anxiety is impacting their morale and engagement.

To sum it up: you wanted to protect the team – but you caused more stress!

Instead, share early and frequently. Be clear about what’s known and what’s not known yet. Commit to following up when there are more details to know. Make sharing a regular part of your communication cadence with your team: give weekly updates, write public 15fives, participate and share in standups, whatever applies.

Note that this doesn’t mean sharing too much too early either! For example: telling the team a random idea of a potential reorg from a director during lunch, or directly conveying the frustration you overheard from a PM about the bad performance of a feature can do more harm than good. But telling the team that for example “the business review yesterday concluded that we’ve missed financial goals for the third consecutive quarter, and leadership is looking into ways of optimizing” can sound painful but helps a lot in the long run:

  • Transparency builds trust in the team, they’ll know that you’ll share when you can and this can decrease anxiety and fear of a hidden agenda.
  • Making the problems familiar to the team will help accept the decisions that will follow.
  • Sharing an up-to-date context helps with all the decisions they make during the day. (In the above example, the Staff Engineer on the team might decide during an upcoming cloud optimization exercise to sacrifice some performance for aggressive cost savings.)

There are a few things to pay attention to though if you decide to share early:

  • Don’t share confidential information and don’t break the privacy of individuals. If someone on your team asks why you didn’t share something like this before, you can explain that if the information had been about them, you would’ve protected their privacy similarly.
  • Be clear about who the team is allowed to share the information with, but expect that this confidentiality might not be kept. Assuming information will leak will counterintuitively make your life easier in the long run: it forces you to choose your words properly in every situation (don’t say something you wouldn’t like to hear back from someone else) — and not keeping secrets helps build a culture of transparency and trust.
  • Pay extra attention to being consistent. Saying different things to different people on the team will add to the anxiety instead of decreasing it, and will destroy the image of a trustworthy leader.
  • Ensure your manager knows your intentions, and you have at least implicit approval of sharing early information. It’s useful to propose in advance that whatever’s discussed, even on 1:1s, you are free to share with your team unless your manager explicitly asks you not to.

Make the Scope of Change visible

The more you mull over something, the closer it will appear as it’s occupying your thoughts — and things seem larger when you're nearer to them. Take a step back. Is this change that big of a deal? Does it fundamentally impact the team? Sure, losing a beloved project or going through a reorganization is stressful. But at the end of the day, there are probably more things that remain the same than what’s changing.

This perspective can even be harder for the team. Help them see the big picture. List and discuss the things outside of the scope of the change. Focus on what you and your team can have an impact on, and similarly, call out explicitly the scary things that the team has no way to affect, and work on accepting this uncertainty.

For example, a previous company I worked at went through a scary period of time searching for an acquirer, meaning an inevitable leadership change. People on the team had zero means to impact the outcome of this process. Instead of ruminating on possible scenarios and what we would do in them, we doubled down on where we could remain in control and have a sense of purpose: focusing on our tech stack, and making long-overdue simplifications and optimizations.

Recognizing the true size of a change, and all the things that are solid and unaffected by it will help the team focus on continuing the work. This feeling of progress and being in control of our future can further decrease anxiety.

A culture of Safety to Experiment and Fail

Being scrutinized for your decisions and only seeing skepticism and cynicism from others can be paralyzing for everyone. We can’t embrace a culture of innovation if we don’t allow organization-wide experiments too — and experimentation also means some inevitable failures from time to time. We know and embrace this when we do a blameless retrospective of a failed product feature development. Why can’t we take the same attitude to organizational changes? Showing this analogy can be useful for the team to tolerate decisions they disagree with; and embrace the experiment by giving it full support even if there’s some initial doubt. Staying constructive is the only way to ensure we gave our best to make the experiment a success, so we can draw objective conclusions free from subjective opinions.

To extend this thought, don’t be tempted to quietly sabotage or undermine a decision you disagree with. This hurts your credibility in the eyes of your team and upper management too. And what if you were wrong, and this was a good idea that didn’t have a chance to run its fair course because of your actions? Even if you have serious doubts, use this experimentation mindset to give support, set up clear success criteria with a point in time to evaluate, and monitor metrics so you can build a case for a course correction proposal if it’s supported by data.

Draw a line and take action when you cannot disagree and commit

Not every decision has to be supported. It’s possible that something goes against your values, or changes the work experience so much that it’s not worth it for you anymore. Allowing your deep beliefs to be compromised is a sure way to bitterness and burnout. Draw a clear line, and make sure you recognize when it’s being crossed.

If this happens, start with your manager. Share transparently how you’re feeling and the doubts you have about your ability to support this latest change. Involve them in finding a solution together with you, they might have more context to add to the background of the decision. Also, things might feel too overwhelming not because of themselves, but because of other circumstances. You might even need a break to recharge and see things a bit differently.

However, once lines are crossed, be prepared for radical changes that can lead to leaving the team or the company. It’s scary, but keeping your integrity is more important than keeping a job that requires you to be someone else. If things point in this direction, work on making your transition a quick and smooth process for your team and your peers. No bridges are worth burning regardless of how you feel today, and being a martyr will not help your team in any way after you’re gone.

Bonus: Logistics of Communicating Big Changes

Work on a written announcement. You need to balance the efficiency and the timeliness of communication. It’s important to get this out as soon as possible, to get ahead of rumors – but equally critical to avoid ambiguity by choosing your words carefully. Making this written also helps people process at their own pace.

The announcement should be straightforward, staying on facts and low on emotions. You should include: who decided, what was decided, why was the decision made (what problems are we solving or what opportunities are we chasing), who is affected, when is it effective, where can questions be asked and what are the next steps. Use “we” if you can, to avoid building an “us vs them” mindset. If there are obvious missing details (about implementation for example), call them out instead of trying to hide them, and commit to a follow-up later. You’re probably not impartial, so if you can, ask a trusted peer in a different department for an objective review of your draft.

Follow up the announcement with a Q&A session not too far in the future (to avoid anxiety and misassumptions getting spread) and not too soon either (to allow the news to settle and questions to emerge). Standing in front of your whole team and allowing them to ask whatever they want sounds scary. What helped me accept this is realizing that people will talk about this decision and ask their questions anyway — but I can choose to be there having a chance to listen and shape the narrative. Invite a higher-up decision maker in the organization if you think it’s useful — but be ready to take questions yourself if you cannot. Saying “I don’t know” can be very powerful when used sparingly and paired with a commitment to figure out and follow up.

Finally, close the loop during individual 1:1s and skip level meetings if applicable, to take the temperature of the team, and ensure all concerns and worries had a place to be raised. Discuss them, but be forward-looking and focus on the work ahead.

Did you have the chance to handle similar situations? What helped you overcome the challenge? What did you learn from the experience? Share in the comments!

I write about Engineering Leadership topics. Sign up here to receive my future articles by email.

Subscribe to my newsletter

I write about engineering leadership topics.
Sign up to receive new articles.
jamie@example.com
Subscribe