Tag me for these on the outro please?
Since I’m actively recruiting this is very relevant for me.
@gabi thanks for starting up the conversation. Since you are getting a working group together. Something that comes from Maker to add to the add to the heap here.
There is a fair bit of discussion that happened regarding MKR compensation in salaries. Looks like Maker has made a choice on how they want to distribute this. The model is a RSU type model and it has a 6 month trailing average vesting price. MKR is also considered to be an addition on top of salary vs. a bonus.
Now 1Hive is in a very different position that Maker in that revenues are NOT sufficient to cover payrolls. I am pretty sure the best and fairest model here would be to offer sufficient salaries in DAI to cover what people need to live and that HNY (or MKR in the case of Maker) only be offered in a vesting contract as a bonus due to performance of revenues. The point here is two fold.
- Make sure competitive salaries are available already in cash. contractors should not have to sell tokens to make ends meet. The organization should do that selling in a consistent way. This allows the whole of community owners to take the brunt equally and contractors to get compensated
Which brings me to a key point to insert here regarding terminology. This should not be called payroll and should be called ‘contractor swarm’. 1Hive needs to stay as far away from having employees as possible from legal and tax implications. 1Hive workers are contractors, must in the US pay their own SSI, Health, fund retirement, etc. Which means salaries will need to account for all of these extra expenses and contractors will have to learn to deal with them.
-
I personally think that once salaries are sufficient and competitive that bonuses based on total community performance (i.e. via a revenue metric) in options vs. RSU type would be the best way to align contractor interests in 1Hive performing with those of holders. 1Hive is so small this may not be a good option and Maker felt RSU was simpler. The point here is that the community can set HNY bonus compensation to vest (it darn well better btw) and that how much HNY is given out should be based on improvements in revenue streams. Have real targets 10K/month, 100k/month for say the bonus allotment period before HNY bonuses are unlocked.
-
Final point is that if contractors will get salaries I think it is prudent for 1Hive to begin rasing DAI. Instead of taking revenues to buy and burn HNY it should be converting these to DAI. So 1Hive better start thinking about how CV is going to work while also managing both conversion of HNY to DAI and HNY voting as well as proposal funding. Altering funding for contractors from HNY to DAI will be a critical step for 1Hive.
I think these are probably the key things to keep in mind and I would start right now by changing the title of this from Payroll to Contractor Swarm so everyone thinking and managing this wraps their heads around what this means in terms of the increase in funding required, and where the full responsibilities for things are (most falls on the contractor) so sustainable funding can be put into place and contractor negotiations can happen. I do like the idea of Core Unit budgets which I think 1Hive already has mechanics to manage. I just think 1Hive needs to formally decouple prices/costs/funding from HNY to DAI and then put together an asset management group to deal with how to convert revenues and assets into DAI so it is least disruptive to markets. (i.e. HNY DCA into DAI)
3 Likes
Yes.
That should be handled within the swarms. Maker uses a CU model where the CU lead basically allocates to their contractor FTEs. Basically CU contractors negotiate with the CU lead, the CU lead also proposes budgets to governance generally.
Unclear and open. Maker has gone for a more centralized CU model where basically 1 person the CU lead, issues budget requests, negotiates CU FTE contractor terms etc. What 1Hive adopts could be up to each swarm but realize the more democratic this is - the more time will be required to complete key steps. For sake of efficiency I’d have swarms elect/appoint a swarm lead, and at least 1 assistant who are the interfaces between governance and swarm FTEs and budget management.
Probably not. Which is why 1Hive governance will need to step in here to construct a HNY to DAI DCA structure and fund it. Like pass a proposal to take 200HNY and sell it at some rate/day to raise DAI. swarms can still request funds in HNY but they should get them as DAI. HNY in the loosest sense should be a bonus related to performance of some kind. i.e. a swarm that gets say 20K/month in DAI might also get some amount of HNY based on some swarm performance metric also related to a revenue growth or target metric. One thing about converting revenues to DAI is that 1Hive will see what these are directly and then governance can more effectively manage them. Right now I have no clue what 1Hives revenue streams have been doing based on all the changes being made - are we up or down over past month - what do these look like over the year.
Revenue is one of the most important organization metrics - we need a dashboard and graph just for this. We also need a dashboard and graph for expenses. People have numbers - show me a graph please. We need historical tracking on these especially if we are going to start tying HNY bonuses to revenue/expense or other performance metrics.
Also realize that the way 1Hive inflation is structured 1Hive will have some real funding limits. So far I think there is enough HNY in the kitty to pay reasonable contractor budgets and to have some HNY as rewards.
HNY is more than MONEY so it is also time to start to change the mantra on that. DAI is money, HNY is MORE than MONEY because it votes, DAI just gets paid.
4 Likes
Thank you for taking the time to write this up. Several great points to think over
I want to second this idea by adding an bee referral program :
We should seeks for qualified people and appreciates recommandations made by current bees.
The logic would be the following:
If you recommend someone who is working actively in the community on a regular basis and are both still working actively in 1hive after six months of the new bee’s “first day” you are eligible to be paid a referral bonus.
$1500 for pm position
$1000 for regular position
3 Likes
I think maybe half those amounts. And just for developers or someone who can prove they’ve added significant value to community or maybe people who get nominated by a few bees. I would also reduce the length to 3-4 months.
Nice post Gabi, you really are addressing some potential problems and also proposed solutions 
