VSHN Improvement Process

We want a process to capture tension, formulate the needed change and enable us to make decisions quickly enough to transition iteratively while actively involving the right people and making the whole process transparent for everyone. This will make sure that we can make informed decisions efficiently, as everyone knows when to get involved on what.


The VSHN Improvement Process is designed to capture ideas or tensions, understand the Driver (the need) for change or to define things, then develop a Proposal and decide that we implement that Agreement and re-evaluate it periodically. It’s the written governance backlog for circles and an implementation of our Decision Making Process to make good enough for now, safe enough to try decisions, until we review every decision again.

A governance backlog is a list of steering decisions and is therefore fundamentally different from the operations backlog in which the actual value-creating work is planned.
The following are examples what VIPs can be used for in different circles



VSHNeers Delegate Circle

Salary System, Working hours, employee benefits

Solutions Delegate Circle

Creation of new Teams, Which team should own a new customer

Products Delegate Circle

Creation of a new Team, Definition of product groups

A Product Team

New team member joining from another team

A Solution Team

A team member leaving to another team


Defining a Domain in VSHN

The Process

For every Tension we notice, we formulate and agree on the Driver. This Driver is created as a VIP (VSHN Improvement Proposal) in Jira. All documentation, especially the Proposal, is linked to this Jira issue. The Jira issue is the ultimate source of truth (status, accountable circle, links, etc.) as it enforces the process using a Jira workflow.

Only when following the workflow we can ensure that we make good decisions by involving the correct people at the correct point in time, that everything is written down transparently for everyone to find and we actually review our decisions.

VIPs are never done as longe as the Driver is valid, they go through the process again and again on every review date. For example a VIP might define the Domain Customer Solutions, on the review date of the VIP, we check whether the driver on why we’ve this domain is still valid or not and make sure the domain description is still accurate, amending it if needed.

The workflow is based on Navigate Via Tension, Respond to Organizational Drivers and Consent Decision Making from Sociocracy 3.0 - adapted to our needs.


Clarify and assign Driver

After you or someone else created a VIP, we try to understand and clarify the organizational driver (that’s what’s happening and what’s needed in relation to the organization), then we assign it to the accountable circle who then respond as required.

Options to respond
  • Start forming a proposal

  • Drop the driver if it isn’t an organizational driver

  • Assign the driver to another Circle if it’s not in your domain

  • Respond with a direct operational action when the driver is within your domain


The Circle (set by the Accountable Circle Jira field)

It’s only natural that you often have a proposal when you should actually write the driver first. It’s okay to do both at the same time, but until agreed on the Driver stay in this state.

Creating Proposal

There are many ways of Proposal forming, usually it happens very naturally in a collaborative way using Wiki pages and communicating in chat, presenting it in meetings, etc. They typically follow a similar pattern though:

  1. Consent to driver in the accountable circle. This can usually be done by presenting the driver (the VIP) in written form in the chat and answering:

    • Is this driver relevant for us to respond to?

    • Are there any essential amendments to what has been written down so far?

  2. Collect considerations phrased as questions relating to possible solutions. Questions either reveal constraints (information gathering questions) or possibilities (generative questions).

  3. Answer any information gathering questions if possible. Do this in written form on the wiki page of the VIP.

  4. Prioritize considerations.

  5. Gather ideas as possible ingredients for a proposal.

  6. Design a proposal for addressing the driver considering the creative ideas and information gathered so far. This is usually done by a smaller group of “tuners” and written in the Proposal section of the VIP Wiki page or directly as a GitLab Merge Request.

Choose 2—3 Tuners. Tuners are the ones who actually write the proposal and later amend it as needed during decision making. The first tuner is set as the Assignee of the VIP in Jira and the additional tuners are added as Participants. Make sure there are no objections against the tuners and also consider expertise from potentially tuners outside of your circle.

This step is done when the Tuners agree to have a good enough for now, and safe enough to try proposal.

  • The Circle (Accountable Circle Jira field) until Tuners are defined

  • Tuners (Assignee and Participants Jira field)

Feedback handling

We get a brief response to find out the level of acceptance by presenting the proposal in the circle and maybe other selected people that would be affected or could have a useful opinion. When okay, we can go to the next step, otherwise back to Creating Proposal.


Tuners (Assignee and Participants Jira field)


Days (decided by the Tuners)

Decision Making

We present the Proposal to everyone in the Accountable Circle and everyone that the Tuners defined as affected groups or people.

Affected Groups and Affected Users are fields in Jira that you can use to track who is affected in addition to the Accountable Circle.

We’re resolving objections one by one either through clarification or amending the proposal. We document concern which was revealed from objections.


Tuners (Assignee and Participants Jira field)


Usually 1 week (decided by the Tuners)


All objections were resolved, so we’ve an Agreement. We’re now planning follow-up tasks to implement what was agreed on.

  • Assignee of the VIP creates follow-up tasks

  • Coordinate in the Circle who owns the follow-up tasks

In Effect

  • Affected people were informed about the agreement.

  • Follow-up operational tasks are planned as needed
    or we’re convinced that the agreement alone will bring the intended effect.

  • The VIP has a due-date for next review set.

On the review date, the accountable circle has to re-evaluate the driver and verify that the agreement actually has the intended effect (addresses the diver) on the organization.

Alternative states


We dropped the driver, because it either:

  • wasn’t an organizational driver

  • we couldn’t consent to the driver

  • it was considered obsolete during re-evaluation

Operational Action

The driver is addressed via a an operational action within a domain - no group governance decision needed.


Jira is how we track VIPs - The Driver and the Proposal is on a Wiki page or in a Merge Request. The VIP itself is created in Jira - the resulting unique VIP number is used everywhere else.

You find the VIPs here in Jira:

  • Project: VSHN Improvement Proposals (VIP)

  • Issuetype: VSHN Improvement Proposal

VIPs can be anywhere in the Wiki as long as the wiki page and Jira issue are linked in both directions. There are two common places for the VIPs though:

Wiki Pages, with the page name following the schema VIP-X - <name of driver = Jira summary> contain:

  • The Driver formulation follows Describe Organizational Drivers

  • The Wiki page might contain information to help understanding the driver

  • Questions, Concern and Objections documentation

  • Proposal is (one of) linked:

    • On the same Wiki page

    • GitLab Merge Requests (usually the VSHN handbook), include VIP-X in the title of the MR

The driver formulation can be in Jira, until we go into Creating proposal.

Merge Requests

If you don’t need a wiki page, you can simply use a merge request in GitLab as long as you link the MR and Jira issues in both directions.

Questions handling

There will be questions especially during proposal forming. We document questions and the corresponding answer either on the [Wiki] page or in the Merge Request. The Wiki page template has a Questions section for this and the in GitLab MRs use the comments.

Documenting Concerns

When we resolve objections during Decision Making we should document concern on the Wiki pages or in the Merge Requests. Concern can be considered when implementing a VIP.

Objection handling

The Wiki page templates has a section Objection handling with a table where we document each potential objection and the steps taken to resolve it. In Merge Requests this happens as threads with comments.

Inter-Linking of VIPs

VIPs can:

  • relate to each other (relates to in Jira) - use sparingly where it helps to understand the context.

  • address a parent driver (address driver in Jira) or have sub-drivers (has sub driver in Jira) - mandatory

Making Proposals and Change visible

We want to make everything we’re working on visible to everyone so that everyone knows what’s around to read, comment, object or help with. As VIPs are normal issues in Jira, we can easily filter, sort and show the VIPs on boards in Jira and Confluence.

This allows us to have an automated overview to:

  • Show in Weekly Company Meetings

  • Make the governance backlog visible in Delegate Circles

  • Base a "weekly OrgDev newsletter" on it or similar.

  • Sync with external Coaching about what’s currently going on

Out of Scope

VIPs are for organizational things where a governance decision is needed.

VIPs aren’t
  • about tracking operational issues which clearly fall within an existing domain’s core tasks.

  • "tickets" on which you actually work to implement something. Implementation is always done in follow-up tasks.

  • an instrument to set goals. For this we use 2-year goals or Product Bets.

This process is tracked and reviewed as VIP-1