Decision Making

Introduction

This is a proposal for a decision making system at Vizzuality. The goal of the proposed changes is to empower individuals to make decisions, because we trust people will make the best decisions.

We arrived at it by reviewing our current decision making processes and identifying their weaknesses. We researched systems used in other organisations to design our own.

General criteria

If you have a decision that affects other people and has a risk attached to it you need to start the decision process by:

• checking existing guidelines;
• using the advice process to make decisions;
• using the consent process to develop new guidelines.

Exclusions

Some decisions are legally required to be made by the shareholders of the company and are therefore excluded from this system. Those are any decisions that put the company at risk of bankruptcy / legal issues or affect property right of shareholders.

Examples:

• Selling the company
• Company going public
• Changing the status of company
• Very big investments

Guidelines

Clear, concise and easily accessible Guidelines are paramount to the efficiency of the decision making process.

Guidelines have a hierarchic form with Purpose at the top. Vision and Strategic Priorities are the next level.

Next, we have broad organisation guidelines, like conflict resolution, resource allocation, information flow, feedback loops and decision making.

Finally, at the base we have functional domain guidelines, e.g. project workflow, quality standards, technical documentation.

Maintaining good guidelines will allow us in many cases to take decisions independently, taking into consideration their scope and impact.

In absence of a specific guideline we should look for a relevant higher-level guideline. The guidelines themselves can be modified using a collective decision making process, as described later.

Scopes & Risk

Another pillar of the proposed decision-making process are the criteria to apply when classifying the decision and processing it through the proposed framework.

Scopes

The first dimension according to which to classify the decision is its scope, understood as people affected by the decision. We have identified the following scopes:

• Company

  Decision affects everyone in the company directly or indirectly. Many of these decisions will be covered by organisation guidelines, for example:

  • To bid on a project - vision & strategic priorities
  • To open a new office - resource allocation
  • To dismiss someone - conflict resolution
  • To carry out a performance review - feedback loops
  • To disclose salary brackets - information flow

• Office

  Decision affects everyone in the office. Similarly to company scope, many decisions here will be covered by organisation guidelines, for example:

  • To grow the office - vision & strategic priorities / resource allocation
  • To buy equipment - resource allocation

• Functional Domain

  Decision affects everyone within a functional domain:

  • Backend
  • Frontend
  • Business development
  • Operations

  Many decisions here will be covered by functional domain guidelines, for example:

  • To establish communication channel with client - external communication
  • To start working on a project - project kickstarting

• Project team

  Decision affects everyone within the project team. Similarly to functional domain scope, many decisions here will be covered by functional domain guidelines.

  Because of the overlaps, a decision made in this scope is typically covered by functional domain guidelines with a possibility of feeding back.

Risk

The second dimension according to which we can classify a decision is the impact it has on the company. Put simply: “What negative outcome will the decision have for the company if it goes wrong?”

We could consider an number of types of risk associated with decisions:

• Strategic - e.g. investing in technologies that quickly become obsolete
• Legal - e.g. running services non-compliant with GDPR
• Financial - e.g. buying expensive equipment that turns out to be faulty
• Reputational - e.g. losing a contract with an influential client

A risk assessment (high vs low) will help understand how much advice and dissent to encourage in the decision-making process.

Framework

We propose the following framework for making decisions.

There are broadly 3 paths a decision can go through:

Decision based on existing guidelines

IN SHORT: If there is a sufficient guideline that covers your proposal, you can make the decision right away.

sufficient ≠ specific

can ≠ have to

The easiest path is where a decision can be taken simply based on existing guidelines. This path will help reduce the current decision overload.

** EXAMPLE PROPOSAL**: To buy new mugs for the office

• Guideline sufficient? YES (Guideline: you can spend up to X euros from the office budget)

• Follow guideline? YES

• DECISION I will buy new mugs for the office

Decision based on advice process

IN SHORT: If there is no guideline or you choose not to follow it, you have to start the advice process. You can follow the advice.

can ≠ have to

Where an appropriate guideline does not exist or where it exists but the proponent believes it should not be followed, they initiate the advice process.

1. Express the proposal. Provide justification. Document it. Assess the risk and define the scope (upper-most for high risk).
2. Conduct due diligence. Are there any known constraints (financial etc)? Are there any contradicting decisions already in place?
3. Everyone in the advice process can voice their opinion but it does not need to be followed.
4. Anyone in the advice process can call the need for guideline creation / amendment, and becomes responsible for leading it.
5. Decision can still be passed while guideline change process takes place. Consider the risk assessment to decide.

EXAMPLE PROPOSAL : To go to a conference X

• Guideline sufficient? NO (Guideline: you can use a personal training allowance of up to X euros per year but you must consult with peers / manager)

• Advice process

  • My proposal is to go to conference X to learn about Y.
  • The risk level is low (based on cost) and the relevant scope is the functional domain + manager.
  • I checked I have sufficient funds in my training allowance.
  • I checked that the dates don’t coincide with any known events.
  • I consulted with peers in my functional domain and my manager. One of my colleagues noted there is another conference Z that might be better for me to go to.
  • Nobody called the need for a more specific guideline.

• Change guideline? NO

• Document decision outcome: I documented the expected outcome: I will learn about Y in the conference, which will be useful for upcoming projects, and report back in the form of a lightning talk for the functional domain team.

DECISION I will go to conference X.

Guideline change based on consent process

IN SHORT: If anyone in the advice process raises the need for creating / amending a guideline, that person has to start a consent process. You can wait for that process to be complete.

can ≠ have to

A process to change guidelines can be started where existing guidelines are deemed insufficient. This is carried out using the consent-based (“no principled objections”) process, loosely based on Holacracy.

1. Express the proposal. Provide justification. Document it. Assess the risk and define the scope (upper-most for high risk).
2. Open the proposal to everyone in identified scope for a round of clarifying questions.
3. Set a time frame for a round of reactions.
4. A proposal cannot pass if it is blocked. It can pass if people disagree. A block is a principled objection, which needs to be explained and further discussed to either withdraw the proposal or amend it allowing the block to be resolved.

EXAMPLE PROPOSAL: To bring dog into the office

• Guideline sufficient? NO

• Advice process

  • My proposal is to bring my dog into the office to reduce my stress levels and get a better work-life balance.
  • The risk level is high and the relevant scope is the office.
  • I checked there are no contradictory health and safety regulations we have to comply with.
  • I consulted with peers in my office. One of my colleagues has an allergy.
  • One of my peers would like to bring a cat. They called a need for a general guideline about bringing animals to work. They started a company-wide consent-based process.
  • I will not pass the decision without the collective process, because the risk level is high.

• Change guideline? YES

• Wait? YES

• Consent-based process

  • The proposal is for everyone to be able to bring animals into the office.
  • The scope of the proposal is company-wide.
  • After the round of clarifying questions the proposal was amended to say “for everyone to be able to bring well-behaved animals into the office”
  • In the objections round the proposal was blocked by a person with an allergy.
  • The proposal was then amended to say “for everyone to be able to bring well-behaved animals into the office, provided no-one in the office has allergies”.
  • This proposal passed and this became a guideline.

• Document new guideline

• Guideline sufficient? YES

• DECISION I will not bring my dog into our office because we have people with allergies there.

Responsibility

Document your decision process and your intended outcome.

If a decision fails, we don’t start blaming anyone. Instead we use a review process or retrospective to understand what happened, why, and how we can improve next time.

Do a retrospective when the intended outcome was not achieved.

Include the people who were involved in the decision process and the people who were affected by the outcome.

For example, everyone has to say three things that went well, and three things that could be improved next time. Learn from each other.

Online tools to support decision making

To address the issue of lack of transparency in current decision making process, we need a tool / set of tools available to everyone, which will allow us to:

• Organise guidelines in an easily navigable and searchable format (to support “Predefined process for guideline creation / modification” in the diagram)
• Document outcomes of decisions (to support “Predefined process for documenting decision / guideline exception” in the diagram)
• Organise people according to the scopes they belong to
• Facilitate the advice process (group consultation)
• Facilitate the consent process (company wide voting)

Links to other systems

The operation of the decision-making system relies on guidelines and processes coming from other systems. This allows the decision making flow to remain simple and not necessarily concerned by potential issues arising from misuse, for example:

• Bad decisions are made? - feedback loop
• People bypassing the system? - feedback loop
• Opposing interests surface? - conflict resolution
• Decisions leading to overspending? - resource allocation
• Insufficient transparency? - information flow