swarms/ideas/120-swarm-process/README.md

---
id: 120-swarm-process
title: Formalize swarm process
status: Active
created: 2018-04-02
category: meta
contributors:
    - martinklepsch
    - oskarth
    - naghdy
    - arash009
exit-criteria: yes
success-metrics: yes
clear-roles: yes
future-iterations: yes
---

## Preamble

    Idea: 120-swarm-process
    Title: Formalize swarm process
    Status: In Progress
    Created: 2018-03-30
    Requires (*optional):
    Replaces (*optional):

## Summary
Swarms are the primary structure we use to turn ideas into reality at Status.
People who are excited about bringing an idea to fruition commit to it and make
sure it happens.

At an individual level, this ensures individual contributors are enabled to
achieve autonomy, mastery and purpose, while still ensuring accountability.

At a product team / organizational level, swarms allow us to see what is going
on and which OKRs are targetted, which are not, and generally track progress at
a reasonable level of granularity.

However, the process for creating, running and completing swarms is currently
ad-hoc, lacking in accountability and follow-up, and knowledge of how to do this
properly isn't evenly spread throughout the organization. This swarm will fix
this.

## Swarm Participants
- Lead Contributor: @oskarth
- Evaluation ('knowledge spreading'): Voting mechanism (Polly survey)
- Evaluation ('OKR coverage'): OKR spreadsheet coverage and @nabil
- Evaluation ('enable experimentation'): @martin
- Contributor: @martin
- Contributor: @arash009
- Contributor: @naghdy

- Possibly UX for communicating things during Town Hall, etc.

## Product Overview

**UPDATE: Our thinking on this matter has evolved, see [Permission-less and compensated work at Status](permission-less-and-compensated-work.md) for more**

There are two constraints that govern how this structure is designed and
cultivated. One is that Status the company wants to ship a product, and the
other is creating a decentralized autonomous organization. Since we are moving
towards the latter, the structures we are building must be compatible with this
latter vision, while still being mindful of the first.

The primary difference between the two is that in the former, we are speaking on
behalf of users, and people are generally compensated on a salary or salary-like
basis.

We thus distinguish between swarms (Type-1) as a general concept for bringing
ideas to fruition and getting compensated by it, and 'Status LLC using swarms'
(Type-2). The latter might have more constraints given its immediate goals
and current compensation model. This allows us to be efficient and effective
while the rest of the organization is being built up.

For example, a reasonable requirement for a Type-2 swarms is that they target
OKRs and that PM/UX/Eng should approve an idea before it is given go ahead,
whereas these requirement might not make sense for a Type-1 swarm.

### Product Description
This swarm is trying to work towards the majority of swarms working on
collectively identified OKRs and following processes that:

- are open
- have discrete steps
- stay up to date

#### Type-1 vs Type-2

Specifically to what extent things will differ for these remains to be seen. We
can make one comment regarding the concept of evaluation already though.

Right now we are conflating a few different dimensions:

- external (reality) vs internal self/group-evaluation
- as a person/role or as a mechanism
- as acting on behalf of something or someone (like users)

This has been talked about a lot in various contexts, but there's lack of
clarity around terminology, as well as difference between rules constraints and
optional/possibly desirable customs.

For Type-1 swarms, this ties into discussion around proportional payouts
(internal self-evaluation) and anon evaluation panels / user meditation
(external interface).

For Type-2 swarms, we might want e.g. UXR/PM/Eng to take this role by default,
and/or let swarm lead evaluate themselves (downside: not compatible with
marketplace/nature(ecosystem, evolution pressure), not working in byzantine env,
upside: ease of use and implicit trust good for team cohesion).

### Requirements & Dependencies

### Minimum Viable Product
Goal Date: 2017-04-06

Description:
- i. Ensure new draft / in-progress ideas use PR review process.
- ii. Measure Core/Swarm OKR coverage and communicate this/needs.
- iii. Evaluation terminology and expectations are clarified in manual.

Town Hall Update: 2017-04-09

Progress last two weeks: Move to PR based ideas with discrete steps; make Ideas
repo more homey; measure and communicate OKR coverage; capture participation and
iterations in ideas.

Swarm Stats:
- Registry: 22 ideas committed
- Ideas In Progress: 11 well-defined swarms
- Mempool: 12 ideas under review
- OKR coverage: 50% of Core OKRs covered by at least one well-defined, in progress swarm
- Contributors: 30 people committed to at least one well-defined, in progress swarm

Goals for next two weeks: Ensure repo is kept up to date; support swarm leads
and idea creators; clarify evaluator role; capture and spread knowledge about
swarm lifecycle, definition and roles.

### Iteration 1
Goal Date: 2017-04-20

Description:
- i. Ensure participation commitment (and ideally availability) is captured.
- i. Ensure iteration check-ins is captured for in-progress swarms.
- iii. Town Hall presentation outlining lifecycle, well-definition and roles.
- iv. Send out survey through Polly.

### Iteration 3
(Buffer)

## Success Metrics

Three primary success metrics.

### 1. CORE KNOWLEDGE SPREADING.
90% of core contributors surveyed answer yes to following questions:

- 1.1. It is clear to me when a swarm starts
- 1.2. It is clear to me when a swarm ends
- 1.3. It is clear to me what it means for a swarm to be well-defined
- 1.4. It is clear to me what is expected of a swarm lead
- 1.5. It is clear to me what is expected of an evaluator

### 2. CORE SWARM/OKR COVERAGE.
80% of Core OKRs are explicit covered by well-defined, in progress swarms.

### 3. ENABLE EXPERIMENTATION.
Ensure the following steps are encoded as discrete steps in order to enable
future experimentation and compensation tied to it:

- 3.1. Swarm as it moves throughout lifecycle (draft, in progress, done/aborted)
- 3.2. Participant commitment
- 3.3. Iteration check-ins

## Exit criteria

This swarm will be time-boxed to one month and marked as completed May 1 OR when
success metrics have been met.

## Supporting Role Communication

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).