Kris, thank you for the wonderfully thoughtful comment!
iâll address a couple points:
I super agree with this ideal state you describe. Unfortunately this is not at all the case. Despite talking with workstream leads for months about having more logical comp, and People Ops holding the domain of compensation the whole time, any attempts at guidance around comp have been left behind and workstreams have not been seeking advice. Now, we have ALL had a lot on our plates and a lot of this is due to just trying to move as quickly as possible on what is most essential. (myself included! i know I even have an unsent comment open on @seanmacâs proposal on MMM contributor levels )
However I donât think that simply making suggestions will result in there being legitimate compensation across the DAO. Evidence: I made a DAO Hiring Process Guide (including a section on making a salary offer) back in November and circulated it a few times, and afaik no workstreams used it.
the big issue at hand is with this proposal not tackled, how do we deal with the current compensation, for existing contributors, as this is already causing tensions?
Indeed this is a big issue - and I propose that we create a skills/competency leveling matrix that is custom to gitcoin. Such matrixes usually look something like this:
Ours however would be customized to our own DAO and might include such verticals as: self-management, ecosystem expertise, and MAYBE even proximity to our essential intent.
But in the vein of trying to make sure our work is efficient & useful, itâs important to get workstreams on board with actually using this stuff. A custom competency matrix like this would allow:
- anyone to score a new job candidate into a salary band, independently
- folks to evaluate salary levels in a fair way if we DO need to go into a period of leveling inequal/unjustifiable pay
- contributors to self-assess what skills are the most important to gitcoin, therefor seeing what they should improve upon to become more valuable to (and valued by) the organization. great for using professional development resources in a smart way.
Itâs hard to know though whether we should embark on this work when workstreams are still arguing against having a shared comp logic. I really donât want this to become a piece of work that People Ops produces and doesnât end up getting used by workstreams.
People Ops is in an interesting position. MMM can produce content, run events, etc. GPC and Moonshot can code & release changes to our products. DAO Ops tooling can make changes to our discord structure. FDD can change our grants eligibility enforcement. But when People Ops produces work, folks across the DAO have to agree to use it, otherwise it just sits & gathers dust while the people problems tend to persist. Iâm not complaining (i love people operations work & this interdependency has always been an inherent truth of it in every flat org Iâve been in ), but I am trying to draw attention to how and why itâs crucial to get agreement on these things.