Standardize Pay Rates for Spends

Given all the issues and arguments we face around compensation for proposals I think we should discuss standardizing pay rates for spend proposals.

A way this could be done is making 2 ranges for compensation.

  1. Non technical work
  2. Technical work

Each would have a bottom and top rate depending on experience, background, ect. Then the rate could be revisited on a schedule and agreed to via signal proposal.

I suggest this not because it’s perfect, but because if we don’t do this and the pattern continues, the compensation will continue to increase arbitrarily. It’s ridiculous to me (for example) that some non technical committee leads gets paid more than a contributor like Baedrik (for authoring the snft standard), and it’s clear to me people are going to continue to take advantage of this public good unless we implement standards around pay. People simply cannot be trusted to pick realistic amounts.

4 Likes

Thinking through some numbers here is what i have

Non technical

$30-75 per hour

$4,800 - $13,500 monthly cap (min - max rate at 40 hours a week)

$2,400 - $6,0000 monthly cap (min - max rate at 20 hours a week)

Technical

$50-150 per hour

$9,000 - $24,000 monthly cap (min - max rate at 40 hours a week)

$4,500 - $12,000 monthly cap (min - max rate at 20 hours a week)

  1. If project based pricing is used then the monthly cap still cannot be exceeded.
  2. Things that fall in the middle of the 2 categories could go between the max rate for non technical and the min rate for technical.

Edit 1: changed low end of tech range based on feedback.
Edit 2: changed high end of non tech range based on feedback.

4 Likes

Following this chain of thought, should there be a standard for creating proposal pricing?

Right now, it’s “we took the average SCRT of the last 30 days to get the current estimate.” I don’t particularly mind that usage, but I would like for the method to be codified in some way, regardless of which direction it takes.

I def dont agree with any average value being standardized so i wouldn’t agree to such thing. I only care about value when it goes on chain and when proposal passes.

That’s fine, I wasn’t suggesting that be codified, just the method for SCRT calculations codified.

For example:
Option 1:
Take 30 day average, multiple by {hours} * {qualifications {tech|non-tech}} = SCRT to be paid

Option 2:
Take 90 day average, multiple by {hours} * {qualifications {tech|non-tech}} = SCRT to be paid

Option 3:
Take 1-week average, add 20% for buffer (with justification*), multiple by {hours} * {qualifications {tech|non-tech}} = SCRT to be paid

Option 4:
Take NO average. Take price at posting to governance, add 20% buffer (with justification*), multiple by {hours} * {qualifications {tech|non-tech}} = SCRT to be paid

Just a few ideas. If option 4, I’d want for it to be updated before going onto Governance, as that seems only fair, given there’s a 1-week buffer of forum → on chain proposal.

1 Like

Option 4 seems best out of the presented options but what we are really saying is, everyone will ask for 20% more. Better than the alternatives and not too crazy or unreasonable.

1 Like

Per meeting conversation:

Another option of allowing for supplemental funding if price drops significantly [during governance]

2 Likes

Some points from today’s governance call (check the full notes for more details):

Consensus seems to have formed that spend proposal pay-rates should be based on the average value of the day before submission (and increased by 20%). If the actual result (in USD) is >10% lower, a second proposal is put on-chain for the difference. Upper limits should be formulated and all above details validated in the upcoming Validator Survey and a resulting Signalling Proposal.

One aspect that’s hard to nail down is the upper limit(s) for different categories, except that we should probably start off with a simple model. Please respond below with your favourite model and its details below so it can be included as an option in the Validator Survey to vote upon. One model is already described above (technical and non-technical).

3 Likes

A related discussion regarding discretionary budgets just occurred in the Governance Telegram channel, and it was suggested to bring this into the pay rate discussion and add it to the Secret Network Charter.

Topic: Discretionary budgets should be entirely spend on the original aim irrespective of SCRT price at the moment of exchange to USD.

Please also include some thoughts on this topic in your replies below.

1 Like

I think it’s worth discussing if there is flexibility to use discretionary funds for things in the committee or group charter instead of just the specific spend in question. (In the event of discretionary funds going up in value before sale for usd)

Here is how i see it (roughly)

Strictest rule : discretionary funds only used for specifically things laid out in the proposal.
Less strict rule : discretionary funds only used for things outlined in the group / committee charter of the proposals.

Which we decide as a community comes down to how much flexibility we want proposers to have.

Discretionary is by definition…discretionary, but the funds should always be used to further the spirit of the charter.

In Awareness for example now that there are more funds on hand in USD value we could pay for a YouTuber or two which has been requested. I did not include this as a distinct line item (because it was mostly around conferences and the Secret Agent Program), but it seems reasonable to take a small chance given the relative risk/reward for doing so.

In the end it’s up to the lead to spend wisely and in the spirit of the proposal/charter. If they are not doing so, they are abusing it.

2 Likes

Personally I think all asks should be in USD, and SCRT doled out at milestones or when external invoices must be paid (e.g. buying hardware) at the time. For fixed costs like hardware, a small buffer can be added to help pay for off-ramping SCRT to fiat and price volatility from time of distribution to off-ramp. For labour, no buffer added as this is inherently more flexible as the recipient can do what they like with the SCRT earned - delegate, sell, hodl, etc.

3 Likes

I totally get that this wording is simply a suggestion to kick start the conversation…

I’m sure some will be familiar with engineering environments where folk are unhappy that marketing or sales are rewarded more than those that make widgets. The model that resembles the manufacturing factory where folk on the shop floor earn less than the office worker. Yup, the plight of the engineer is not new, but doing the same in reverse is unhealthy, let’s bear this in mind.

It’s worth considering that the actual effort a technical person puts into their craft doesn’t really change. However, creative thought processing usually develops with experience and over time, and this naturally increases the value added.

So what is the classification of non-technical?

Let’s consider only for the sake of a crude example, that technical is engineering, and that non-technical are any of; marketing (awareness), sales, compliance, law, finance, business dev, international growth, and education.

The question that comes to mind is, are non-technical giving any less value to the eco system? Well, for a start, many disciplines must gain an in-depth understanding of the technical product, otherwise, how can one document about it, market it, sell it, educate about it, or even defend against threats, so those disciplines can really be classified “technical” – oh and keep mindful of the actual non-engineering but technical duties that each perform. So technicals can now be considered as; engineering, marketing, sales, education. Okay, moving on, how many engineers do business dev, finance, law, or compliance? Okay, so those are also technical. This process goes on and on, rinse and repeat, and the more we learn about each others responsibilities, the more we should gain a true appreciation for why we all exist, performing technical duties that each other may not like, or want to be part of, because, why do law if you love design, right? Though personally, I do enjoy many areas of marketing, I digress :wink:

I think from my crude list that “administration” is the only non-technical duty while still earning a good remuneration.

Bottom line, be careful how a role or discipline is classified. Don’t jeopardise growth by not appreciating, backing, and rewarding each other. It would be something special if folk are rewarded such that their only concerns IRL are how to improve their contribution to the eco system for the benefit of all, right?!

7Two1 (aka BEngEE)

3 Likes

I like and agree with the sentiment that this was begotten from, but disagree with the notion. It is attempting to objectify subjective roles, talents, and responsibilities.

While yes some ‘technical’ workers have been underpaid, and potentially ‘non-technical’ workers could be considered by some overpaid, this is not the right kind of line in the sand, nor do I find the anecdotes indicative of the nature of the network in the slightest.

Enigma then, and now Secret Network, has always been exceptional at development, and atrocious in terms of marketing, partnerships, awareness, education, listings, and everything that is associated with ‘soft-skills’ or ‘non-technical’ work. Were more money to have been spent on non-technical work to better establish ourselves as a blue-chip, to higher prioritize documentation, marketing, and User Experience, it is very likely that the price of the SCRT token would have been much higher for a much longer time. Had that been the case, less of our resources would’ve needed to be spent on technical or non-technical work. We could have hired MORE devs. MORE lawyers. MORE marketers. MORE biz-dev teams.

In the extra governance call today it was mentioned that the Infrastructure bill you had suggested (300 nodes) was more important than all the other committees needs, because we need that to exist in 5 years. That is ABSOLUTELY true, and I have and do publicly agree with you and your goals to drastically expand the infrastructure of this ecosystem! BUT, I agree with that only because I believe that we will have the non-technical support and drive from talented and driven individuals to increase Marketing, Awareness, Exchange Listings, Documentation, etc. If those aren’t conducted at a high level, then there won’t be a point in having a vast infrastructure layer. As we’ve learned from our years outside the top-100 tokens, this is not an ecosystem of “If you build it they will come”. There’s a reason that marketers and business-men are so highly paid. The deals and meetings need to happen.

I LOVE your work with Infrastructure, and think that you are doing an incredible job! I second your opinion about multiple devs being drastically underpaid, especially if their efforts are compared to others in the ecosystem, and absolutely agree that that should be rectified. This WOULD be a wonderful solution, as I’m a huge fan of objective metrics, if it were pragmatic, but I don’t believe it would be. I think metrics such as these would further drive a wedge between parties in the ecosystem, and dis-incentivize dedicated work and drive.

Yes, non-technical people can learn how to code. There is efficiency in specialization. In the time it would take you or I to become developers, you could build out our infrastructure effectively and substantially in ways no developer could, and I could’ve onboarded 10 other developers with experience and organized their tasks. If I were incentivized to learn how to code instead, the network would be worse off.

2 Likes

Thanks for the kind words. I want to be clear that I value both technical and non technical work a lot. But I am merely suggesting limits in line with industry standards for paying different types of work. Do we want to pay 20k a month for a lead working on maintaining a twitter account? (Intentionally not real world example) probably not. Might we want to pay a dev developing a network changing dapp who needs “seed” funding? Maybe. I don’t think it makes sense to have the same limits for both categories and if people disagree with that, I encourage them to propose different numbers or changes for me to make to my numbers. These numbers have been adjusted and can be adjusted further of course.

2 Likes

At the end of the day this is a tech product and technical roles should have higher compensation. This isn’t to demerit the non-technical work, it is definitely crucial, but without devs we wouldn’t even have a product in the first place and that’s why the compensation in the tech industry is how it is.

Weighing in per pmuecke’s request.:

:one:

I don’t support arbitrary pay ranges, nor do I support dividing pay rates based on arbitrary buckets.

Spend proposals, IMO, should be a reflection of the person’s (or group’s) level of skill or experience, the market rate for the work involved, time or effort involved to complete said work, and the value delivered.

To that end, each spend proposal is unique and should be evaluated in a vacuum – not based on what some other individual or committee, with a completely different ask and set of individuals executing the work, received.


:two:

The crux of the issue seems to be that spend proposals are issued with a currency which fluctuates in value.

IMO, Identifying a way to ensure the amount issued is an appropriate reflection of the above, outlined criteria seems to be the most appropriate solution.

This also seems to be the simplest solution.

I worry that making things too complex will make it difficult to communicate to the broader community what the guidelines are, potentially result in more community backlash when someone doesn’t follow guidelines properly, and discourage proposal submissions at time when we should be spending more to facilitate growth.


:three:

Lastly, I would encourage the community to critique spend proposal in a way where they work with the propers to achieve a satisfying outcome, instead of against.

For example, instead of saying “No way, X is not worth this much,” consider offering suggestions for improvement, like: “If we’re going to be spending that much, it could be great if you also did Y and Z.”

I personally find these spend proposal conversations to be toxic and unproductive, because the criticisms end up creating these us vs. them environments, when we should be fostering more support and collaboration.

4 Likes

I see two problems in this discussion.

  • SCRT vs USD pricing of pay and proposals.
  • Appropriate compensation of work.
  1. For the first issue I would favor pricing of work in $USD as it is the easiest to utilize for the community when comparing proposed financing with industry rates. Payout is the equivalent $USD value in $SCRT. For volatility a threshold % should be added to the payout. It would be the responsibility of the proposer to make the appropriate $SCRT to Fiat conversion. The proposer should also provide proof to the community of the conversion. Any remaining difference in SCRT should be returned to the community pool.
    I forsee that eventually we could utilize Shade/SILK to make the process of limiting the slippage at time of payout.

  2. IMO in a decentralized network the the determination of pay rate falls upon the proposer who is seeking the funding. They should appropriately price their own work commensurate of their expertise and effort and thoroughly breakdown the rational for the requested payment. This isn’t something that inconsistent on proposals.

The above 2 points also yield to the following:
As a new member just arriving to the forums and having examined through proposals it would appear to me that the problem lies in the proposals themselves. From my observation there is no standardization to the proposal and the required depth of detail. There is ZERO obvious accountability in demonstrating to the community that funds are being used appropriately.
Additionally, there should be a standardization of proposals i.e. a template of some sort to be a minimum for proposals. As this would allow the community an easier time with determining if the funding is appropriate. Additionally a requirement for proof funds for things like the conversion from SCRT to fiat is 100% a must. Without standardization you end up with some proposals being vague as possible and others being more detailed.

1 Like

Since policy discussions on calls and on the forums for the secret network is disproportionately influenced by non technical people with minority stakes on the network, I’m no longer interested in pursuing pay rates. On any call we have on the topic they all argue against pay rates so they can continuously increase their pay arbitrarily and way out of line with industry standards. This is a political type of problem to solve and I’d prefer to focus on solving for technical problems. Hopefully we get more technical people taking part in shaping governance and policy on the network, since we are a technical product.