## 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/).