Feedback Governance Charter v1.0

Running topic to log feedback related to the governance charter.

Anything goes:

  • General feedback
  • Things that are going well
  • Things that are unclear
  • Things that are not going well

Reminder that review of v1.0 of the Governance Charter is planned for the week of June 20th, 2022.

Things I’m missing:

  • Pod controller migration as a responsibility in one of the technical roles
  • Description of role/vote delegation process (e.g., pod lead goes on vacation, what’s the process for them delegating power to another member? Also relates to source pod membership.)

2 things come to mind for me:

What is working?
What isn’t working?

Had a convo a while back in the Pod Lead Sync call about this, so want to surface it.

Source Pod
I think we might need to make modifications to the charter (specifically around creation of new pods) that take into account the Source Pod’s existence and role in helping initiatives find homes in pods (and the Source Pod’s ability to create new pods if need be).

Pods need to be asked to create their own charters. That has not happened yet.

I think this gets at an interesting question that keeps coming up around the Governance Charter:

How do we actually implement it in practice?

I think there are a few factors that have made this challenging:

  1. It’s not perfect (some things we expected to work don’t quite work as planned)
  2. Unclear how each pod is implementing the charter (I am guessing this is why you are suggesting each pod has their own charter ‒ but maybe I’m misreading, would love to hear your intention behind this)
  3. Without aims & domains of pods, was hard to use part of the charter (hopefully the recent ratification of aims & domains will help with this)

If I understand it correctly, I think the idea of having each pod have their own charter could make a lot of sense. It allows each pod to take ownership over implementing a version of the charter that works for them, and then actually putting it in practice.

One thing this brings up as an interesting opportunity: @wgow suggested that we might consider more training around the governance processes outlined in the charter.

One of the common pitfalls of organizations implementing sociocracy is not understanding the why (and the how) behind different governance processes. I believe this has been brought up by others before, but it feels particularly relevant now.

As we begin to discuss how each pod can intentionally craft their own set of governance processes, it is incredibly important that we actually understand these processes.

I’d highly recommend everyone read this article (shared by @wgow).

Personally, I feel like I have a LOT to learn and believe dedicated space for training/understanding these processes would be incredibly helpful.

Would be curious to hear how others feel about this!

1 Like

Interesting! I had always assumed that you were expecting each Pod to develop their own charter based on some of our conversation. The very fact that we were giving Pods freedom to implement what works best for them with the main charter as a guideline, and the reality of some Pods likely being formed for a specific project vs a community function made that “assumption” on my part as natural as breathing.

One thing that comes to mind, is that for any specific Pod, there may be roles that are truly necessary, but are not a part of generic governance. In additon, some of the roles in generic governance, seem less like necessary roles, and more like duties that must be fulfilled; Secretary and Facilitator. It seems giving Pods the authority/freedom to decide how they will implement those duties should be left up to them. The larger organization does not require the actual roles, only their outputs. Pod Leads & Delegates are actually required, because they literally need to be the same people showing up in more than one part of the organizational layout.

1 Like

TBH, although I think that article is interesting, I don’t see it as that important to read.

We are not an organization going from a hierarchical to sociocratic model of organization. We are an organization going from unconscious, implicit, leadership largely based on consensus consent, if not consensus consent, to one explicitly based on consent consensus. At least that is what I have experienced.

It may feel really different from the SL side, but from the Community side it has not felt like a hierarchical organization to me at all. Pod Leads took responsibility for making sure basic functions happened, but did not wield authority, so much as guide activity.

Which is not to say training in sociocracy wouldn’t help, we’ve all been indoctrinated in hierarchical models. However, the real learning is always in the doing, and we are doing.

I see a lot more value in explicit NVC training just for exposure, but without a big commitment to it, even if only for “conflict resolution,” I don’t see it making a big change in how we currently operate. There is a natural empathy, and concern for other’s POV that is already very much a part of the culture. NVC helps most, when that natural humanity is lost.


Totally agree with this and really appreciate this perspective. Training can be helpful in giving us a deeper understanding of the tools we have available to us.

Also, I think it’s super important to acknowledge that all of these things (sociocracy, for example) are just tools. Once we get to a point where we feel like there’s a “right” or “wrong” way to follow something, we’re likely swinging too far in the direction of one model. The reality is exactly what you said, we’re trying to move toward more conscious organization by constantly learning and evolving.

While I think sociocratic principles can help us, I don’t think we need to abide by every single thing ‒ because that loses the entire point.


Realized I inverted where I had consent and consensus above.

I think we have largely moved by consensus, and have now made that more explicit, and relaxed it to consent. I had it written the otherway initially.

Discourse lacks strikethrough, so I just unformatted markdown ‘–’ and ‘–’ around the the strikehrough text. Only a single word in each case. Even though strikethrough is not in the editor GUI it does exist. Yea!

It seems you got my meaning, but I always think of future readers as well.


One important aspect of this is to distinguish between 2 vital activities for each pod:

  1. Agreeing on what aspects of the pod will deviate from the Governance Charter and documenting them so they are transparent to all stakeholders.
  2. Identifying specific policies, processes, procedures, standards, guidelines, work instructions, etc. that enable the pod to achieve its intended results.

To be clear, I am not advocating for mindless bureaucracy. We should only create these things where they provide benefits that exceed their costs and risks of just letting folks do what they think is best. They should be time-limited and able to be disregarded when they unduly get in the way of the larger adventure-vision. We should also have some way to assess how well they are working so they can be improved, and treat this improvement work as valuable and important.


First Quarter of Life Review

Mostly nits, like ‘domain’ for Pods in most places should be the plural. ‘domains.’ One Aim, one or more Domains.

Adding/adjourning Pod Members is expliclty given to the Pod Lead, which contradicts the recommendation below that the Admin role be filled by a contract. In reality, three months later we are doing neither.

Adding/adjourning will likely be done by m/n of multi-sig after voting until real voting implementations for Orca Pods are craeted. Presumably as adjuct trustware, goverance contracts, SafeSnap, etc.

The Governance Charter explicitly states, “Each pod has a duration (outlined in the pod’s Pod Ratification Proposal) which is not to exceed 12 months.” However, since there is no Operatinig Manual or other document referrnig to Pod specific details, there is no reliable way to even track when a Pod was started to enforce this part of the charter. We can make up that all Pods started with the charter and use its anniversary date, as their own, but if we are going to do so, it should be documented.

If we are not going to do so the charter should mandate the creation of a Pod Operating Manual to cover this detail, and all other variances in practice from the charter. An Operating Manual would also be a place where Pod policies can be uniquely defined and found by new Pod members, or referenced by existing Pod members. An idea agreed upon, but uniformly not acted upon, except possibly by SL Pods.

Pods are currently so small for regular members formally in the Pod, I question the enumeration of Social Roles other than Pod Lead and Delegate. In fact, Delegate could be questioned, but it does ensure a perspective other than the Pod Leads is represented in Orca-source. Most Pods committed and regular members are so small, the Delegate is typically only representing them self as a member. For this reason, if we are running a minimum viable process, these roles should be elided. I do think the functions are necessary though, and the processes and/or work products of these roles should be a part of the charter. That is to say, we as a community expect certain things to happen in all Pods, and certain work products for certain events and/or regular period, (e.g. meeting notes.)


Those are all good points.