How we make decisions

As explained in Organizational Structure VSHN is organized in a flat hierarchy around a role-, squad- and chapter-model.

We use Consent Decision Making from Sociocracy 3.0 to make decisions notably on guidelines, processes, protocols or policies and squad or role assignments.


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

We want to 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. This includes decisions already made and decisions made by Management.

Daily business

We don’t have to use Consent Decision Making to decide in our daily work, for example when making technical decisions or in Customer Service-, Project- or Product- Management this could be inefficient. It can make sense though when it affects other VSHNeers or imposes potential risk to the company strategy, technical roadmap or the organization itself.

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.

Step Goal Verbal example Written example

1. Present the need and impact

Know what and why we need to act

This is a problem for me, I think we should change this, otherwise we can’t do that

Jira issue or discussion forum topic explaining the need and imapct

2. Consent on the need and impact

Make sure we’ve the same understanding

Do you understand the problem and agree that something needs to be changed?

Jira issue comments or forum comments questioning the need or impact

3. Create and present a Proposal

Make your potential solution visible

I think the problem could be solved by doing this and this

Written proposal on a Wiki page or as a handbook merge request, announced to the group of affected people

4. Collect and answer (clarify) questions

Everyone understands the proposed solution

Do you understand how I propose to solve the problem?

Start a written FAQ and request feedback and questions (wiki page or handbook merge request)

5. Get a brief response (reactions)

Before going into handling Objections know the level of potential acceptance

Would you be okay with this?
Usually combined with previous step.

Check acceptance from a subset of the group of affected people, for example via chat

6. Collect Objections

Collect objections against proposal

Do you have any objections?
Give time to think or even shift the process to a written form at this point

Announce Proposal again and give a time window to raise objections as merge request comments or comments on the wiki page.

7. Resolve Objections

No objections left to reach consent

Discuss and change proposed solution

Discuss, request amendments and change proposal until no objections are left

8. Document Agreement and celebrate!

Decision documented and announced to the group of affected people

Document the decision and how it was made, crucial in verbal decision making

Merge and release handbook changes, remove "Work-in-progress" markings from wiki pages

During the whole process the need and impact should be visible by making it part of the written proposal (description of the merge request or a Why/Goal section on the wiki page)

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 chapter, the squad 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 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, all concerns were taken into account and all questions were answered, the Proposal becomes an Agreement.

Agreements exist in written form only, for example in the VSHN Handbook.


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.