Maintaining Social Order in Decentralized Communities

Common Practices for Maintaining Adept Teams

Steven McKie
Amentum
7 min readJul 30, 2019

--

Distributed, Coordinative Project Management

Often in the day-to-day mumblings around crypto, especially in the Ethereum community, the conversations around governance continually evolve.

Now that more literature has become available on the topic [1, 2, 3, 4], we must strive to continue to dive deeper into these discussions around privacy, governance, and community; doing so concurrently, while deriving the appropriate norms to more aptly achieve our goals of decentralization, collectively.

Whether you’re an investor, engineer, or a retail speculator on the sidelines, you have to respect the second order desire for all of us to somehow build resilient, trust-less systems that stem from our deep infatuation with spreading the ethos and concepts of decentralization.

To do so requires apt and timely communication that is delivered from diverse groups of stakeholders, consistently, to the appropriate parties, in order to distill these perspectives to the generalized public.

The Systems Bible is an entertaining read for anyone interested to an introduction to systems project management

My project management teacher in college stressed over and over to “be here now”, and focus on the task at hand. Only by being present, can you truly listen, and effectively communicate with vital stakeholders (both technical and business) to see a project to its successful fruition.

In technical project management, there are a lot of moving parts. We’re all building machines, but we ourselves are not mechanical, and we need fluid communication to ensure milestones are completed in an efficient and timely manner. When working to build decentralized, distributed systems, this becomes even more difficult with all the diverse stakeholders at play. It’s a game of mass social coordination — one now aided by incentives presented by public blockchains.

But, there are rules when we have to coordinate on the social layer to enact our grand technical visions on a massive scale. To ignore these norms and strategic methods to making a team cohesive, means you’ll either have to learn to implement these skills on-the-fly in the future, or never get the chance due to almost assured failure.

Organizational Behavior 401

We’ve discussed governance in the form of blockchains, emergent governance, DAOs and the usefulness of programmatic assistance when coordinating groups and motives, but what about the most basic of norms and strategies for aligning groups to complete localized goals?

Have you ever heard of the concepts of “forming”, “storming”, and “norming”? If not, you’ll definitely want to. In short, it’s described as the natural process any group goes through when adjusting for performance upon initial formation. A new formation (forming) of highly exposed public facing devs may cause drama while things storm (tumultuous period of establishing common practices and communication), and eventually normalizing those into methods to be cohesive on a regular basis (norming). It’s an emergent phenomenon that every group goes through. And, no group is exempt from this process; it’s simply a model of how people engage and interact.

When going through these phases, clear and concise communication is paramount, as imprecisions in language are typically what causes humans to work together ineffectively.

And like real governance, social governance should move slowly. You want a slow and rigorous process of checks and balances so a tyrant can’t reign in control and inflict damage on your governmental norms and legal procedures. This is a feature that ensures tyrants can’t disassemble precious social norms and inflict societal damage on a populace, and is a part of making sure the citizens’ (or users) stay in control at all times.

Fig. 1 The scale of social governance and distributed coordination can be visualized as notated above. Citizens in control means they are empowered to make choices (ideal); citizens who are given symbolic powers (middle), but officers of the law are chosen and decisions are still made without them, so they’re mostly just consultants to the incumbent political forces. Once the citizen has no power (bottom of the scale), they become subject to manipulation.

Tools to Ensure Consistent Communication

Let’s now get to root of how this is all done, so we can make note of how to best establish the norms necessary for further social scalability. Let’s break it down into sections for what’s most important to remember:

Participation: Individuals participate in systems in variable ways, and they should seek to act together. And the support of independent community interests should be funded and supported. Important so the individual isn’t disillusioned to their real capability or power, even if participation is limited by function.

Entrenchment & On-boarding: Many systems can struggle to sustain due to the inadequate construction of initiating individuals into a group. Without this initial engagement, eventually social trust erodes.

Control: When creating decentralized systems, we must decide how little or how much control to allot to others. This means deciding where on the ladder in Fig 1. you wish to place your eventual citizens/users.

Granted Powers: Participants must then of course understand their power and abilities, else they can’t exercise them. You cannot fear loss of control, power must be distributed evenly from the start so it doesn’t appear a scarce resource worth capturing.

Defined Roles & Practices: The participants in your system must then know their individual roles, given their granted powers, and what is ultimately expected of them as a practitioner maintain your open source system.

Stakeholders & Community: You must engage with, and actively maintain your community to continue to onboard new users to grant the power of controlling your system so it may scale outward. Everyone who participates in a system will not do so equally, so you must understand who holds the most influence (in crypto this is technical developers writing code/specs).

Partnerships: These partnerships can come from anywhere, and should not be confused with stakeholders and community. They are outside parties with mutually beneficial interests (think public assets, and the exchanges that list them and provide liquidity). All the partners don’t have to contribute equally, but they do have to trust and share the commitment of those building your community.

Commitment: You cannot let apathy get the best of your growing system. People must commit to achieving some goal (often communicated via memes in crypto). If people seem apathetic to your proposals in your community of stakeholders, it’s likely they don’t relate to the interests of those formalizing them. This is why diverse community engagement and growth is crucial.

Group Accountability: The concept of “not invented here, not accepted here”, is very prevalent in technical communities of developers. To reduce the likelihood of this zero-sum group-think, practice running many different workshops and events to think through hard problems presented to the community and attest to their practicality. This allows the community to slowly negotiate with others as to whats deemed acceptable when compared against an existing framework of organically constructed community norms.

Confidence: To tie all of the above concepts together, you need people capable of delivering these visions in your community. In crypto, this is again the aptitude of the low-level developers you have actively participating in their roles. Your stakeholders need to feel confident in everyones’ ability to deliver on their accepted milestones. The ability to make complex decisions and integrate them in a moving system does not happen overnight. These norms are honed and learn in time, by utilizing best-practices.

Moving Beyond Theory

Keeping the above in mind is just the beginning of understanding the key parts of organization at scale. There are other best-practices you can employ as well.

Here are some other other tips to improve upon your social coordination methodology, and increase your propensity for success.

  1. Public discussions with community stakeholders with wide variety of interests are great for improving participation in a fledging community. But remember, a conference panel limits major discussion points, who can speak, and only address some of the perspectives of community members in the audience. Use them wisely and strategically. Stick to purpose-built events for more engaged discussions on specific matters.
  2. Know who’s accountable, and make sure they have the skills to deliver. Important not to just give power to those who have too much responsibility, and/or lack the ability to deliver, simply because they appear best for the job on paper.
  3. Recognize that volunteer groups that formalize outside of your core community are important. However, they will possess their own agendas, budgets, and motives. They should not be seen as mere neutral “helpers”. Ensure to empower the volunteer orgs that are deemed healthy after checking your sources, and utilize their expertise where you can.
  4. Understand that subject matter experts are merely consultants, and do not represent the full voice of your stakeholders and community members. And, those experts may also not feel comfortable being seen as representatives of a whole community (think Ethereum core developers).
  5. When employing the use of outside consultants to help educate or come to consensus on a future matter to be deployed, make sure the consultants’ purpose and power is clear, and there exists healthy boundaries between them and your stakeholders in the community. Encourage them to ask difficult questions that others may not have thought to inquire, and make sure that whoever employs these consultants can deliver on integrating their feedback, to avoid community unrest if social sentiment trends towards others complaining of stagnation in its implementation.
  6. Do not downplay an opportunity to consult subject matter experts as consultants when a project’s success may depend on it. To excuse that opportunity may have future consequences, with multipliers too. If skipping SME consultation is absolutely necessary, explain the constraints why clearly (to the whole community), and produce an educational resource for those that may miss those points so they can have a crash course. This helps ensure smooth social consensus.

This essay will hopefully serve as a future resource for anyone trying to wrap their heads around decentralized communities, and how to best govern their community of granted stakeholders more effectively. Sound governance processes and procedures should be met with equal efforts in employing structured and sensible community governance standards.

--

--

Steven McKie
Amentum

Writer. Programmer. UX/UI. Bitcoin/Ethereum. ENTP. Doing things