MMM is always on the lookout for better, more efficient, and more fun ways of getting work done. We have recently implemented a series of measures to make decision making more clear and streamlined within the Workstream. The goal of this post is to share a few learnings from this experience with other DAO leaders within Gitcoin and the broader community.
The Problem We’re Solving
Until now, there have been no formal structures for decision making. In turn, the Workstream often experienced preventable issues at two ends of a spectrum:
- an individual making decisions on behalf of the Workstream with unintended consequences (ex: misinformed decisions, high-risk decisions, poor morale, etc.)
- slow, clunky, consensus-based decision-making with multiple syncs needed to move forward
In an effort to make decisions more quickly without compromising on the quality of those decisions, MMM has turned to implementing best practices from Holacracy and Sociocracy.
The result is a system with processes and a few key pieces of technology that allow us to move full speed ahead with clear governance models.
Since our kick-off meeting in mid-May, we’ve adopted more than a dozen pieces of governance describing norms, roles, processes and policies at our Workstream.
How it Works
It starts with a tension arising in the Workstream. Confusion, a lack of clarity, a frustration, or even a curiosity are signs that something has not been properly documented and decided upon. This is the first sign that there is a missing piece of governance.
Passing pieces of governance DAO-wide uses a tech stack that may look like:
- Google Doc - used to collaborate between contributors/within a Workstream
- Gov Forum - posted to gauge sentiment of the DAO and its Stewards
- Snapshot - sent to a vote
- Tally - codified on-chain
At MMM, we adopted our own, similar tech stack process.
Phase 1 - Proposal Creation
In the creation phase, one or more contributors will develop an initial proposal for review by the rest of the Workstream. They will use tech based on the size of their proposal:
- Large ideas/proposals (ex: compensation model) - Google doc
- Smaller ideas/proposals (ex: new role) - Discord post
Both avenues are meant to 1) create space for collaboration and 2) get a pulse check if the idea is palatable.
Phase 2 - Proposal Consent
MMM has adopted consent-based decision making as its primary form of decision making. We use Murmur - an async governance tool - to ask/answer questions, make suggestions/edits, and decide/object to proposals using the Murmur method.
Despite the tool being in beta mode, our experience has been mostly on the positive side (but not without its barriers). Below is a list of pros and cons for other Workstreams to consider whether they should adopt this tool or not:
| Pros | Cons |
|---|---|
| The entire tech is intuitive and easy to use | No room for collaboration in-app |
| Lots of great templates to start from | Async means that passing proposals takes longer (more time is needed to allow people to read and comment on each proposal) |
| Great labels and categories for easy sorting | No search functionality (coming soon) |
| Expiry dates for agreements (huge advantage of Notion) | Murmur is unfamiliar and has a learning curve |
| Allows for more async work | Murmur leaves little room for back-and-forth discussion |
| Murmur tech biases toward action - makes us move through rounds within a set time period | Murmur questions/answers cannot be referred to in later rounds |
| Murmur has a fast-track tool makes it easy to make amendments |
A few additional notes:
1) MMM still biases toward a Google Doc for the initial development and sharing of ideas (especially large, potentially contentious ones).
2) At this point in time, only MMM Stewards and Seed (aka Trusted) Contributors can participate in governance at MMM.
Phase 3 - Proposal Codification
Once a piece of governance has been passed through Murmur, the article is placed in the MMM Knowledgebase. This is what we call our Notion page, and it operates as the single source of truth for the Workstream.
Only those with permissions (and Gitcoin emails) can change content on Notion, meaning we aim to keep our use and updating of Notion minimal. Our hope is to create relatively static pages that are only updated to capture new decisions made (rather than use it for dynamic documents). The only exception to this will be meeting notes and tracking projects.
Each season, several roles in the Workstream are responsible for ensuring that specific pages are updated.
Next Steps
As we prepare for S15, we will continue to experiment (and iterate) with these tools and processes.
Some questions that have already surfaced include:
- Which steps (if any) in this process can be bypassed?
- What is the right amount of time to allow people to comment, ask questions and make suggestions to a proposal?
- Is a tech stack like Murmur working better for us? Or should we move to live, synchronized governance meetings using a sociocratic meeting model?
- Is the Murmur method our best option or is it better to allow back and forth discussion in a Google doc?
- How do we encourage more participation from Contributors at the edges of the Workstream (without creating too much noise for sound governance to be passed)?
If anyone has any comments or questions, or would like to know more about how to implement a similar process in their Workstream (or DAO), don’t hesitate to reach out.