Sociocracy and Building Complex Technical Systems

I was talking with @john.l.clark the other day, and we were contemplating if there are ways in which sociocracy’s policy process might be limiting when it comes to building a more complex technical system (in this case we were talking about website infrastructure). Basically the two ways I’ve seen is the co-creating a proposal process, where everyone is building one proposal together, or one person privately creates a proposal and brings it to the rest of the group for feedback. In both of these cases, whatever the foundational beliefs of the original proposal usually define the framework for the finished proposal unless people openly object to it strongly enough that the process effectively starts over from scratch. I guess a metaphor using common tools for this I can think of to describe a similar problem-- Imagine in your policy process you get fixated on how to dig some holes with a shovel early on in the process and never stop to think about maybe the problem is too big to use a shovel and you should rent some bigger equipment instead… or you only realize that the shovel might not be the best tool after everyone has consented to it and it feels harder to change your mind again?

Sociocracy tends to be biased towards action, which is great a lot of the time, but sometimes I wonder, especially with decisions that can prove costly in terms of time and resources, if its worth fighting that bias, and if people have experience/advice for how to balance those tensions? There’s moments where I’m tempted to suggest something like, “Why doesn’t everyone take some time to think of how they would solve this problem on their own, before we work on making a policy together,” to make sure good ideas aren’t getting lost early on when people just follow someone else’s lead, but the ways that would lead to more conflict and difficulty actually making a decision are fairly predictable and problematic too.




It’s not only with technical topics but with all decisions that have big implications that are costly to un-do or adjust.
There are three strategies that I’m aware of. Let’s say, I’m building a house.

Strategy 1: Build the upstairs bathroom with all details first.
→ most often not a good idea. But that can be done IF you want to use the bathroom first and it’s possible to build the rest around it. Not for a house though.

Strategy 2: Build the foundation first and build it solid.
→ That can make sense in an example like yours. We’re not hashing out the details but instead talk about the fundamental things.

Strategy 3: build a coarse house first and then flesh out.
→ We don’t start with the foundation but we build the whole house but we build it in paper to get a sense of what it would look like first. My experience is that it’s a good idea BUT it requires a lot of trust in the group because one asks for consent on things that are provisional. For example, do you consent to the house being ca. 12m high? What if someone objects because they can’t say whether 12m is good unless we also show the full design or building specs? Then we’re trapped. So in this approach, everyone has to take a deep breath and accept that we are saying yes to things that are unspecified.

Now to your topic. I completely agree that building a full proposal would be unwise (it would probably turn out like strategy 1, way too much detail and people losing track of their biases). Yet, one person writing it can be even worse because now they are bringing a complete bathroom with golden towel holders and all, and ask the circle to build a house that fits the bathroom. That never lands well. So I encourage groups to go with strategy 3 - make a general decision on the general approach first - and do it together. Details can be hashed out by individuals, the direction-setting happens together.

Not 100% sure I incorporated your point well. Tell me, @Lainewyne and @john.l.clark? Or use my metaphor and explain it again?

1 Like

Ideally generating a proposal for a complex issue should start with “Picture forming” - naming the questions that would need to be answered in the proposal. So what tool to use is considered in context and not determined before the context is understood.

For example, given our understanding of the organizational need:
How many holes do we need?
How deep should the holes be?
How wide should the holes be?
What shape should the hole have?
How soon do we need the hole dug?
What budget considerations do we have?
What is the size of the team we need for this job?
What skills do we need in the team to get this job done well?
What tool(s) would we need for the job?


I interpreted Laine’s query differently. It seems to me the question might be answered by one’s orientation to reaction rounds. If the proposal seems too well-formed and you want to question the foundational belief, I wish that you would do exactly that.I think a reaction round is inclusive of ALL reactions, including questioning the basic assumptions in the proposal. If I were in that circle, and we wore ourselves out digging holes and then you said, “Yeah, when the proposal was presented I wondered about …” I think I might ask what stopped you from saying that during the decision-making process.

1 Like

There’s a lot of layers here I think!

Re: Second Paragraph

It seems the gist of what you’re getting at in the second paragraph, seems to be this aspect:

Is it better for people to share their ideas all together and influence each other with them?
Is it better to have people think through things all together on their own?

I think it’s impossible to know the answer, I’ll offer these two considerations.

  1. It seems that people are different. Everyone seems to need some amount of time to think on their own about things, and that need can vary greatly from person to person. For some people, just a bit of time in a meeting is enough. For others, they may need a week and some research. It also depends on the puzzle. So I guess the question is: how much space is appropriate for this group and this puzzle to give people enough time to mature their own ideas?

  2. When people share ideas during the process, they impact each other. That alchemy is part of the magic of sociocracy. As in the selection process, when the change round goes one by one instead of all at once, that alchemy is invited. Similarly in the “policy process” (MVOS page 97) that alchemy is invoked. However, the dose of mutual impact can be titrated with facilitation choices. For instance:
    – How long between phases? (same meeting, different meetings, etc.)
    – Are people given time to think and take notes on their own, before hearing others shares?
    – Who and how is the synthesis done?

Re: First Paragraph

For the the first paragraph, I think @jerry.koch-gonzalez 's response is key: a thorough Understand phase (MVOS page 97) can hopefully prevent acting before the problem is thoroughly understood.

I’ve definitely seen things go completely squirly by skipping that first phase. When the people working on the project aren’t clear on the inputs, the whole thing can go sideways.

Skipping them might seem faster… but it seems it rarely is. There are usually gnarly downstream effects that compensate for any time saved.

However… there are still more layers to the puzzle of design and sociocracy…

More on Design & Sociocracy

Some other things that come to mind are:

1. Design is a special thing!

There are many strategies, and how it works can depend greatly on context and resources.

There are a lot of processes which can be used in a complimentary way with sociocracy, but modifications may be needed depending on the resources available.

Google’s Design Sprints for example are a model that brings a cross functional team together in a concerted “sprint” to accomplish design.

However, if you don’t have a cross functional team with enough free time/resource to run a full “sprint” then this process won’t really work.

Also, that process is tailored to building something truly from the ground up. If resources are limited, it’s frequently the case that a system is making due with limited resources, such as using pre-made building blocks that offer limitations. All of this can impact the facilitation of the process. A multi-day intensive is probably not accessible for anything but a well funded project.

SoFA’s Support Circle adapted this process when it was working on the Membership workflow, and it took forever, and went back the the drawing board exactly as you described from the very end, which was predicted. It was definitely a lesson in range of tolerance for consent for me. Objections are feedback - feedback frequently and early :slight_smile:

Also, design can be iterative. One can design something as prototype, rough and ready, and then re-work it based on on feedback. The Lean Startup model is a pretty sociocratically aligned business development model that focuses on fast feedback to inform design. This is in stark contrast to design processes which put a lot of energy into making the perfect design from the beginning to make them perfect before they are released into the wild. You’ll notice lean startup’s the “build-measure-learn” is kinda similar to “lead-do-measure”, except it’s framed specifically in a design context of producing a thing (which can be built), whereas “lead-do-measure” is more process oriented.

2. Sociocracy’s Proposal Forming Process & Design

I would offer that Sociocracy’s proposal forming process has a lot of potential for design. And it can be applied in different ways to (to positive or negative effect in different ways) emphasize or de-emphasize different parts which can have a significant impact on the outcome and satisfaction with the process.

Specifically, the Understand-Explore-Decide and Lead-Do-Measure concepts discussed in 3.3 of Many Voices One Song.

However, exactly how this same process plays out for systems of different complexity is different. For instance, Workflows, which also use the Lead-Do-Measure model can have very little or very much detail depending on the level of details worthwhile.

The same is true for design. But questions remain: How much time and energy do we have? How much do these details matter? The answer will likely have a significant impact on the facilitation of the process.

In a simple case, it may be that a group could go through all three steps of the “policy process” shown below together:

I have certainly done this with groups for simpler tensions (or “triggers”).

However, that process for more complex systems, or with groups who only have partial understanding of more complex problems doesn’t always work.

Some examples of how you can play with different parts of the process to match the complex needs of the group and the system are:

Partial Outsourcing

Referencing the image above:
Do the first two parts of the understand Phase together as a group, and have someone synthesize the needs and bring them back, then do the first two parts of the explore phase, and have a someone synthesize the proposal and bring it back for the decide phase

This maximizes input, while minimizing group processing time, which may be limited and cumbersome, especially for very complex systems.

This process was recently used in Membership Circle to improve SoFA’s membership systems based on a bundle of tensions.

It has some nice benefits of including much of the group process, but speeding up the synthesizing elements a fair bit.

Outsource to a Helping Circle

On the other hand, helping circles could be used to allow a core group to work on something using the full process.

It may not be possible for larger group to dedicate the amount of time, or they may lack particular expertise, In this case a Helping Circle could be formed to do a more intensive sprint.

One could see the Language Equity Helping Circle has an example of this in SoFA.

Tactfully Skip Group Process in Some Areas

This one is probably used way too often, and is most likely to backfire, but it’s worth mentioning doubly for those reasons.

Rather than doing full rounds to understand context, then full rounds to explore needs, then rounds to synthesize needs, almost always people combine various areas. Kinda like combining Question and Reaction rounds, or doing a popcorn question round. Depending on the context, it’s probably fine to just lump the Understand section all together in a single round and move right on along to the explore phase. Who has time for 6-9 rounds for every decision?

However, in a design process… it’s probably more necessary.

Moreover, it’s also tempting to entirely skip sections of the group process and just give context without doing rounds. This is danger zone IMO.

I’m certainly guilty! It’s so tempting, especially if the working group has limited knowledge of the issue. Still, avoiding this whenever possible, even going through the whole process results in the same original proposal often creates a much greater sense of group cohesion, trust and shared vision and understanding, which is invaluable.

Without that trust, one will probably get confusion and complaints like “designs systems that are too complex” :stuck_out_tongue: And honestly, for relatively complex systems even when not skipping group process… this can still happen that people reject the results or process. Unfortunately Sociocracy doesn’t solve for humanness or physical limitations, it just accommodates humans given their situations it as best as it can, but we are still bound by time and our bodies!


Deary Laine, I appreciate reading you so much. I agree 100% with your temptations haha. Time to think alone and together is so important. I would love to see a culture of taking and giving more time to think in the meetings and between proposals.

On the other hand I love Tom Chi’s concept of Rapid Prototyping and I would love to try it out on the circles we are in. - “Rapid prototyping the discipline of turning conjectures into actuals, they also sometimes call it the discipline of learning the most for the least amount of effort”. Here is a 45 min video in which Tom Chi explains how to do it.

1 Like

I wonder how someone can build complex technical systems without some sort of social infrastructure like sociocracy (or some other methods, there’s a bunch).

There will be people yes that get super-focused on hole-digging or some other practical grind type work, and others that can’t look away from the big picture no matter how hard others try to convince them details have value and someone will have to actually perform labor to get from point A to point B.

@cj.oreilly’s response is closer to my reality - methods like design thinking, lean startup, lean inception etc seem to mesh well with sociocracy, which was how I originally found myself here.

1 Like