Roleocracy: The Untold Importance of Autonomy & Well-Defined Roles for DAO Success

Published in

tomipioneers

12 min readOct 4, 2023

Hi, I’m peth! The idea of DAOs is what got me into Web3 and I’ve been involved in the DAO space since the infamous The DAO in 2016, before becoming a full-time DAOist in 2019 by founding MetaGame. In my 7 years of experience in the DAO space, I’ve seen many DAOs struggle to reach their full potential or die, often due to chaos and/or ideological reasons.

90% of startups fail. In DAOs, this is further compounded by innovating on the governance front instead of just building a good product, which is hard enough. This post is an attempt to give you a blueprint for starting your DAO in a way that minimizes chaos and governance headaches, while boosting worker autonomy.

Intro

When it comes to inequity in DAOs, people think token-weighted voting is the issue — and it is. But it’s far from the only issue.

You don’t succeed merely by voting, you don’t succeed by whales having an outsized say, you don’t succeed by everyone having an equal say and you certainly don’t succeed by people randomly and frequently dropping in and out.

You succeed by having reliable people playing the right roles consistently
You succeed by not being a decentralization maxi (or an anything maxi!)

MMO-RPG players have learned the lesson a long time ago: You can’t just have people jump between roles. It’s important to have the basic roles, covered in a reliable way by people who specialize in those particular roles.

In this post, we’ll be talking about the importance of clearly defined roles in DAOs, with their clearly defined powers and responsibilities.

In this post I will cover:

A bit of history and current state
Why roles are important
Mission and village
Other basic roles
How to and tools

History and current state

People dividing work by roles to achieve group coordination is nothing new. It’s a game people and organizations have been playing for years and years, even centuries and millennia.

For as long as there were human societies, there were categories of tasks needed for well-functioning societies, and there were people who specialized in particular roles. Not everyone was equally good at shoe-making, hunting and weapons crafting.

Did we really think we could do away with competence hierarchies?
Did we really believe that it’s best to give the decision power to those with the most money or conversely to simply distribute it equally among all people and be done with it?

As it currently stands, DAOs are a haven for people with commitment issues and armchair governors. But to build a functional organization, you need a clear definition of who’s responsible for what, and people with responsibilities need autonomy.

DAO purists seem to think that any form of hierarchy or centralization of power is bad. They believe DAOs should maximize decentralization and that roles such as project management, CTO or CEO are completely unnecessary. It sounds good, but does it work?

Where decentralization maxis go wrong

Here’s why idealized concepts of zero hierarchy couldn’t be further from true:

Context — not everyone has the same level of understanding of the organization
Skills — we may be equally human but not all of our skills are equally developed
Onboarding — it helps newcomers immensely to know which kind of roles are most necessary as well as what their powers, requirements and responsibilities are
Everybody, Somebody, Anybody and Nobody — a tale as old as time. Being aware of problems doesn’t make them go away; having somebody dedicated does
Tyranny of Structurelessness — whether you want it or not, some kind of power structure will emerge over time; it’s better to have it explicit and transparent
Decision Time — knowing whose role it is to solve a specific problem cuts down on time wasted and cognitive strain of the whole organization, makes shipping faster

All of these points add up to say “being fully democratic doesn’t mean being fully functional” as well as “having big bags doesn’t mean you know what’s best”. Meritocracy is not the same as hierarchy. It just means getting the right person for the job.

At MetaGame, we experienced all of these pains ourselves. We started a DAO that was fully democratic from day 1, with 1 person 1 vote and without clearly defined roles. Over the years, this has led to a lot of time wasted in endless discussions taking into consideration every meaningless detail.

Group deliberation on minutiae detail that somebody could have autonomously worked through in a few minutes. In turn, people who are supposed to be doing it, feeling demotivated by the bureaucracy and having to wait for next week’s meeting to discuss.

Newcomers trying to help without a clear “how”, ending up just joining discussions and giving suggestions. Meanwhile, boring important tasks and problems go unattended because it’s nobody’s duty to do it and “anybody could do it”.

Finally, those trying to wade through all this chaos, always looking up to me to answer any question and solve any problem, while others look at me as a dictator for pointing people at problems and solving problems without asking for feedback on everything.

Believe me, it’s no fun.

How

Now that we know why it’s necessary to have clearly defined roles and a decision making system that’s based on expertise rather than the whims of armchair governors, let’s get into the how…

The Village and The Mission

I’d say the first distinction to make is between the mission and the village. There’s a great post explaining why this is important, but the tl;dr is that tension will inevitably arise.

Village wants to vibe, chill and take care of each other, while the mission wants to get somewhere, reach its goal and fulfill its destiny. You can see how they clash:

Village wants to build a safe space, and mission wants to challenge people
Village is concerned with feelings, and mission is concerned with tangible outcomes

My suggestion is to separate the two in some way. It sounds counter-intuitive and “oh no, the divides!”, but IMHO it’s the only way to maximize both.

Have the community side vibe and have the mission side kick ass. Have the cake and eat it too. Don’t eat the community tho: you’re nothing without your community!

So, you create some kind of separation between “the community” and “the core team”.

Note that this shouldn’t be an “us vs them” thing. Both are crucial aspects and it’s important the community stays cohesive, with people self-selecting for the most part, based on their wanted degree of involvement.

The main thing you want to do is have 2 dedicated spaces and meetings. One that’s more curated and focused for the mission/action oriented people and another one that’s open for the whole community, to vibe, share and discuss things.

If you want to keep it fully transparent, you can instead keep the calls open but give only mission-oriented people the permission to speak (you can do this on Discord).

Reasons to separate doers from vibers:

Keep the discussion mission-oriented and succinct
Keep the mission-oriented people motivated
Keep high pace without demotivating the community
Community moving slowly without demotivating builders
Prevent the clashes of highly conscientious people and vibes people from occurring

Some more important and bigger picture things should be discussed at both meetings, but not everything needs to be discussed by the whole community, and not everyone has to share their 2 cents on everything — especially not the operational day to day work.

There’s a whole other guide for people who still struggle with keeping their team meetings productive and on-topic — you might’ve heard of Holacracy.

Tl;dr, everybody can be a part of the community but not everybody can be a part of the core team. Here’s how you can make the separation:

Minimum contribution requirements — you don’t want talkers in the core team as they drag out and derail the meetings, create roadblocks and demotivate builders
Check for objections — before adding somebody to the core team, you should absolutely check if the core team has any objections to this person joining
Consistency and reliability requirements — core team members should be held accountable on doing things they said they would and stay active, rather than turn into talkers upon entry or a few weeks down the road

Note: the community has its own missions, it just moves slower

Some roles

Other than these two basic orientations towards the work versus the vibe, here are a few important roles.

Vision Beacon

The DAO-equivalent of a CEO, whose role is to formulate the long term vision and roadmap. You can’t have the whole DAO vote on a new direction every 2 months.

Usually held by the founder at least for the first phase, the task of the Vision Beacon is to clearly define the long term goal of the project.

Their responsibility is to hold periodic meetings, reflect, discuss and then formulate the short term roadmap and roles by taking into account the feedback of the community.

Tech Beacon

The DAO-equivalent of a CTO, whose role is to inform the roadmapping session with what’s realistic, keeping ambitious visions viable.

Their responsibility is to help finalize the roadmap and come up with the plan for implementing the technical side of the roadmap.

Their superpower is refusing contributions from members whose contributions aren’t meeting the quality standard required.

Project/Product Manager

In new teams, this role will be carried out by the Tech Beacon. In bigger organizations, all three of these are distinct roles.

On the product management side, the main responsibility is to do user research and surveys to figure out what’s working and what isn’t. Working with the TB to come up with the product strategy and roadmap.

On the project-management side, the tasks include running meetings, delegating tasks based on the short term roadmap and following up to make sure tasks are getting completed.

Their superpower is making decisions on what to prioritize, based on user feedback.

Community Manager/Innkeeper

The community manager serves as the heart of the community and the liaison between “the village” and “the mission” — representing the community inside the core team.

Their responsibility is making sure the community is happy, onboarding new members, keeping track of the churn rate, collaborating with product managers and coming up with the rules of engagement as well as activities for the community.

Their superpower is to ban or in other ways sanction misbehaving community members.

Rewardster

This role is all about making sure the core team and the active community members are rewarded in one way or another. This may mean using one compensation or contribution tracking system or another, rewarding people in tokens and/or NFTs.

Established organizations usually have funds to pay people. In the case of new DAOs, you might want to start with just NFTs or paying people in illiquid tokens that basically represent reputation, and a metric for rewarding people once funds are available.

Role Auditor

This one is about making sure role descriptions, responsibilities and powers are well written, but more importantly — that the people taking on roles are actually staying true to doing the things they said they would. One of the difficulties in DAOs has been accountability. Funds are automatically distributed through smart contracts — but smart contracts aren’t smart enough to know whether work was carried out and whether it was done well.

They should do this in collaboration with the community.

Champion Roles

We recommend all of the above roles have a “champion” (somebody in charge of the role) and a “deputy” (someone to hop in when the champion is unable, to assist the champion in general, and keep them accountable).

Most if not all of the above-mentioned roles can grow into whole teams over time.

When that happens, another circle forms around the core team.

Stewards

As DAOs grow, it becomes more important to have stewards — these are generally publicly-known figures that are highly knowledgeable and spend hours to stay up to date on what’s going on with the project as well as the ecosystem, and guide the decisions.

In some DAOs, they are also called delegates and are assigned formal power by the community — token holders assign their voting power to delegates because they know they have the context and knowledge to make informed decisions on their behalf.

Bounty Hunters

Last but not least — bounty hunters. While some DAOs mistakenly think the whole DAO can work through bounties and other DAOs avoid bounty hunters altogether — having bounties and engaging bounty hunters can be extremely beneficial for the project.

They can be drawn from the community or third party platforms like Dework. Putting out bounties is also a great recruitment tactic, with people proving themselves through work rather than interviews and slowly growing into the role over time.

The main issue with bounty hunters is that they can sometimes be as flaky as the community members who say “I will do that” before disappearing completely. This is avoided by paying them well and a list of reliable bounty hunters — and not assigning them super important, time-sensitive tasks until they’ve proven themselves.

Checks and balances

After instituting roles, the most important things are to keep them up to date, split them into multiple if they’re too heavy and keep the role holders accountable.

For starters, I recommend role descriptions and commitments to be seasonally refreshed, so the people keeping the role are made to re-pledge and there’s a period where other community members may apply for the same role.

It is up to you to decide who’s the ultimate authority on who gets “hired” and who gets to keep their role. I suggest this is done by the core team, as the core team knows best and has the most context into their needs and dynamics — vs. the community decision, which may turn into a popularity contest.

IMO, the role of the community is to guide the decisions of the team, not direct them.

If the community thinks somebody is not fulfilling their duties or abusing their powers, they should be able to start a motion against the member — leaving it for the team to decide.

Alternatively, you can take community votes on all matters related to top roles.

Tools

There are two main tools for tracking and managing roles inside DAOs — Sobol and Hats Protocol. Though it has fewer features due to being a much newer product, we recommend Hats Protocol.

The reason we prefer Hats Protocol is because it’s built as a protocol in addition to web app, meaning you should be able to easily integrate it into your workflow and have it manage actual permissions (like granting multisig signing rights or assigning Discord roles), rather than simply describing and mapping roles.

But ultimately, these two tools serve different purposes. Sobol has recently integrated Hats Protocol, and you should certainly check out both tools to see which one better serves your needs.

Caveat

Of course there are things that fall between the roles, where it’s not clear whose responsibility it should be to solve a particular problem.

The main capacity you need in the DAO is to have a way to identify problems rapidly as they arise. As soon as there’s an issue, it should be categorized and tacked on under a role’s responsibilities (in agreement with the role keeper).

The roles described above are bare bones — you should expand on each of them and adjust them according to your organization’s needs.

Conclusion

No matter how you set out to design your organization, roles will emerge.

This post is an attempt to motivate you to spend some time writing out the roles needed for your DAO.

When doing so, these are the questions to answer:

What is the role about?
What are the responsibilities?
What are the superpowers?
How do you measure or validate success?

Other than that, you’ll also need to figure out:

How do people get these roles?
When and how do people lose roles?
Do some of the roles rotate?
How do people raise concerns about role keepers?
Is there an escalation system and who has the ultimate power to make decisions?

I believe DAOs are the future of human coordination. I’m on a mission to educate the world about DAOs, talk to many DAO operators, and produce a lot more playbooks for building functional DAOs and helping the DAO ecosystem proliferate.

That is also why I’m joining tomiDAO — to help it get through these initial design concerns and connect it to other experts in the field. Together, we hope to launch one of the most well-aligned DAOs while sharing learnings to help the wider DAO ecosystem.

Thank you to Grace Rachmany, DAOwl, Dag, David Ehrlichman and Sparkle for giving great feedback, editing and overall making this post 3x better than it otherwise would have been.

Follow us for the latest information: