Consent Decision Making

Everyone who’s affected by a decision should be directly or indirectly involved in the decision making. This could mean all members of a Team, a Delegate Circle, everyone holding the same role, a list of affected people or all VSHNeers.

Therefore we use The Process from Sociocracy 3.0 to make governance decisions notably on guidelines, processes, definitions, protocols or policies, and team or role assignments.

This process is implemented through the VSHN Improvement Process, which tracks decisions and ensures that periodic reviews on drivers and agreements actually happen. This process can also be used in meetings or through other written implementations.

As Consent Decision Making is about making good enough for now, safe enough to try decisions, we live a culture where people feel comfortable to raise potential objections at any time. Everyone has the possibility to voice Objections against proposals, decisions, existing agreements, processes or activities.

The Process

Proposals become Agreements when they’re considered good enough for now and safe enough to try until the next review.

Unresolved Objections prevent proposals from becoming agreements.

1. Present the Driver

Formulate and then present the Driver to the group accountable for the affected domain (for example the Team or a Delegate Circle), hereafter called "group."

2. Agree on the Driver

Check with the group to see if there are any objections to this Driver. Change the Proposal as necessary or drop the Driver and stop here.

3. Present a Proposal

Create and present a Proposal to the group. There are many ways to create a proposal.

4. Clarify Questions

Let the group raise questions, answer and document. Change the proposal to address the questions where appropriate.

5. Get a brief response

Before we move on to collecting objections, request brief feedback from the group to find out what the level of acceptance of the proposal might be, before we move on to collecting objections.

6. Check for Objections

Collect Objections to this proposal, inviting everyone affected to seek for possible objections: "Can you think of any possible objections to this proposal?"

When doing this asynchronously, set a time frame during which you’ll collect, register, and integrate possible objections.

7. Resolve Objections

Resolve one Objection at a time by working with the group to amend the proposal until a "good enough for now, safe enough to try" solution is found.

8. Celebrate Agreement

Proposals become Agreements when they’re considered good enough for now and safe enough to try until the next review.

Actually celebrate it and announce the agreement, thank everyone that was involved in the process!

9. Consider Concern (Optional)

Record Concerns if that’s considered valuable.

Resolve Objections

Those accountable for an activity or (proposed) agreement in question, are responsible for considering arguments and addressing Objections that are raised.

Resolve objections one at a time by using the information they contain to make and evolve amendments to the proposal. Choose an option for resolving an objection that looks most promising, and if that fails, simply pick another one:


  • Discuss with the VSHNeer that raised the objection to amend the proposal

  • Check with the proposal owner (creator) to amend the proposal

  • Request help within the Delegate Circle, the Team or VSHN wide: Who can (help to) resolve this?

In groups:

  • One or more discussion rounds on How would you solve this objection?

    • It helps to try the Rounds method to maintain equivalence and support effective dialogue.

    • Timebox the meeting

    • Forum discussion "How can we resolve this objection?"

There is also the option to defer a proposal:

  • Create a new proposal

    • Form a group to research and write it

    • Same VSHNeer or group creates an alternative proposal

  • Restart decision making on the the new proposal

  • Drop the proposal when you can’t resolve all Objections


To understand our decision making process it helps to understand some basics that we borrow from Sociocracy 3.0. You neither have to read the whole Sociocracy 3.0 guide nor have to be an expert in its concepts and principles.


A Driver is a person’s or a group’s motive for responding to a specific situation. A Driver is usually formulated from four parts:

  • Current situation

  • Effect of current situation

  • The organizational need in relation to this situation

  • The impact of attending to that need (the result)

“The kitchen is in disorder: there are no clean cups, the sink is full of dishes and it’s not possible to quickly grab a coffee and get right back to work. We need the kitchen in a usable state so we can stay focused on our work.”


A proposed (change of a) guideline, process, protocol or policy to guide the flow of value, in a written documented form.

Proposals usually start as a merge request, for example for the VSHN Handbook.


When a Proposal has no unresolved Objections the Proposal becomes an Agreement.

Agreements exist in written form only, for example in the VSHN Handbook. An Agreement always has a date when the next review has to happen.


An objection is an argument demonstrating (or revealing) how a (proposed) agreement or activity can lead to unintended consequences, or that there are worthwhile ways to improve it. Withholding objections can harm the ability of individuals, teams or the whole organization to achieve their objectives.

Things to consider when seeking out potential objections:

  • Why the intended outcome would not be (fully) achieved: effectiveness

  • Why it would be wasteful to proceed as proposed (or previously agreed): efficiency

  • The negative consequences something would have: side-effects

Test arguments to qualify as Objections

When someone raises an argument for changing a Proposal, check that the argument reveals how leaving things unchanged will or could lead to consequences you want to avoid, or that it informs you of a worthwhile way to improve how to go about achieving your objectives.

Helpful questions:

  • How does the argument relate to this specific proposal or agreement?

  • Does the argument reveal how a (proposed or current) activity or agreement:

    • harms response to any organizational driver?

    • can be improved right now?

    • prevents or diminishes someone’s contribution towards responding to a driver?

    • is in conflict with the organization’s values?

    • is considered not ‘safe enough’ to try?

Read more here.


Not all arguments raised are Objections. Distinguish between objections, which always reveal useful information, and other arguments that are based only on assumptions, or a personal preference or opinion.

If in doubt about whether you have an objection or a concern, be proactive and check with others to see what they think too.