Decision-Making at VSHN

A team has a lot of different work - customer support, incident handling, proactive product development tasks, and more. Given the sheer volume, they need to prioritize and organize who does what. The Product Owner prepares the backlog (Proposal), what to include in the sprint (an act of Leadership). Unless there is a reason why starting the sprint as proposed is a risk, the team commits and begins (Consent Decision in Operations). Everyone is now working on tasks (Operations).

During the sprint, a major incident occurs. In the next standup meeting, the engineer working on it asks for assistance. Another engineer volunteers to help but points out that doing so will prevent the completion of two sprint tasks (another act of Leadership). The team deems fixing the incident as a higher priority, and in the absence of reasons against it, two engineers are assigned to address the incident (again Consent Decision in Operations).

Over the next four sprints, the team consistently struggles to collaborate with another team due to differing Jira issue types. They agree that this issue is a significant hindrance (Consent to Driver). One team member suggests adopting the same issue types as the other team uses. With no objections raised, they proceed to make the change (Consent Decision in Governance).

— A little story that summarizes everything outlined on this page.

Decisions at VSHN are made in both our operational and governance contexts. In both scenarios, we try to follow the principles of Sociocracy 3.0 to make decisions collectively involving the people that would be affected by the decision (Equivalence) and based on reasoned arguments (Consent). We understand what is needed, propose a next step or a solution and if there are no reasons why it would hurt us, why we couldn’t at least try it, we move forward with it.

Introduction

Decisions are powered by reason and involve affected people, not rank or position.

At VSHN, we embrace non-hierarchical principles for Decision Making and leadership. The power to influence decisions lies with reasoned arguments and not with people in specific roles or ranks, and we involve the people responsible and those affected by the decision. It’s crucial that decisions are made, and therefore equally crucial that someone takes the initiative to drive them; otherwise, they simply won’t occur. These principles apply at all levels within the organization.

Operations vs. Governance

At VSHN, we differentiate between Operations and Governance. This distinction, while a key concept in Sociocracy, isn’t exclusive to it. In any organization, team, or even for individuals, there’s a need to perform work (Operations) and to define the environment, our goals, rules, processes, etc. (Governance).

Example

Planning and prioritizing your work, and doing the actual tasks you planned, is Operations. But determining how you plan your work, for example whether we do Scrum or plain Kanban, or setting customer communication guidelines that we want to stick to, that would be Governance.

Operations

Operations relate to doing the work and the organization of day-to-day activities within the constraints defined by governance. This is what most of us engage in on a daily basis - the actual work you do, such as programming, calls with customers, resolving incidents, doing backoffice admin work, you name it. It also includes organizing and planning your work.

Although "Operations" is a common term in tech teams referring to unplanned tasks like incident responses and customer requests, in this context, Operations includes both planned and unplanned day-to-day activities.

Coordination

Coordinating and planning work is also within Operations and not Governance, as refining tasks and prioritizing them are one-time decisions.

Tracking Operations

In theory, you could keep all the work you have to do in your mind, remembering what to do and by when. In practice, this only scales to a certain point. Also, because you share the responsibility to get the necessary work done with your other team members, it’s important to write down, visualize, and track progress on work items. The most common way is through task lists, Jira issues, etc. Larger chunks of work are planned in Epics, Projects, etc. - Kanban is usually a great visualization to make work (Operations) visible.

Governance

Governance, on the other hand, involves the process of setting objectives and making and evolving decisions that guide how you do your work. This includes making and evolving policies and procedures about how we work together, distributing responsibilities and power, selecting people for roles and teams, accounting for dependencies between teams, distributing resources, developing strategy, setting priorities and objectives, and making all consequential decisions about products, services, tools, technology, security, and more.

Who does Governance?

Governance is not exclusive to a board or managers. It happens at all levels within the organization. Everyone who makes or contributes to governance decisions is a part of this process, often even unknowingly. We encourage everyone to participate in governance decisions, whether in dedicated governance meetings, on the fly during the working day, or in one-off meetings dealing with a specific topic. For transparency and future reference, we document our decisions.

Teams at VSHN are self-governing, meaning the whole team shares the responsibility to make and evolve agreements which govern how the people doing the work in their domain create value.

Defining the team’s domain - their purpose, responsibilities, products, etc. - is also part of Governance. This is done collaboratively by the Delegator and the Delegatees (the Team). This is also what ensures that the Delegator remains overall accountable for what is delegated to the Team - if they don’t deliver, they are stuck addressing issues or other issues, the Delegator needs to work this out together with the team, but doesn’t do it for them.

Tracking Governance

In theory, you could do this off the top of your head, understand the need to change a policy, propose something verbally, and ask people if they see any potential objections. If not, move forward and implement what you proposed. In practice, like with Operational work, this doesn’t scale, and it’s very difficult to reach a common understanding of what the problem might be and what your proposal implies.

  • For larger topics (drivers), we have an implementation in Jira - the VSHN Improvement Proposals. This is essentially a way to track the status of a governance item from understanding the problem, identifying who is responsible, finding a solution, making the decision, and reviewing the implementation and effectiveness of the decision.

  • It’s okay to make smaller decisions directly in meeting agendas, for example. Be aware, however, that we still document and proactively inform the people affected by the decision, and that we still need to follow up later to see if what we decided is effective.

VSHN Improvement Proposals, aka VIPs, are not Governance, they’re a way to track Governance. Governance needs to happen whether we use VIPs, something else, or nothing to track our Governance decisions. Compare tracking your normal work in Jira. Whether you use Jira or not, the work is still there, needs to be prioritized, worked on, and done.

Consent Decision-Making

The following provides an overview of key elements in making decisions based on the principle of Consent. This is a very big topic, while we encourage you to try based on what you learn here, we acknowledge that it requires quite some education, training, and experience to facilitate this in group meetings or semi-asynchronously. Our goal is to have enough Facilitators who can assist you and facilitate for you where useful. Still, to participate, a common understanding of the following elements is crucial.

Consent

Giving Consent to something or consenting means the absence of Objections. It’s not to be confused with Consensus, which would mean that everyone has to agree.

Implicit Contract of Consent:

In the absence of objections to an agreement, I intend to follow through on the agreement to the best of my ability.
I agree to share objections as I become aware of them.

Objection

An Objection is an argument relating to a (proposed) agreement or activity that reveals unintended consequences we’d rather avoid, or that demonstrates worthwhile ways to improve right now.

In turn, having no Objection means:

  • Despite my best effort I can see no reason why the proposed agreement would harm our organization.

  • I see no way to significantly improve the proposal on the spot.

  • I don’t think the proposed agreement conflicts with an existing agreement.

  • I think this proposal is *good enough for now and safe enough to try*.

You can’t have an objection - you might have a possible objection, when you dig into it together you find out what is behind your argument and whether it reveals risk or ways to improve the proposal. If that is the case, it’s an objection and we need to somehow change the proposal to integrate what we learned.

Proposal

At VSHN, you’ll often hear that we follow a proposal until there are reasons not to (an Objection). But where do Proposals come from?

First, you agree on the driver - the problem or opportunity you want to address - and then you research the issue to learn more about the details and understand all the important considerations and constraints before moving on to brainstorming ideas and finally using all the information you’ve gathered to draft a proposal.

Driver

Always start with the Why.

A Driver is a simple but powerful concept. It’s about understanding what is needed, collaboratively, to have a common understanding of what the problem or opportunity is, that you need to address. After that, we can start finding solutions and create a Proposal.

The tricky thing here is, that we as humans are often taught to think in solutions, but actually, the power to do the right thing lies between understanding what’s needed and then finding out what to do - Move out of autopilot. This is especially important, as other people might have a completely different understanding of what is needed.

If we skip understanding the Driver (the Why), it’s likely that we get stuck in "Moving forward with a proposal until there is a reason not to" (Consent), because people will question what we need to do and why in the first place.

Leadership

Leadership at VSHN plays a crucial role in facilitating decision-making processes and ensuring that decisions are followed up on. Leaders are not just those in traditional hierarchical roles - every individual is empowered to lead within their area of responsibility. It’s easy to say "No one takes the needed decisions" - what is likely the case is that it’s more an issue of missing leadership and not flawed Decision Making - Ensure that we see the need, insist that we come up with a proposal and that we decide together.

See The big risk in VSHN’s culture for an overview of this topic.