By now it should be reasonably clear to most members of this community that we have a bit of an issue with negotiations.
Out in the real world, there are negotiations in all shapes and forms. Examples would be political bargaining, arms reduction agreements, oil production quotas, and a myriad of business deals of all kinds. Common for practically all of them is that they are conducted in private and in a face-to-face setting. On the most controversial or sensitive topics, the fact that negotiations even take place is a closely kept secret, one such example being negotiations on mergers and acquisitions.
The need for privacy is caused by two factors. The first is the need to avoid showing both your negotiation position and the outcome so that subsequent negotiations with other parties will not be affected. Imagine yourself in the shoes of a supplier in a market with only a handful of customers - any news of the outcome or even the starting position of your negotiations with one client could have real repercussions on your upcoming negotiations with others. The other reason for privacy is the need to avoid perceived or real loss of status resulting from the outcome of one negotiation, again to avoid this impacting the present and future standing of the party in question. A secondary reason would be the simple need for sufficient peace, quiet, and lack of disturbance, in order to purely being able to focus on the work at hand.
But what do we in Maker do? We have a sprinkling of private negotiations such as the Institutional Vaults, but in the name of trust through transparency, the vast majority of proposals are posted directly on the forum for public and partly anonymous engagement.
The problem with public discussions is that they are presently set up as a yes/no choice to an initial proposal. Additionally, no one from the community has any mandate to make counter-proposals from a collective platform. This has the unfortunate effect that community members cannot really modify a proposal to any degree prior to the vote. The only thing they can do is to loudly threaten to vote against it. Needless to say extremely few are going to do that because they might end up working daily with these new people. The net result is that proposals are either voted in with little debate and no negotiations whatsoever, or the debate turns into a slugfest.
This near inability to constructively negotiate a proposal in public has as a minimum the following side-effects:
- makes it very hard to size CUs to match the rest of the Maker organization
- makes it near impossible to negotiate around performance and compensation bonuses
- creates a psychological hurdle for potential CUs as the onboarding process feels risky
- the more complex the proposal the harder it will be to get it right without negotiations. This has real implications for how advanced DeFi integrations Maker can take on.
Possibly now is the time to change how we are working, mainly by splitting up incoming proposals so they do not form a take-it-or-leave-it complete package.
The proposed sequence is as follows:
The technical proposal, i.e. the typical CU onboarding application and the facilitator application, are posted on the forum as usual for feedback and voted on as a non-binding agreement. Because the application does not mention compensation in any form and the voting is non-binding both the proposed team and the community are freer to adjust and repropose compared to the present as there is less at stake.
Only after the technical vote has passed can the applicant CU post in their compensation proposal. This is after all the normal order of things: first, you discuss what you want - and after that, the service provider will tell you their initial price offering for it.
Now comes the major change - the compensation proposal is not negotiated, it goes straight to vote. There is a catch, however. Every time the MKR holders refuse it, the proposed compensation is dropped 20% from the original value and is automatically put up for a new vote (1), (2).
Eventually the proposal is usually voted in and the team in question now has the choice to take the deal as offered or leave it.
If the proposal has been declined for 5 consecutive polls the proposal is considered utterly refused.
This procedure automates the function of negotiation and leaves it up to the MKR holders how badly they want the deal. Wait too long and the team in question might not take what they are offered. Take the deal too soon and it might be on the expensive side. The same applies to the proposing CU, price the proposal too high and it only results in the compensation being given a haircut.
The above procedure can provide more balance and less stress around the topic of negotiations at Maker by partly automating it. Admittedly, not all issues around negotiation can be resolved this way, but at least this is a start. There is however some increase in governance overhead.
Please tell me what you think in the comments below.
Note 1: Might be any other percentage the community feels is more appropriate. There could even be an element of randomness involved to further limit attempts at gaming.
EDIT Note 2: will likely have to stick to pre-agreed parameters.