mirror of https://github.com/status-im/swarms.git
150 lines
5.5 KiB
Markdown
150 lines
5.5 KiB
Markdown
## 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
|
|
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.
|
|
|
|
### 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)
|
|
|
|
Possibly something related to Type-1 swarms and communication thereof, but to me
|
|
once success metric 3 is achieved this is a slightly different focus and thus
|
|
ideally a different swarm.
|
|
|
|
## 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/).
|