Distributing Rewards in Decentralised Communities

Originally published here.

In the most basic form, I see a decentralised community as a group of freelancers that join forces to work on a common goal. We are no different. We have a process with which you can join us as a contributor and participate in all the things we do.

Being a contributor however doesn’t mean you get an employment contract and a fixed monthly salary. It’s really more like being a freelancer. Freelancers are paid based on effort and have no real certainty in their earning, whereas employees typically do know what they’ll earn next month.

But of course it’s not black and white, it’s a spectrum.

An employee will get something like 70% fixed based on hours and 30% dynamic pay based on value add. Obviously if the employee does not add sufficient value to earn even the fixed share, then the employer would probably fire them.

Freelancers or gig-workers (bounty based) on the other hand are mainly paid based on value add. The level of value add is typically measured by a client and places freelancers on the dynamic side of the spectrum. Dynamic because after each gig a new one has to be found and agreed upon.

If a decentralised community is a group of freelancers, then they fit into the dynamic pay side as well. Working here does bring less security, but ideally also a potential higher reward.

When it comes to payout, the individual freelancer is straight forward; scope up a project, deliver, get paid.

The payout-problem starts when there are multiple freelancers adding value. How do you divide the pay to those that added value?

Why not just pay salaries?

Couldn’t we just count hours contributed and pay based on that?

For similar reasons that an employer will want to maximise the dynamic part of an employee’s pay: Hours spent don’t always correlate with value added.

A bounty based reward system might be an alternative. It, however, turns members into agents — they only work on what is available as reward and have little accountability. We hope that with dynamic pay, based on the joint outcome, we can turn more of our members into principals that take ownership.

By not paying salaries, we hope to unleash our contributors’ freelancer mindset and increase their accountability towards meaningful outcomes. Ideally everyone keeps in mind that what they are doing somehow should be adding value to the community.

Revenue sharing is caring

Ideally, we’d like to share the revenue that we make among contributors in a way that everyone feels paid well for what they’ve done. The problem here is that not everyone contributes the same amount of time. Some are full time, others work only part time. If we would just equally split, those full timers wouldn’t be happy, if we’d only onboard full timers, then we’d limit our community.

If not salaries, how do we distribute our revenue among our contributors?

More specifically, we want to:

1. Be flexible i.e. pay whoever contributed value
2. Deal with the uncertainty of revenue i.e. we don’t know what we will earn next month
3. Incentivise both part time and full timers to add value
4. Make it easy e.g. members should be able to do this without keeping track of what all their peers have done
5. Avoid friction and keep the group of freelancers working as a team
6. Avoid bureaucracy and spending too much time on voting
7. Add a market based system that allows contributors to decide what is most valuable and by that guide future contributions

The tricky bit all boils down to measuring value and finding consensus among members on how they want to split the reward.

Measuring value creation

Measuring value creation is a very subjective topic as every individual will want the largest part of the pie and will likely overestimate their own contribution vs. the contribution of others.

Performance indicators are a good way to start e.g. using the number of likes or reads to measure the success of content. As lagging indicators, however, it might take some time to be able to measure properly and thus to pay out the rewards.

Other activities such as managing the community, making sure content is published on time, and running the actual payroll, no doubt add a lot of value, but are a lot harder to measure with indicators.

The ideal outcome is reaching a consensus so that everyone feels well paid for the work they’ve done, while not getting into bean counting.

A difficult challenge and we are certainly not the first to try this, but it seems to be an important building block of communities.

What we’ve tried

Coordinape is probably one of the most popular tools for decentralised reward distribution, but it is very focused on the individual and not the actual value add. Yes, value add can be shown in a user’s profile when voting, but it’s not the main focus of the tool. We felt that with a focus on people it becomes more of a popularity contest rather than a value add contest.

Coordinape also offers discord tipping, which is great for on the spot rewards, but does not trigger a deliberate thinking and reflecting on value creation.

We initially tried out Dework, which is a great kanban/project management/bounty board tool for crypto communities. It’s super sophisticated but has its focus on bounties.

Bounties are similar to salaries except for that bounties are more granular and flexible. You know upfront what you’ll get, but there is no point in overachieving as they typically don’t have a dynamic pay part.

Dework has created a feature for retroactive bounties and we tested it for a couple of months, but found using Dework just for retroactive bounties a bit overkill.

Our current approach

Most important to us is a quick, frictionless process.

We thus started with a spreadsheet and split our dao into teams (publishing, consulting etc.). This ideally helps keep the circle of people you are voting for as small as possible.

We then try to vote in two phases:

1. Decide the teams total value-add to the dao.
2. Decide the individual’s value-add to a team.

A two-phased process makes it easier for us to keep track of value add and not get too confused by a large organisation.

Our overall process roughly looks like this:

1. Each team jointly creates a short pitch of what value they have added in the month.
2. All contributors then vote on the value add of the team. The goal is to know that e.g. publishing contributed 40%, community 30% and education 30%. Voting is done by proposal and veto, meaning that anyone can make a proposal that gives a 2 day veto period. If no veto/ new proposal is submitted during that period, the team distribution is set.
3. Next, individual team members submit their contribution to each team and vote on who added how much value to the team. For example, the education team might have two contributors, member A and member B and by voting we determine who added how much value. This allows us to break the reward down to member level.
4. We close the reward round and run our payroll.

Content creation is part of our flywheel, that’s why we reward content creators separately from team contributors.

Our content reward round goes as follows:

1. Beginning of the month, we’ll import all content that was published in this month from our content calendar on Notion.
2. We set a budget based on the month’s revenue.
3. Per content piece, every contributor gets 10 points to vote. E.g. 15 articles, threads, podcasts etc. will give everyone 150 points.
4. We open up voting for 5 days and everyone decides which piece deserves the largest part of the budget — authors can’t vote for their own content.
5. We close the round and know which author gets paid how much.

Ideally this doesn’t take a lot of time and effort but allows us to reflect and ensure everyone is paid for what they do.

Reaching the limits of a spreadsheet, we built ourselves a little tool, that covers all of the above:

Issues we are still facing

While we are quite happy with how this process works, we have a few issues.

1. Voting vs. consensus. Reaching an agreement can take more time but will ensure that, for the most part, everybody is happy with the outcome.
2. Think of the spectrum of fixed and dynamic pay from above, we want to avoid counting beans — i.e. spending a ton of time on tracking who did what exactly.
3. A voting process (take our content reward round for example, in which one can’t vote for their own content) can favour those who don’t vote as they receive but don’t give points. For now we’re thinking of excluding those who don’t vote from the rewards. I.e, if you don’t vote, you don’t get paid, incentivising participation
4. From the process described one can see that this is a lot of work to run. We absolutely want to keep effort and time spent as low as possible.
5. We currently only look at the value creation within a month and tie that to the revenue made in that month. A major downside is that we have no long term view on things. Yes, it does keep people on their toes, but it does disincentive working on long term projects.
6. Do we need to bring in some fixed pay? Not everyone will want to take the risk of taking dynamic pay.

Summary

Figuring this out is core to the future of work that these communities enable. The new way we assemble in groups to work on stuff that interests us and creates value while making money to pay the bills is very exciting. I personally find this a lot more interesting than working in a corporation and would love to see how tools and processes evolve to cater for this new way of working together.

As our issues show, paying a group of freelancers is not an easy problem to solve, but we want to explore if there is a better way than simply paying salaries.

The main issue I’ve seen from many other DAOs and communities is that the decentralised nature gets them swamped in bureaucracy and slows down the process of getting shit done.

This is our biggest concern too, but we’ll try and experiment with different approaches.

If we get it right, there awaits higher accountability of contributors and a culture that focuses on driving value rather than spending time.