As a team member, how do you voice your disagreement with a decision that you believe is not in the best interest of the company? As a leader, how do you enable your team to disagree with decisions in an equitable and productive way?
We set out to answer these questions at Matter. Although there are a number of useful frameworks for making NEW decisions (e.g., those shared by Gokul at Square, Brian at Coinbase, and Bain), we couldn’t find a framework for handling and supporting disagreements after decisions have been made, especially if you weren’t a part of making that decision. We took inspiration from existing frameworks to create the Decision Disagreement Framework.
Since we began implementing this framework, I’ve been blown away by the results. By embracing this framework, our team has come up with significantly better, more innovative, and less technically complex solutions. No one has felt like they have compromised or “given up” on important issues. In this post, I’ll share how our Decision Disagreement Framework works. You can view our decision disagreement framework template here.
Here is a step-by-step guide for using the decision disagreement framework:
Determine if you should use the decision disagreement framework
If you are the one disagreeing with a decision:
Next time you disagree with a decision ask yourself:
Will the decision slow down, harm, or break the business?
If your answer is yes, use the framework. If not, the disagreement is likely not worth the time and effort involved in using the framework.
If you are on the receiving end of a team member’s disagreement:
First, acknowledge the disagreement and paraphrase the opinion of the person disagreeing to make sure they know they have been heard. Second, ask the person to answer the question above.
Define the disagreement
Brevity is key. Define the disagreement with a maximum of 1 to 3 sentences.
Decide on the decision maker.
There can only be one decision maker. Although each team member will be heard, one person will make a final decision for the good of the business. If you’re a startup with less than 15 people or at a startup that is pre-product-market fit, this person should be the CEO. If you’re at a larger company, the decision maker should be a lead or head of a cross-functional group. This may be a Head of Product, Head of Design, or Head of Engineering. Pick the individual that makes the most sense for the given decision. Large companies may require an additional approver (e.g., a General Manager, Chief Product/Engineering/Design Officer or even the CEO). However, keep in mind that the framework is optimally suited for smaller teams and companies.
Determine the stakeholders
List all the people who need to have input before the decision maker can make their decision. This step is necessary to make sure everyone involved has dedicated time to communicate their opinion and feel heard before the final decision is made.
Prior to bringing stakeholders together, the person who raises the decision disagreement must list 2 to 3 initial resolution options to discuss as a team. This is a key time-saver: By doing this before the group meets, the person raising the disagreement productively processes their thoughts and prepares various options along with each option’s effort, pros, and cons. As an optional step, stakeholders may be sent the various resolution options prior to the meeting.
This step aligns with one of the most important reasons that people join small companies: They want to be a part of the process, not just told what to do.
Remember that it’s okay if their option isn’t part of the final decision, as long as the team has given it thoughtful time and consideration. This means listening to understand or active listening. Contrast this with listening to respond where individuals listen as they think about their own ideas (whether they agree or disagree) and devise their response.
After all options have been reviewed and discussed as a group, the decision maker should ask each stakeholder: Which option do you vote for and why?
In contrast to blind voting, this should be done openly, in the group setting. This is not only an exercise in efficient decision making, it is one for improving transparency, honesty, and candor - key skills for working well within small companies.
After the decision maker has heard from each stakeholder, it’s time for that person to make a decision and explain the rationale. After the decision has been stated, the decision maker requests that each team member commit support to the decision aloud. This creates a shared mindset and path for the team to move forward for the good of the company. Finally, the decision maker will share the decision and its rationale with the entire company within 24 hours. If your company uses Slack, consider sharing the decision in the general channel along with the completed worksheet. If your company does not use Slack, a company-wide email is a good option for sharing the decision and its associated rationale.
At Matter, using this framework has provided a much more harmonious method for dealing with disagreements, as well as significantly better solutions.
Importantly, this framework doesn’t require folks to compromise, surrender, or give up their strong options. Rather, it’s a team-based framework that leads to team-oriented resolutions.
You can view our decision disagreement framework template here.
Not every decision warrants using a decision disagreement framework. Use a decision disagreement framework to work through conflicts that could slow down, harm, or break your business. Let’s look at a couple of examples:
Example 1: Not Appropriate for the Decision Disagreement Framework
Product/Engineering doesn’t like the color of a button. Why isn’t this appropriate for a decision disagreement framework? One, this a subjective opinion that is not likely to slow down your company or harm long-term prospects. Two, this could be resolved with a short conversation with the designer that involves quick feedback, a timely decision, and brief communication of rationale for the decision.
Example 2: Appropriate for the Decision Disagreement Framework
Design created a new user experience with a filtering option for sorting through a list of items. This sorting feature took design less than a day to design. When engineering prepared to work on this feature, they realized it would take two weeks of work due to all the hidden complexities. In this scenario, engineering could use the decision disagreement framework to productively and efficiently meet with key stakeholders (engineering, design, and product) to decide how to move forward in a way that is best for the business.