Most of the time, consensus is NOT the goal.
As a tech-lead at Facebook coaching mid-level engineers, I often found that they would search for consensus when starting to lead or drive projects.
I wrote this post back then, I’m copying this post externally so that I can share and reference it.
I’ve seen people on the team sometimes struggle to get folks behind a product/design/code decision when in discussions with the larger XFN team. I’ve heard engineers ask: “can we get to a consensus on this?” in chats and in quips. Or in experiment review: “can we get a team agreed upon decision?” The situation is complicated because every option has strong advantages and significant drawbacks.
This note will try to address one issue which may be creating some of those “gridlock” moments. As with a few of my notes, how well this works for you may vary.
When you’re trying to make a group decision, I think you should think of your goals as:
- To get to the best decision.
- To get alignment around the execution of that decision.
Often, people will treat these as getting to “consensus,” which I’ll define as “general agreement” around what is the best course of action. Most of the time, getting to 1 and 2 might lead to consensus anyways, but the goal should not be to get to consensus.
Here is the best note I’ve read on making these XFN decisions, and it’s been effective for me in my time at Facebook. Disagree and Commit is another way to achieve 2 even without consensus.
Why not consensus?
Designers, PMs, managers, Content Strategy, etc., all come to a single problem from different perspectives and with different experiences. The time it would take to get that many diverse perspectives (a good thing!) to see a single solution as the “right” one is not feasible — even if it were — not worth the time. Especially if you’re in the driver seat of a conversation, you might be working with people who have little context about the situation, and getting them — no matter how thoughtful, wise, or smart they are — away from other reasonable directions towards a single, shared one is hard.
Striving for consensus also often leaves you with the safest, tried-and-true solutions because it happens to be the least controversial rather than one that includes necessary new paths. This problem compounds because if every decision requires consensus, it also might hinder your ability to plan multiple steps ahead because every step will require new coordination and consensus-finding.
We know this fact to be obvious when looking at other decisions made at a distance from us: the right decision is not always the most popular one for the people involved.
But practicing it in our day to day work is a lot harder. Because the nature of consensus is that many people agree, going from “finding consensus” to “getting to the best decision” also takes courage.
Not a maverick either
On the other hand, you can’t simply make unilateral decisions and then convince everyone to do what you think is right. Diverse perspectives, especially across functions, provide both vital information and useful opinions in decision-making. It’s that feeling when an XFN partner brings up something that you hadn’t considered or takes a strong position against an assumption you originally thought was trivial.
You also need the team to be aligned around executing towards the final decision, so the decision must at least be acceptable for nearly everyone.
As the driver of the conversation, you might not even have thought that a direction is the best one yourself, but trust in the judgement of someone else or of a particular argument. That’s okay too.
What is the “best” decision?
I purposefully left “best” vague. “The best decision” varies based on the specific context in which you’re making a decision. For example, for the News product, “best” often is what provides people with the most accurate and complete reporting. Right now, it might also be what reduces CPU usage the most. In some cases, if your goal is to boost morale, the best decision might be the consensus decision. But in making decisions, the reason for choosing one course of action over another should be to better achieve an end goal or to better satisfy a principle; most of time, it is not to “find consensus” among the decision-makers. Again I will plug this note.
Facebook values consensus-building
Facebook values consensus-building and democratic decision-making. You can see it in interviews loops, during PSC calibration, and in the day-to-day culture of the company. Not all of these processes treat consensus as a goal, but they clearly value it. As a value it’s good and useful in many contexts.
And while we continue to value consensus, for most of the decisions we make while roadmapping or designing UX or architecting code, we should treat our goal as to “get to the best decision based on group input” — whatever that entails in the specific context — rather than trying to “get to a consensus.”
