DAO Ops proposal

[kempsterrrr]

@Erik_Knobl

@kempsterrrr

A large part of the DAO Governance Structure Upgrade was to simplify and clarify structures and roles.

This is an effort to elaborate in that effort.

@kempsterrrr

Have you thought about the complexity this new terminology is adding back into the DAO? If so, what are your reasonings for adding more role terminology back into the mix vs not?

We can use “revenue-generating contributors” and “non-revenue-generating contributors”. I just think it’s shorter.

OK. This feels like it adds complexity that we’ve just removed from our processes and makes Governance bigger again which feels like a mistake.

@Erik_Knobl

@kempsterrrr

How are these Operator roles selected?

That task has been delegated to coordinators of each area.

Who chooses the Coordinators?

@Erik_Knobl

@kempsterrrr

Love the idea of setting the threshold and putting that decision to the Stewards. Is this on top of the 5% for non-revenue generating roles, and is that per Sub-DAO?

Yes, on top of that. And for each sub-DAO. Right now there is no clarity if other sub-DAOs can request USD, why, and how much. We need that.

Totally. That power was given to Stewards in DAO Governance Structure Upgrade, see below. Does this replace that or just doing that work for now?

@kempsterrrr

Define DAO-level Treasury Strategy (any DAO Operational / Foundation costs, Treasury assets available for budget requests).

@Erik_Knobl

@kempsterrrr

Thoughts behind this $1 rate for $CODE? Do you see it being expanded across the DAO for other activities?

I just think it’s simpler because the real reward is USD. If required, I can add the hourly calculations.

tbh I like it as an experiment. Quick and easy.

I wonder if there is a reduce scale for paid roles though i.e. if you’re paid by the DAO your $CODE rewards are 50% of what they otherwise would be based on OKRs?

@Erik_Knobl

@kempsterrrr

Why are most roles documented with what seems like hours and the coordinator’s roles on %? If we update the revised figures I’ve shared above, that will leave the ops work at $2,200, which is not sustainable for the level of work. This means ops would coordinating AR/AP/Contracts/Payments etc. for less money than the folks they are coordinating doing work that takes less time

There are two steps in this process. First we have to know which roles we are rewarding, and how much each area needs. These initial numbers are an effort to have consensus, and learn how much Community, Operations, and Partnerships need?
Then, we balance and negotiate those numbers. If we start saying currently a role will be paid with $100 monthly from a 50,000 seasonal budget, we know it’s 0.2 of the total budget. If the available budget is reduced, we adapt that reward to that percent, just like coordinators.
If we have more money, all payments remain the same. If we have less money available, all payments will be reduced.

Open to discuss ways to improve the payment/percent, in a way that creates a system for all. It’s still a work in progress. Currently, Operations is ranked in the same level as other coordinations (community and devrel), and compensated as such. My initial suggestion for you would be to have a basic role, and also take on other (defined) tasks, which all together will be a sustainable payment. But if you feel we should create a unique role, with a single payment superior than the rest of the roles, we can discuss it too.

I think the way this is defined is the problem, it is creating far more work for Ops, not less. Handling payments/contracts etc., across all of these different people isn’t a small task. It’s far bigger than Season 1. With current definition, Ops needs to handle contracts and payments for 65 Contirbutors a Season. To put that into perspective that’s:

• Up to 65 Contributor agreements (probably not all at the same time as its fluid); info gathered, questions answered, contracts sent, chased, signed etc.
• Up to 65 invoices per month; chasing people, checking everything carefully etc.
• Making sure we make up to 65 on-chain payments correctly every month

That is ~ > 10x last season and doesn’t include Accounts receivable invoices, contracts for partners etc.

I’m not sure what the right solution would be under this potential model, I will have to think about a suggestion (any advice on what might be useful info), but that is not sustainable.

[kempsterrrr]

There was a lot of discussion on the @stewards call today regarding the need for a framework for calculating rewards.

Copying from Labs proposal channel in discord

Typically, companies do this in the following ways:

• pick a location that is their base line
• get salaries for roles in that area
• target a percentile (i.e. 90th, 80th, 70th) etc.
• pay that globally, or, use a cost of living multiplier based on location (i.e. more in more expensive places, less in less expensive places)

Please see this spreadsheet for some data-backed suggestions, copied in below.

Role	Base Salary (Year)	Bonus (yearly)	Base Salary (month)	Bonus (Monthly)	As %	Source
Community Manager	$ 66,356.00	$ 2,258.00	$ 5,529.67	$ 188.17	3.40%	https://www.comparably.com/salaries/salaries-for-community-manager
Partnershis Lead	$ 69,915.00	$ 39,419.00	$ 5,826.25	$ 3,284.92	56.38%	https://www.comparably.com/salaries/salaries-for-sales-rep
Operations Lead	$ 84,409.00	$ 8,133.00	$ 7,034.08	$ 677.75	9.64%	https://www.comparably.com/salaries/salaries-for-operations-manager
Recruiter	$ 84,409.00	$ 8,812.00	$ 7,034.08	$ 734.33	10.44%	https://www.comparably.com/salaries/salaries-for-recruiter
Fundraising	$ 68,761.00	$ -	$ 5,730.08	$ -	0.00%	https://www.comparably.com/salaries/salaries-for-fundraising-coordinator
	$ 373,850.00	$ 58,622.00	$ 31,154.17	$ 4,885.17

This falls apart a bit if we’re seeking to bounty many things out, as the data for this doesn’t exist. If we’re doing that, it seems sensible to decide on a flat hourly rate for those tasks. I don’t think we should be doing this for operational (so community, ops etc.) work, though, as these things need accountability and don’t have a variable to motivate that accountability. Bounties IMHO should be reserved for things with limited accountability/impact on the community/cost of goods sold.

We’re working in current structures from Season 1 for roles, whereas we’ve evolved most of the other structures and I wonder if maybe we should consider doing the same for roles. Just and example of here of the Job Description for a Community Manager @ ENS.

[ntindle]

This makes a lot more sense to me but this money has to come from somewhere.

[kempsterrrr]

Indeed. However the monthly total here is roughly aligned with what is being suggested in in-flight proposals. Be very easy to reduce these rates by a % of available funds/revenue generated each month (this would incentivise everyone involved to drive value)

The other major problem I see is how tasks are being allocated as things fall through the cracks (i.e. DAO Marketing/social etc.) without defined roles. See ENS community role JD that looks after their socials.

[ntindle]

Fair. The ability to hold people accountable for things as well as having them dedicated to these roles is really desirable. How long could we sustain funding at this level right now?

[kempsterrrr]

If we ignore everything else and just look at revenue from partnership this season that is currently at $20,000/month (and we’re expecting another cc @Colin4ward ) bringing it to $30,000 - so we’re basically break even (assuming we make no more money from josb/events) AND have ~ 80k left over from last season

Caveat I’m remembering these numbers on the file and will need to check. Very late here

Ignore this, we’re missing some figures. See message below

[kempsterrrr]

WOAH… sorry, we’re missing a delivering/devrel/newsletter work here. Got ahead of myself and tired, I’ll add these in tomorrow. Although again, if you look at the ENS community JD, some of this comes from that role and imagine some might come from Partnership here (given how the roles are defined)

Regardless, I think the approach has a lot of merits and will explore more tomorrow.

[kempsterrrr]

Dropping one more piece of food for thought on this model before bed. FWB offers a sliding scale of USD rewards or tokens. Not sure exactly how this works there but I wonder if (assuming legally fine) we can explore something similar (at least for Labs/Ops)

It would work something like this:

For every $1 USD a Contributor reduces their pay, they are paid 10 $CODE.

So for a worked example, let’s say someone is paid $10,000/month and 0 $CODE. That person decides to actually take only $8,000 in USD and then 20,000 $CODE (2k * 10 CODE).

This further rewards folks in elevated Governance for believing in the community by being happy to take less USD in return for $CODE.

[ntindle]

I agree with this in general and should absolutely be explored.

[allWiseee]

This may have already been touched on, but I don’t think a dao wide bounty is great due to lack of accountability on ops and community side.

I think back to when I started actualizing onboarding 1st quarter of last year, I spearhead the initiative, and galvanized others to help me. That happened naturally. Someone with full accountability (me), and a team that wanted to add value but not be accountable for the entire project.

Maybe those project leads can create bounties for their specific needs instead of the stewards, which I’m sure you’re not opposed to.

[kempsterrrr]

Given the situation, this is hard to say, but if the calculations in this proposal remain the same, I cannot perform my role in S2. The time required to perform these tasks (far more than S1) is not equivalent to the return or the risk associated with ensuring we remain compliant, particularly when my name is on the Foundation.

This doesn’t come close to covering living costs, and I won’t have enough time to generate significant funds from elsewhere at this rate. The minimum for me to be able to perform these roles is $5,000.

I appreciate this may not go down well and seem unfair, but it is what it is, and I can’t put myself at risk like this. I’m happy to work on reducing this bus factor in S2 and diversify my income, but I’m not prepared to perform this role at that rate.

[Erik_Knobl]

Based on the feedback collected, I have decided to withdraw this proposal from contention. The process has been a learning experience, and really hope to be able to improve some of the ideas in this initiative.