During the last months, we’ve talked with hundreds of DAO core members, project managers, and contributors about how to productively engage their community to get stuff done.
Almost without exception, DAO operators tell us that a flexible working environment with contributors is great:
Less of a need to run long recruiting processes to find value-aligned contributors
Easy to scale both up and down as DAO objectives change
Prioritize work output versus core team time input
However, as in all nascent work & technology paradigms, there are several things that make this way of working hard to implement:
It’s hard to have both bottoms-up autonomous workflows AND to get people to consistently work on useful stuff rather than what they feel like
It’s hard to know who’s the right person for the job
Dealing with onboarding & applications from outside contributors can be a mess
During the last months, we’ve been developing and refining ways to be able to actively work with contributors while minimizing the above pain points. We call it role-based workflows.
What is a role? While it certainly differs between DAOs & servers, one common interpretation is that it’s something that gives various levels of access to do things, without an obligation to do so.
Despite the often well-founded criticism of Discord, the thing they really excelled at is granular role-based access control. Whilst you can self-select to certain Discord roles in some servers, in most cases Roles are accumulated stamps of approval that you receive over time as you prove yourself to be trustworthy and competent.
If role-gating is the way DAO contributors are accumulating local reputation and access to their Discord server, why wouldn’t that be the way it’s structured in their work management tooling as well?
Enter - Dework Role Gating
In Dework it’s possible to granularly define which roles that grant you certain work access. Work is broken down into Projects and Tasks. You can very granularly control who should get access to what work by using Roles.
A key to using Roles is to make them granular and ranked.
Granular: A role should be precise enough to accurately describe the specific skill in question. ‘Product’ for instance would be too broad - it is better to have ‘design’, ‘product manager’ or ‘frontend dev’.
Ranked: When working with contributors, the concept of gradual reputation building is key. If you’re not precise about how much you can trust a contributor, you’ll end up getting burned by giving too much responsibility too soon. The DAOs that succeed tend to be very clear about the roles - eg Dev L2, Community L3, SmartContracts L1, and so on.
Having this setup allows us and many DAOs on Dework to easily create tasks, bounties & projects, gate them to the appropriate level, and allow contributors with those levels to easily and autonomously claim those workflows and start working on them, without an intermediary.
Usually, the recommended approach is to set it up so that if you have a role, you’ll be able to claim directly. But if you don’t have the role - you can still apply:
For someone that doesn't have either the
Core Team or
Dev L3 roles, this is what the bounty looks like:
Whereas if you do have the role, you’re not shown the “I’m interested” button for applications, instead you can just claim it:
Now, how can you progressively step up your ranks? The answer isn’t straightforward, because usually, the process through which you acquire a role and what it actually entails is far from transparent. At least until recently! Using Dework Role Center you can easily get an overview of which roles are available in a DAO, what they entail, and how to get one:
Through the role center, contributors get a clear picture of the role, and you can allow eg applications to the role through a Typeform.
Soon to come: the ability to set quantitative rules for how contributors can acquire/unlock roles - eg the Dev L2 role could have a rule to be automatically handed to someone after
successfully completing 10 Dev L1 tasks. This would be done in collaboration with Guild.xyz, which will allow us to create and gate by roles based on several on and off-chain conditions, like one's level of Twitter engagement, Github activity, for how long you've been a token holder, etc.
Tying back into the problems we touched on initially, and how it changes using Role gating:
We’re not claiming that this approach will remove all headaches when it comes to working with contributors, but it’s a clear improvement on the status quo. After all, there is no ‘Lean Startup’ doctrine of best practices yet for DAOs working with contributors - hopefully, this guide can serve as a chapter in that book when it’s finally written.
We’ll be writing more about how roles ties into compensation in the future. If you’re interested make sure to follow!
The road ahead:
Globally recognizable roles (global guilds?)
Combining multiple roles