The DAO primitives facilitation framework is a work in progress. It is designed to provide a structure for designing organisational forms based on the DAO primitives that can be implemented using reliable organisational patterns from the Pattern Library.
The framework will help an external facilitator or a team themselves to work through a set of questions that will reveal the design of the core organisational structure (what the team, organisation is designed to be and do) and the basic agreements that will govern its members and relationships.
From design and set of agreements we can choose from the pattern library the different social processes and technical tool-sets that the organisational structure (team, DAO etc) will use to implement the above design and agreements.
Using Knowledge Resources
Playbooks
Intro coming soon…
Link to original
Patterns
patterns#^152f26
Patterns typically contain the following:
Key Concepts
Group Scale
Group Scale
Group Scale is a group property referring to the relative size of an group’s active membership, and is an important factor in the selection of primitives.
Human groups function in fundamentally different ways at different scales. When we design systems for groups to work together. The scale at which this happens is critical to how a particular group pattern will function.
Any frameworks we draw from to design human systems needs to account for scale to have any chance of success.
We use the above group scale model to inform how we combine the different primitives. It is based on modern organisational/anthropological models but very simplified to be easy to apply. It maps 3 basic group scales:
NOTE
It is important to note the size listed for the different scales is an upper limit but not a lower limit. For example, trying to collaborate at numbers greater than 10 is generally impossible, however it is possible for a small team of less than 10 people to operate in coordination or constituency scale governance structures.
Link to original
.png)
Group Phase
Group Phase
Different groups go through specific phases in their development. The more these phases can be understood, mapped and then tools and practices can be provided to facilitate each phase, the more coherent, useful and efficient the function of a group can be and the more effectively it can coordinate with other groups.
For applying the DAO primitives we consider groups to have 5 distinct phases:
- ideation - no constraints.
- Formation - early engagement with minimal process.
- Organisation - formal structure/state.
- Coordination - integration into operating networks.
- Completion - graceful closing down when no longer needed.
In the context of team development, group phase tends to parallel some stages of the 5 stages of development.
Link to original
Group State
Group State
Group State makes decentralisedorganization possible, because entities and groups can be autonomous/self governing, while also being deeply integrated into larger networks and partnerships via agreements held in their state.
Group State makes decentralised organisation possible, because entities and groups can be autonomous/self governing, while also being deeply integrated into larger networks and partnerships via agreements held in their state.
Group state is also fractal, with Roles and Tasks also having state, which rolls up into Cell states, and Cell states rolls up into DAO state. In this way, the entire network can be understood simply by looking at the the different group states that it is made up of.
Background
The concept of group state is borrowed from computer science. We use “state” to describe the current configuration of an entity at any point in time.
Entities having a clearly defined and interpretable state is fundamental for decentralised coordination to occur. It allows an entity or group to have a coherent accurate view/description of itself that others in the network can engage with.
An entity’s state is a secure, (ideally version-controlled) up-to-date description of the intentions, agreements and activities of an entity that provides a mechanism for others to coordinate with it - e.g discover it, trust it, partner with it, share resources with it etc
An entity or group must maintain its own state. This allows the structure of the system to emerge as a network of small autonomous teams, rather than relying on state to be maintained (and dictated) by a centralising structure in the organisation.
From a technical perspective, state will consist of a basket of attestations that make explicit the commitments and agreements that are foundational to a Role, Task or entity.
For example, a task or role contains the agreements about the nature of the task and agreement by the person or entity who is being assigned/accepting the task or role. For a Cell, the state contains the shared agreements held by the core team and also commitments that the team makes to entities outside the Cell. And for a DAO the state is defined by the community agreeing on how the DAO is to operate.
Elements of Group State
A simple articulation of this state could be covered by the following categories:
- Purpose: what is the goal of the entity, role or task? - What is it trying to achieve and how does this relate to the other entities in the network and the network’s overarching purpose?
- Practices: How will it achieve its goals? - Who is in it and what roles to they have? How does it make decisions? How is money and other rewards/compensation managed? How is the work of the entity managed?
- Progress: What progress has been made? - where are plans, timelines etc and progress through these recorded? Where can outputs, documents, artefacts etc be viewed?
Expressions of Group State
- OpenCivics has created a similar approach to project legibility in their OpenCivics Collaborative Initiative – Specification Template
Link to original
Modeling Group State
Foundational Agreements
Based on the properties discovered during evaluation, determine what types of basic agreements your group will need right now.
Working Agreements
As a starting point for the facilitation process we can use a process like The Ready’s OS canvas. This provides a simple starting set of questions to outline the desired set organisational relationships and functions. From here the appropriate patterns from the pattern library can be chosen to implement these.
