The “I don’t like what they’re saying, so they shouldn’t be allowed to say it” approach to crisis management

TL;DR: Leaders often face push back when they make tough decisions. Trying to “control the narrative” by ignoring or shutting down dissent is a bad idea. It erodes trust, invites negativity, and stifles learning. A better approach is to be transparent, open, and accountable. This builds trust, invites positivity, and fosters learning.

4 minute read

Every seasoned leader I’ve worked with has had to make an unpopular or controversial decision. It’s one of the hallmarks of good leadership. But almost as important as the decision itself, is how you engage with your team following the decision.

It’s understandable. You spend days, weeks, maybe months agonizing over ever detail, every pro and con, every possible outcome. You’ve done your due diligence, and you’ve made the best decision you can given the situation. You’re confident in your decision, and you’re ready to move forward. Then comes the inevitable push back from your team. They have questions, concerns, and objections. They’re not happy with the decision, and they’re not shy about letting you know.

It’s easy to dismiss that negativity as ignorant, personal, or a vocal minority (“you can’t please everyone”), after all, they have a fraction of the perspective you have as a leader. You might seek to “control the narrative”, by dismissing such voices as inviting negativity, undermining your authority, or asking questions that you’ve already answered, thinking its unproductive to further discuss a decision you know is final. Those are all understandable and human reactions.

“Controlling the narrative” is counterproductive

Attempting to “control the narrative” by silencing dissent is not only ineffective, it’s also counterproductive:

It erodes psychological safety - When you shut down the conversation, you send a message that you don’t value the input, the perspective, or the feelings of those affected by your decision. You also signal that you have something to hide, or that you’re not confident in your own reasoning, further eroding trust.
It invites negativity - When you ignore the questions, you don’t make them go away. You just push them underground, where they fester and grow. People will start to speculate, gossip, and complain. They will feel resentful, frustrated, and alienated. They will look for ways to resist, sabotage, or undermine your decision.
It stifles learning - When you avoid the scrutiny, you miss an opportunity to “show your work” and teach through action. An organization’s culture and values is comprised of the underlying assumptions that its members use to make decision. When decisions are transparent, you offer opportunities for the next generation of leaders to learn and grow through passive observation and lightweight participation.

“Caremad” is a good thing

Like your own reaction, your team’s reaction is equally human, and I’d argue, actually a good thing.¹ It means they’re engaged. It means they care. While you’re ready to move on, they just go the news, and they’re still processing. The difference between good leaders and great leaders is in the follow through. Specifically, in their willingness to engage in the emotional labor of helping their team figure out how to move forward, together.

That dissent isn’t disengagement or obstructionism as it may be easy to misread. Quite the opposite. They’re likely “caremad”² - they’re upset because they care about ensuring the best possible outcomes and are trying to figure out how to do that. The reality is, questions and dissenting voices are a sign that people care about the decision being made. They want to understand the reasoning behind it, and they want to have a say in the process. And as a leader, it’s your job to listen to those voices, take their concerns into account, and plot an emotional path forward.

The alternative

The best leaders I’ve worked with have always been open to dissenting voices. They’ve always been willing to listen to the other side of the argument, and to engage with it, even if they’re not willing to change their mind. The playbook is simple: be transparent, open, and accountable. This means:

Be transparent - Share the information, the data, and the evidence that informed your decision. Explain the criteria, the trade-offs, and the implications. Acknowledge the limitations, the uncertainties, and the challenges. Don’t hide, spin, or sugarcoat the facts. Be honest, clear, and consistent.
Be open - Invite the questions, the feedback, and the dialogue. Listen to the concerns, the objections, and the suggestions. Respond with respect, empathy, and curiosity. Don’t dismiss, deflect, or rebut the views. Be receptive, humble, and collaborative.
Be accountable - Take responsibility for your decision, your actions, and your results. Admit any mistakes, apologize, correct, and improve. Don’t blame, deny, or justify the faults. Don’t put the burden on others. Be honest, humble, and results-focused.

Conclusion

While some see leadership as bold and courageous decision making in the face of a difficult situation, I would argue that covering one’s ears and humming in the face of after-the-fact questions shows a lack of leadership in the moment. It’s the equivalent of saying “I would have gotten away with it if it weren’t for you mangy kids…” (for those that grow up watching Scooby-Doo and other Saturday morning “who done it” cartoons).

The alternative to the “I don’t like what they’re saying so they shouldn’t be allowed to say it” approach is to embrace transparency, openness, and accountability. This means acknowledging the complexity and uncertainty of the situation, explaining the rationale and evidence behind your decision, inviting and addressing the questions and concerns of your stakeholders, and admitting and correcting any errors or shortcomings. This also means being humble and curious, listening and learning from others, and being willing to change your mind or course of action when warranted. This also means being clear and consistent, communicating frequently and honestly, and following through on your commitments and promises.

I’d take an engaged team that can have healthy, productive, and respectful disagreement any day over a team that’s checkout out, indifferent, or apathetic. If they don’t care enough about this thing to speak up, it’s likely that there are other, bigger things that they’re not speaking up about either. ↩
A portmanteau of “care” and “mad”, meaning a software developer who is passionate, enthusiastic, and diligent about their work, and who cares deeply about the quality, functionality, and impact of their code and products. A caremad developer is not satisfied with mediocrity, but strives for excellence, innovation, and continuous improvement. For example, “She’s caremad about accessibility, she always makes sure every feature is compatible with screen readers and keyboard navigation.” ↩

Originally published January 8, 2024 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit