I’m putting down my answers to the Open Questions below.
If you prefer to see a video version, here’s the Q&A livestream from last week, edited to show only my answers: https://youtu.be/I1pMHofACG0.
- ZIP Ambiguity: The ZIP-1014 language has some ambiguities. Where would you stand on how to interpret and implement operational activities when there is no explicit language to guide you? How should the MGRC consider community will/preference?
At this point, the decisions that are yet to be made include: whether we will be “investing” (returns expected) vs “granting” (no returns expected); whether MGRC members will be full time or part time; and whether members will be compensated.
TL;DR answer: Apply lots of common sense, and put yourself in each stakeholder’s shoes.
(I think the word “uncertainties” is more accurate and less loaded than “ambiguities,” so I will use “uncertainties.”)
Elaborating further,
- Applying “common sense” involves considering each major concern and ensuring that the solution solves, or hedges against, each one. In the push-pull of conflicting options, the underlying concerns usually provide valid and valuable signals. In weighing those signals, we should look to optimize rather than compromise. Zooko makes a point about leadership and withstanding criticism in a recent post
- The four groups of stakeholders to take into consideration when we make decisions on these uncertainties are: (a) the organized groups ECC and ZF (we should be coordinated in action if not identical in mandate), (b) the Zcash community, (c ) the crypto community, and (d) the non-crypto community. Facebook failed to take into account (d) when they first launched Libra, a global kerfuffle ensued, and it led to a year-long restructuring of their efforts
For the record, I think it’s good that there are some uncertainties before the MGRC is fully formed. Otherwise, there would be little scope for independence of thought and action between the MGRC and the ECC/ZF - and I believe that independence is what we are looking for, to some extent.
- MGRC Role: Should MGRC be a “driving actor” or provide sourcing, oversight and review? Should MGRC be more of a bureaucracy (with hierarchy, continuity, defined rules, and expertise) or can it be an adhocracy (decentralized and flexible)?
Definitely a driving actor. We’re at war. There is no guarantee that we’ll be around in 3 years. We have to fight for our survival and our mission. The MGRC should measure itself against KPIs linked to productive outputs, e.g. traction of z transactions, market share within retail transactions.
However, i don’t think one needs to be full time in order to be a “driving actor.” With a team of motivated, competent and high-integrity folks, much can be achieved without having to perform a full-time role. I also believe that not being full-time leads to greater independence, where each member is making objective arguments that are divorced from concern about losing a major source of income.
I am leaning towards adhocratic in actions (I think made that word up, heh), but hierarchical in accountability. That means we should be nimble when we do things, but open about what we are doing (no cowboy flights of fancy).
- Teamwork: Have you had previous experiences of being put together rather arbitrarily in a team before? If so, how did you manage? How will you go about managing disagreements between 1) yourself and another MGRC member and 2) other MGRC members with each other?
Managing disagreements is one of my day jobs. I work with a brick-and-mortar financial services company going through digital transformation, and there are frequent serious disagreements between the business and IT teams. My job is to serve as referee and problem solver, and most of that depends on being able to bridge the divide between opposing agendas.
At the end of the day, I find that what resolves most disagreements are:
-
Letting each party know their concerns are valid. Knowing that you respect where someone is coming from, even if you don’t agree with them, often elevates the conversation from “I am right, you are wrong,” to “how do we solve this.” People say respect is like air: you don’t notice it until it’s gone. Holmes Wilson, another MGRC candidate, makes a similar point in his Q&A
-
Understanding the more core reason for them taking a particular stance, and making sure that the solution treats that, or at least doesn’t trigger it. For example, if an integration with a partner isn’t working out, the business guy may be worried about failing to deliver his revenue targets, while the IT guy may be worried about looking outdated. In delivering a solution and an explanation for why things failed the first time round, both fears need to be treated. Telling the IT guy that he’s 10 years outdated or the business guy that he picked the wrong partner may be factually accurate, but a recipe for fireworks
- Processes: If you were elected to the MGRC, what processes and frameworks would you attempt to set in place in order to allow frictionless collaboration between the members of the MGRC? Is it a conflict of interest for a member of another cryptocurrency project to be on the MGRC?
I’ll leave the specific question on processes for collaboration to general agreement and iteration.
I think the more important thing to get done in the first couple of weeks are three specific deliverables:
1. A set of principles for the MGRC
This will set out how we behave vis-a-vis all our stakeholders, and with each other. It should spell out how we manage conflict, what the expectations are for the committee and each individual, values we hold tight, and things we will not do. This will underpin the next two documents
2. A playbook for the MGRC
This is the canonical reference for the MGRC’s objectives, resources, success metrics, blueprint for development, and anything else that would serve as a guide for what we will do, when we will do it, and how we will operate. It should be a living document that grows with us. Here’s an example: Playbook for software design and development - By thoughtbot
3. MGRC Constitution
Like the articles of association of a company, this document lays out, in a conservative fashion, how votes will be counted, how conflicts of interest should be handled, the things that the MGRC will and will not do, etc. This is a shorter, more rigid document that should only be updated with formal agreement from the ZF
I don’t think a member of another crypto project should be automatically conflicted out of our ecosystem. Firstly, if they can provide value by virtue of helping see beyond our shores, it would be strongly positive. Secondly, locking someone out because they have legitimate interests in other projects that further values we share, like freedom and privacy, would not be consistent with being mission-pure.