[dropcap]Q[/dropcap] We are beginning an interesting experiment in governing an international on-line peer support community using Sociocracy. How should we define the circle meeting officer’s roles?
The more fundamental questions are What does support mean? and What will the circle be governing?
The Sociocratic Circle-Organization Method, as distinct from sociocracy as a social philosophy, is that it is designed to organize a group of people with a shared purpose to complete specific actions that enable them to achieve that purpose. In other words, the officers, the meeting process, etc, are designed to maintain a system of communications and control over operations—to make decisions that will guide the organization in effective action. Without operations, the meetings have no purpose. So what are the operations?
The use of rounds to structure discussion and debate, is a good technique even when it is not directed toward a decision. With each person in the meeting speaking in turn, a facilitator is important to unobtrusively keep the process focused and moving. When people are not sitting in a circle, the facilitator also indicates who should speak next.
But trying to figure out what officers will do can go awry when a group is trying to practice a method of organization and leadership when it has no operations. Practicing a technique isn’t a meaningful subject for a circle meeting on an ongoing basis. For a class, yes. A lecture, yes. But in that case, the teacher or teacher is the focus and it isn’t a group of equals making decisions together. It is a group of people learning or being guided in learning a subject from an expert. (I realize there are pedagogical theories about classes proceeding as equals but they are limited to certain uses.)
In a practice session, when there are no options to agonize over and no desired outcome to measure, the process will not transfer easily to a real-life situation. Real-Life situations have thorns and engage people in conflict. They require consent to choosing between imperfect options with personal and financial risks.
So what I’m suggesting is “support” as a purpose must have a defined a vision, a mission, and an aim that can be measured in order for the members to become a group and be self-sustaining. The group members might decide in a circle meeting how to research the meanings and techniques for providing support. What does support mean? How do various groups provide it?
Specific tasks could be assigned, the actions to be completed before the next meeting. The measurement might be consent to a statement of the group’s purpose with tangible aims that can be measured within two or three meetings.
An aim can be intellectual as well as physical. The aim for a support group might be as simple as a forum for asking questions and giving feedback on experiences. A tangible measurement in this instance, might be whether the members find the meetings useful and continue to attend. Other groups might want a more tangible result— measurable movement toward adoption and implementation of sociocracy in a defined context.
Discovering and Developing a Purpose
Some of the knowledge needed to define the purpose will come from experience. It doesn’t mean the group can’t do anything until this statement is clear. I was confused for years about writing a business plan because the plan kept changing. Paul Hawken clarified this for me in Growing a Business: The value of writing a business plan is the research and thinking that goes into writing it. As soon as it is completed, it will be out of date.
I don’t think a purpose statement will be out of date the day it is completed but it’s a development process, although changes may become less frequent over time. A purpose firms up in stages.
As I understand it, agile software development has adopted the view that you define the aim well enough to get started with meaningful action. Produce a workable (partial) solution as soon as possible. This is in contrast to the previous practice of designing perfect systems and implementing them as a completed project. My experience with the old method was that it was largely ineffective and unjustifiably expensive. It was impossible to predict all needs at the end of the long period of time it took to write the software. It was even impossible to answer all the questions the designer wanted answered before they would lift a finger.
So I’m suggesting you both define support in terms of a tangible aim and begin working toward it in order to further define, implement, and measure effectiveness. Define your officer roles as you go. Don’t try to do them first. You don’t know what you need them to do.