Sociocracy Explainer 3: Sociocracy and SourceCred


If you haven’t read parts one Sociocracy Explainer 1: The Basics and two Sociocracy Explainer 2: Diving into Roles of this series, I suggest to stop here and explore those topics first.

In my past two topics I metabolized many of the basic elements and classic roles of Sociocracy as defined by my research into Sociocracy For All (SoFA). In this topic, I’d like to offer more personal opinion and context for the edges I see between the model of Sociocracy and the potential implementation of it at SourceCred.

Sociocracy and SourceCred

What could a more classical implementation of Sociocracy (as defined by SoFA) do for SourceCred?

I believe that by implementing circles and creating a formalized org-structure, SourceCred could vastly improve its ability to increase transparency and decrease ambiguity throughout the entire project. Having agreed upon circles that own their domains, aims, and milestones would increase our ability to make decisions and know who to hold accountable for specific types of work. It would also vastly increase transparency to the rest of the project if we had circles that are responsible for maintaining notes and reports regarding their labor.

I also believe this would create faster, more informed decision making within domains. Better setting and execution of milestones. Fewer and more potent meetings. Better channels for honest feedback and org-wide alignment. Better documentation, less burnout, better decentralization (small and large picture), an easier time communicating milestones and progress with Protocol Labs, and a rebuilding of trust between internal departments.

Some suggestions for first steps:

I suggest that if we’d like to seriously implement a more classical version of Sociocracy than we currently have, that we start slow with a few key actions:

  • Start by defining a very simple high-level org structure made up of circles. Keep the decision making we have to do as an entire project simple by defining the largest department circles together, and then allowing those high-level circles to define their own more specific sub-circles.

    • For example: there is already a naturally emerging Ecosystems Department Circle. That group has already started to use its expertise to define more specific sub-circles such as “Marketing Communications” and “Customer Relationships”.
  • Keep membership of circles small at the start: begin with identifying the most crucial roles/players needed for a circle’s success and efficacy, or with the group of folks who are already extremely high-context in the domain. My intuition is that it will become obvious when more support is needed, and that the circle will have a large pool of talented community members to invite in at that time. In sociocracy, teams need to stay small enough to remain effective.

  • Encourage each department circle (and every sub-circle it creates) to start with creating clearly defined and documented aim, domain of decision making, and set of milestones. Emphasize accountability to both the circle’s aim/domain/milestones/outcomes and the trust of the larger community through transparency, honesty, and administrative documentation.

  • Encourage circles (especially the ones with larger teams) to play with utilizing the four classic roles outlined in the last topic of this series: “leader” (top-down link), delegate (bottom-up link), administrator (logistics master), and facilitator (meetings master).

  • Encourage circles to use the Sociocracy-related tools we’ve already learned from the Sociocracy Working Group such as: consent-voting to make decisions, rounds to generate egalitarian discussion, and facilitation tools to keep meetings moving.

  • Identify the difference between labor we need as we set up our new structure (whatever form it may take) and labor that will be ongoing. Aka short term, mid term, and long term roles/labor/milestones.

Things we’ll need to decide if we start this change:

  • How we agree upon the initial department circles. I suggest we create a proposal topic on Discourse defining the high-level department circles along with their aims and domains. Once a proposal has been created and has incorporated feedback from the community, it could be brought to Core and passed or rejected by our current consent-voting decision making model.

  • How we set up our General Circle. Should the Core Team function as our General Circle, maintaining its current membership? Or do we want to follow classic Sociocracy more closely and dissolve the Core Team to create a new General Circle made up of Delegates and Leaders from each larger department circle?

  • What would the General Circle have domain over? I imagine things like big-picture budget allocations, and org-wide policies (eg all circles must use consent voting, no hierarchical decision making allowed in any circle) could be a good place to start.

  • How to choose the initial members of each department circle. This could be touchy and a potential for a lot of conflict, especially if the teams need to start small. Or it could be super organically obvious who should join where. If there is a lot of conflict around this, we could create a short-list of community-generated nominations for each circle’s membership and have it ratified by Core.

  • How to define membership in a circle. What generally creates the distinction of being in or out of a circle’s team? Can you only contribute to that domain if you’re on the team, or can you take on tasks as an on/off contributor? I could imagine a having a condensed and smaller team which then identifies easier and well-defined bite-sized contributions that people outside the team can do. In the end, this may be up to the individual circles to decide or we may want a broader policy to reduce circle-membership ambiguity.

  • How people get paid. Do circles use salaries, dogfooding, or a combination of the two? I could see a world where each circle has a budget; part of that budget goes to paying salaries of key roles (at least at first in order to ensure vital work gets accomplished, though it could decrease over time) and the rest of the budget could be distributed via the SC algorithm (may require separate instances for separate departments?). Smaller circles would need to assess the resources needed to accomplish their milestones and advocate for those needs to their parent circles. (Eg: the MarCom sub-circle would make a case to the Ecosystems Department parent-circle for getting a specific percentage of the Ecosystems budget in order to achieve their outcomes. The Ecosystems department circle would use the requests of its sub-circles to formulate a road-map and budget request percentage to the General circle.)

  • Which over-arching policies are all circles expected to adhere to? (Eg: can each circle determine its decision-making methods or should all circles utilize consent voting? Do notes and documentation from a circle need to adhere to an org-wide standard for accountability/transparency?)

Things that individual circles may need to decide for themselves:

In the end, we’ll have to figure out how much structure and consistency we want to create between circles, and how much we allow circles to determine for themselves. As a rule in Sociocracy, all circles have agency over decision making in their domain and manage their own operations.

  • Standard Operation Procedures (eg: how often do we meet? How are proposals created? How long is a person allowed/expected to perform a role?)

  • How to recognize when it’s time to split off new and more specific sub-circles.

  • How new members are vetted/incorporated into the circle.

  • How members step down from, or are removed from a circle.

  • How does a circle create a new role or retire a role?

  • Is it okay to merge roles?

  • Etc etc etc

Some soft suggestions via circle diagram visuals I created:

Here I’ve created two visuals of the way my brain is starting to understand the intersection of SourceCred and Sociocracy. This isn’t a proposal, it’s just a sharing of what’s going on inside my head. I can initiate some collective play around a sociocratic org-structure for SourceCred in another Discourse topic if folks are interested in that.

Structure One:

Structure Two:


There are a lot of pieces of Sociocracy that we could continue to build on and implement in our project to increase clarity, transparency, and accountability together. We don’t have to do it exactly the way SoFA outlines, though it’s my personal opinion that we could really benefit from giving it a try and bringing those classic pieces more and more into our space as time goes on.

I’m curious to know, what do you think about the intersection of Sociocracy and SourceCred? Share in the comments!


I’d like to thank the members of the Sociocracy Working Group for all of the ground work they’ve done to get us familiar with these concepts and the building blocks we’re already using which they spent time implementing in our space. I’d also like to specifically thank @Jolie_Ze for their time and effort in getting vulnerable with me around this topic. They’ve helped push back on, sanity check, and bring light to the lineage of these concepts in our space and have impacted how I’ve written about them.