This document attempts to outline a broad set of guidelines so we can operate swarms effectively as an organization.
What we are working towards is an entirely decentralized organization, where ideas and swarms are funded by any user, stakeholder, in the system. This is a non-trivial problem in terms of incentive design. To get there we are currently using a two-pronged approach. This document focuses purely on the first point:
Additionally, a swarm that isn’t in progress should not be actively worked on. This ensures we communicate things properly before doing them and we have a critical mass of development on the active swarms.
### Swarm status updates
A public status update that answers the following questions:
This is a way of ensuring accountability and providing a clear interface to the rest of the organization. It is also helpful for people who want to participate in a swarm and want an overview of what is going on.
## Swarm Lead
Thank you for being a swarm lead! This is a new type of role which we are still defining as we go and learn things, as well as refining the whole swarm concept. Being a swarm lead is different from being a traditional team lead in at least two ways:
We will encourage and empower people to lead, but not expect or force them to.
### How do we deal with failure?
Silent failure is worst case. Capture the upside of failure, what the swarm learned (as in a retrospective).
### Does delaying dates signify failure?
Swarm evaluators are responsible for determining if a swarm is ‘dragging on’ without progress, or if delays are justified. Use health checks and frank discussion along the way on how to improve.
### What is the difference between success metric and exit criteria?
Exit Criteria example: Launch new onboarding UI flow
Success Metric example: Onboarding conversion rate. Target >30% full funnel.
If in the above example, the new onboarding flow doesn’t improve the conversion rate. The swarm should then disband, and create a new swarm to tackle the problem from a different angle.
One example of measuring success is to ensure there are Mixpanel events setup/created that will aid in measuring the impact of the swarm.
### How can I make sure there’s a regular cadence to my swarm?
It’s up to you! It's often useful to keep a public Google Doc with meeting notes that can be referred to later. As a swarm leader, it can be helpful to get someone else to act as note taker while you drive the agenda. This note taker role can also rotate among participants in the swarm.
Another idea is to record decisions more formally, a la Architecture Recording Decisions.
