This is a great question. As a TLDR; the way to deal with strong differences between engineers is not necessarily to build consensus but to have a clear owner in charge of making the final decision.
First, let me say that it is great for an organization when people not only have opinions but feel empowered to express them, even strongly. Conflict avoidance is in fact one of the leading causes of poor decisions and ultimately organizations and teams failing. It is good to encourage discussion especially when a technical decision needs to be made.
However, I have also seen situations where two or more engineers came in with radically different ideas and there was no way to come to an agreement. I have even witnessed cases where this kind of situation ended up leading to pretty bad outcomes. In all of those cases, looking back, the problem was that the decision process, including the owner, was not clear.
Here is the way to address technical decisions/discussions (or most decisions, for that matter): it is called the consultative model. Whenever a (complex) decision needs to be made, start by defining who will be the owner. The owner will ultimately be in charge of making the decision. That person will also be made accountable for the results of the decision. In order to make the best decision possible, this owner will be encouraged to consult with as many engineers as they see fit. Engineers involved in the discussion will be encouraged to express their opinion as strongly as they want. However, they will all accept that it will be the owner the one who will make the final decision. It is up to this owner to make sure the different parts feel like their opinions are being taken into account. However, the goal is not build consensus. The owner can, for example, say things like “I totally get what you are saying, and this is a valuable opinion. However, we are going to go for the other option because of X and Y”.
A couple more things are important when you implement a model like this one:
First, you need to make sure people understand the meaning of “decide and commit”. This means that once a decision has been made, regardless of what your opinion was during the discussion, you should commit to what was decided and work with the group to implement it. This is a really key trait of great team players, and one that can be learned, by the way.
Finally, in this model you should also account for bad decisions being made. As I mentioned before, the main correction mechanism is holding owners accountable for their decisions. However, sometimes it is best not to wait for the outcome of the decision because it might be very costly. It is important that just as engineers feel empowered to voice their opinions during the discussion phase, they should also feel empowered to escalate concerns whenever they worry that a bad decision was made. Escalation is not a failure of this kind of system, it is a feature that should be used as much as needed.
Originally published at www.quora.com.
