Graham King

Solvitas perambulum

Decider Protocol

behaviour
Summary
Most teams lack a clear decision-making process, leading to incoherent choices and confusion about who made decisions. The Decider Protocol offers a structured method for teams to achieve unanimous decisions efficiently. In this protocol, a proposer presents an actionable proposal followed by a simultaneous vote from team members, signaling "yes" (thumbs-up), "no" (thumbs-down), or "support-it" (flat hand). If more than 30% or any absolute "no" votes are received, the proposal is dropped or revised using the Resolution Protocol. This follow-up process involves addressing concerns of any "no" voters to amend the proposal until consensus is achieved. Final decisions require all team members to adhere to and advocate for the agreed-upon plan.

This section is inspired by Software for your Head, by Jim and Michele McCarthy.

Most teams have no explicitly defined, full-blooded, decision-making apparatus. Yet the quality of life of that team is determined by the choices they make. Every meeting, and each creative act, expresses a team choice. Without a clear process for making decisions the choices are often incoherent, to the point of team members not knowing exactly who decided what, when.

The Decider protocol is a decision making process. It provides a formal way for teams to achieve unanimous decisions in an efficient manner.

h2. The Decider Protocol

The proposer says, “I propose…”.

The proposer offers a concise, actionable proposal. No more than one issue is resolved per proposal. The behavior expected of the voters if the proposal is accepted is clearly specified.

The proposer says “1-2-3”, then all team members vote simultaneously in one of three ways:

  • Yes voters give a thumbs-up.
  • No voters give a thumbs-down.
  • Support-it voters show a hand flat.

Voters requiring more information must vote “no” to stop the proposal before seeking information. Passing is not allowed. A yes vote means “yes I support this proposal and I am ready to champion it”. A support-it vote can be translated as “I believe that this proposal is probably the best way for us to proceed now. I support it, though I have some reservations. I don’t believe I can lead the implementation of this proposal, but I commit not to sabotage it”. A no vote means “No, right now I can’t support this proposal”, because it is plain wrong, because some details need clearing up and looking into, or because I don’t understand it.

Once the vote is taken, the proposer counts the votes and takes a decision:

  • If the combination of “no” and “support-it” votes is too great (> 30%, as determined by the proposer), the proposer drops the proposal.
  • If any of the “no” votes states their absolute opposition to the proposal, the proposal is dead. An absolute “no” means that there is no condition that the voter can imagine that would change their vote. It is a tradition, though not mandatory, for an absolute “no” voter to make a new proposal following the death of the proposal killed by their vote.
  • If there are just a few “no” voters (outliers) the proposer uses the Resolution protocol to resolve those people’s concerns.
  • Otherwise, i.e. if everyone voted “yes” or “support-it”, the proposal passes, and becomes part of the team’s plan of record.

Voters do not state why they voted as they did.

During the proposal no-one speaks except:

  • the proposer when stating the proposal or using Resolution
  • any no-votes when using Resolution or declaring their “no” an absolute one.

Any absent team members are responsible for acquiring information about the vote, and are bound by the decision as if they voted for it. If the person would of voted “no”, they must now make a new proposal as soon as possible.

Once a proposal passes, each team member is accountable for personally carrying out behaviors specified in the Decider decision, and no member has more or less accountability than any other. Each is also accountable for insisting that the behavior is carried out by the other team members.

h2. Resolution

When there are only a few “no” votes (outliers), the team uses the Resolution protocol to attempt to bring those outliers in.

The proposer asks each outlier in turn: “What will it take to get you to endorse the proposal ?

The outlier may state at any time, but no later than in response to the above question, that his vote is an absolute “no”. The proposal is then dead.

More often, the outlier states succinctly, declaratively, and precisely what he requires to endorse the proposal. If given what he requires, the outlier promises to drop all resistance to the proposal and to provide affirmation and support for it instead.

As needed and as possible, the proposer makes an offer to the outlier. If in the judgment of the proposer the adaptations to the proposal are minor, the proposer may employ an unofficial ‘eye-check’ of the non-outliers to see if there is general acceptance to the changed proposal. If you are opposed to this implicit new proposal or require a formal re-statement and a new vote, you make make this requirement know during this interval. If the required changes are more complex, the proposer makes a new proposal, and the Decider protocol starts again.

“Yes” and “support-it” voters do not speak during Resolution.

If the outlier changes his vote to “yes” or “support-it”, then the decision to adopt the proposal is committed, and becomes part of their plan of record.

h2. Other protocols

Decider and Resolution are part of The Core. The other protocols are here: Core protocols (pdf) The authors website is here: McCarthy Technologies