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

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:

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:

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:

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:

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:

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:

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:

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].

Supporting Role Communication

Copyright and related rights waived via CC0.