Rough consensus
I’m reading the wonderful book Working In Public by Nadia Eghbal, and there is a reference in there to a note from the Internet Engineering Task Force (IETF) on the type of consensus they’re looking for.
Author Pete Resnick used this wonderful term “rough consensus”:
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
That is, our credo is that we don’t let a single individual dictate decisions (a king or president), nor should decisions be made by a vote, nor do we want decisions to be made in a vacuum without practical experience. Instead, we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs.
Having full consensus, or unanimity, would be ideal, but we don’t require it: Requiring full consensus allows a single intransigent person who simply keeps saying “No!” to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding.
This is the way I think every technical leader in an organisation should behave: try to seek consensus, but don’t let that process block you from moving forward.