Maker and negotiations

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:

  1. 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.

  2. 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.

  3. 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).

  4. 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.

  5. 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.

13 Likes

I don’t have the right answers, but I can tell you that in the Centralized World of Fintech many companies these days are starved for talent and salaries are trending higher. Even outdated SaaS companies are starving for talent and they are ready & willing to pay for it. So the talent pools have many choices. I guess what I am saying–this is a RISK-ON 24/7 industry versus Risk-off in a centralized ecosystem (besides the fact that you can lose your job, or your company can go out of business). Unfortunately this is not a risk-averse industry. The right compensation is a key driver in order to retain/gain talent. Perhaps negotiating compensation can be alleviated with an understanding that Core Units will provide the best cost-effectiveness results and more transparency to the community, in order to measure their value?

This is known as Hobson’s Choice

3 Likes

Thanks @Planet_X for this elaborate write-up on a topic I haven’t seen discussed before :+1:

Starting off, I agree with the statement that our current communication tooling (ie. Discourse) is not well suited for negotiating terms. The binary yes/no voting, combined with the potential loss of face/loss of social capital for sharing negative feedback adds a lot of resistance to the feedback mechanism for proposals.

I disagree with this statement though:

In practice I think that proposals are rarely put to vote before any prior feedback was collected. Behind Maker’s public and transparent governance process there is still an organisation with domain experts and a soft power/influence dynamic. When an external team is working on a cross-DAO proposal, I think we can safely assume that they collected feedback within MakerDAO before the proposal is put to vote. This also applies to CU proposals and budgets. Let’s also try to consider this ‘soft’ and opaque feedback process in this discussion.

Regarding your proposed solution, I do sympathise with your request for native negotiating/iterating on proposals in our communication tooling. However, I do feel like your proposed process for automated negotiations/‘auctioning’ will introduce some toxic and opaque dynamics to the governance process. Similar to when negotiating with a car dealer, you would never take the first offer—in fact, you wouldn’t even consider the first offer as potentially reasonable because ‘the way of the game’ is that a couple of negotiation rounds are usually required before a deal is closed. As someone who’s part of a relatively new CU, I dare to say that the current process of writing a MIP39 and accompanying budget is driven by questions such as ‘what does the DAO need?’, ‘what can we offer?’, and ‘what do we need in order to sustain this team?’. I would hate to see this process being poisoned by opaque game-theoretical games because I believe that the best DAO contributors and technical teams are not necessarily masters of negotiation :sweat_smile:

As member of the DUX team I’ll keep a close eye on this thread and see where it goes. In case there is soft consensus on a shorter-term solution (eg. altering the governance process in some form) we would be happy to provide input on the technical feasibility and potentially collaborate on implementation.

Regardless of the outcome, I believe that ‘facilitating negotiations and iterating on proposals’ should be a functional requirement for any future Discourse successors.

1 Like

Exactly. And that is why we should move to automate the negotiation process. Automating the process could level the playing field.

This is precisely the type of mechanics I want to avoid. First of all, it makes the onboarding process opaque and more of a who-knows-who type of thing. Second, it corrodes Maker governance as proposing teams feel they have already been given approval because they spoke to such and so and all that is left is for MKR holders to rubberstamp it. Thirdly it leaves the door open for exploitation by slightly too enterprising teams by not offering any backstop except outright refusal.