7.9 KiB
| id | title | status | created | ended | category | lead-contributor | contributors | exit-criteria | success-metrics | clear-roles | future-iterations | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 120-swarm-process | Formalize swarm process | Completed | 2018-04-02 | 2018-05-01 | meta | oskarth |
|
yes | yes | yes | yes |
Preamble
Idea: 120-swarm-process
Title: Formalize swarm process
Status: Completed
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 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.
Town Hall Update: 2017-04-23
Progress last two weeks: Update manual and template, clarify swarm’s role in org; static site index; ongoing support and knowledge spreading. 80% of Core OKRs covered!
Goals for next two weeks: Retainer. Start to wind down swarm. Bounty up outstanding issues. Ongoing support.
Lessons learned so far: Updating manual README index is terrible UX.
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
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.
Mini-post mortem
Success metric 2 and 3 achieved. Success metric 1 ended up at 3.7 / 3.7 / 3.9 / 3.9 respectively, whereas we were aiming for 4.5/5. for this one. So still some work to be done there (see section below). Also got a static site index as a bonus at (ideas.status.im)[https://ideas.status.im/].
Will require ongoing support to make sure we follow through, but this can be done outside of swarm model, similar to code review etc.
A few survey take-aways
See raw results in (survey-results)[town-hall-7-survey-results.md].
-
Swarm start clarity: global notifications on when swarms start
-
Swarm start clarity: some work done in draft/prep mode, line blurry
Comment: If in-progress event was tied to compensation being unlocked this would be very clear -- Oskar
- Swarm end clarity: success criteria validation? exit criteria still not clear
Comment: Hopefully this will become more clear as more and more swarms finish. -- Oskar
- Swarm well-defined clarity: can be stated more clearly in terms of user stories
Comment: In TEMPLATE now https://github.com/status-im/ideas/blob/master/TEMPLATE.md#user-stories - something UXR can assist with too -- Oskar
Supporting Role Communication
Copyright
Copyright and related rights waived via CC0.