From 86b257ca0baf3144989ff79ecd1b1253f4317ec0 Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Thu, 29 Mar 2018 12:26:19 +0800 Subject: [PATCH] Formalize swarm process in progress --- README.md | 1 + ideas/120-swarm-process.md | 146 +++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 ideas/120-swarm-process.md diff --git a/README.md b/README.md index cc8c482..f9131fb 100644 --- a/README.md +++ b/README.md @@ -16,6 +16,7 @@ state it is in. | Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? | |-------------------------------------------------------------------|-------------|------------------------|------------------------|------------------------|------------------------| +| [120-swarm-process](ideas/120-swarm-process.md) | In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [83-energy-efficient](ideas/83-energy-efficient.md) | In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [80-onboarding](ideas/80-onboarding.md) | In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [68-core-metrics](ideas/68-core-metrics.md) | In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | diff --git a/ideas/120-swarm-process.md b/ideas/120-swarm-process.md new file mode 100644 index 0000000..0334188 --- /dev/null +++ b/ideas/120-swarm-process.md @@ -0,0 +1,146 @@ +## 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/or @chad and/or @nabil (TBC) +- Evaluation ('enable experimentation'): @martin +- Contributor: @martin + +- 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 fatter 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/).