Summary: Collaborative decision-making can be fast and efficient if we have clear guidelines what decisions are made by groups, and what decisions can simply made by a designated person in a role.
The guideline in sociocracy is that consent decisions are made by group and establish general rules. By defining and approving those basic guidelines, workflows and roles together, we establish the basic framework in which people in roles can be empowered to make decisions alone. The combination of the defined framework and empowered individuals, together with appropriate feedback and advice mechanisms, makes self-management flexible, clear and fast. How much a group wants to define as a general rule and how much will be decided on a case-by-case basis will determine how lean or structured an organization will operate.
Every day, there are decisions to make. When we’re working with others, then the decisions we make impact other people and their work. Organizational governance is all about how we can make decisions in an organization so that all of our operations run smoothly.
In hierarchical organizations, decisions are made at the top and carried out further down in the chain of command. By contract, in extremely flat organizations, “everyone is empowered to make decisions about anything.”
This article shows how systems of self-management with domains and shared agreements can avoid power-over hierarchy and offer more structure as well as efficiency to flat organizations.
This article is relevant for you if
- you like the idea of flat organizations, but they seem unrealistic, inefficient, and chaotic to you.
- you have worked in a hierarchy, and you’re looking for ways to loosen the top-down structures.
- you have dipped your toes into sociocracy, gathered some experience, and are ready for a more advanced understanding.
A simple trick
Sometimes people hear about self-management structures like sociocracy and Holacracy and say, “oh my, it sounds tedious to decide things together all the time! When are we going to get work done?!”
Yes, it would be tedious and painstakingly slow to make all decisions together! That’s why we don’t do that.
So how can we define what decisions we make together? And how do we define the decisions we make alone? To answer that, we need to understand the difference between decisions and policy decisions.
- Operational decisions apply once. They typically get decided alone. (Operations are the tasks that we do)
- Policy/governance decisions set a general rule. They get decided by a group (circle).
Often, new learners have a hard time grasping the difference. But in everyday life, those concepts are familiar so it’s easy to draw from that understanding. For example, if my daughter asks me, “can I stay out until midnight tonight?” and I say yes, then we’re both clear that I did not give permission to stay out until midnight next week. It was an operational decision that applied only to that evening.
By contrast, we make a policy decision if we set a general rule that on weekday evenings, my daughter has to be home by 10; that rule now stays in effect until we change it. (We might make exceptions from our own rule, but we’d need to talk about those exceptions.) So if we make a decision about one time, it’s an operational decision. If we make a general rule, it’s policy.
Let’s translate these concepts into organizational life.
Policy and operations in organizations
Organizations are typically more complex than the relationship between a parent and their child. While in a small group, we can talk about everything with everyone, that’s impossible with a larger group. We need to break things into smaller authority chunks that we call domains.
A domain can be held by one person or by a group of people that decide together in that domain. Those who hold a domain make all decisions in that domain. For example, a Membership Circle makes (final) policy decisions on membership, a Sales Circle sets the frame on how sales happen. You can read more about domains with more examples here.
(*Geeky comment: Domains are high-level policy decisions: a general decision on what decisions are made where. Instead of deciding each time who decides what, we “pre-structure” the space and make a general decision formulated as a domain. So while we look at domains separately, they’re just policy. In the same way, the constitution is only a policy.)
A web of clarity
Once we have clarity over who decides what, we can build agreements to structure our operations.
The metaphor I want to use here is traffic control. Let’s say a circle is only focused on road traffic (not air or trains). Imagine a city where traffic flows all the time. Let’s say there are no rules, just streets. In the absence of rules, every driver has to make operational decisions with others all the time. You get to an intersection and need to figure out who crosses first. That would be highly flexible but also highly inefficient.
By contrast, a policy decision is like installing a traffic light, speed bumps, or issuing a speed limit that establishes the same rule for all traffic. The intention of policy decisions is to build a set of basic agreements so people can operate without having to negotiate at each intersection.
- Policy decisions can make things faster and more reliable. If we have a defined understanding of how we do things, we can get to work instead of talking about it again and again.
- Policy decisions also help us deliver higher quality and be consistent because the same rules apply to everything. (An example would be a style guide or safety protocols.)
Policies and worker power
In a state, the Department Of Transportation makes the traffic rules. In a self-managed organization, the people who are engaged in the work make policies. For example, a Blog Content Producers Circle – the circle that makes policy on how blog content is written and published – should consist of content producers and others involved in blog content publishing.
If workers make policy decisions in their domain, it flips the power structure on its head. The policies don’t come from the outside (or top); they come from the inside. We decide for ourselves what constraints we want to define so we all can do better work. The same Blog Content Producers Circle will make better policies and be more accountable to policies that they craft with each other and for each other.
Now that we know all that, we can talk about decision-making. Here’s a helpful difference;
- Policy decisions are made by consent.
Every circle member needs to give their consent to the proposal. We make those decisions together so those directly involved can check whether a policy decision is good enough.
- Operational decisions are made by whoever is authorized.
Most commonly, the authorized person will be in a defined role. For example, if there’s a robust membership policy, all we need to do is apply our policy and see if a given new applicant fits our frame. Ideally, someone in an operational role (e.g., Membership Coordinator) takes care of the tasks in alignment with the relevant policies.
That said, a defined role isn’t always necessary. For example, if there’s a clear Dishwashing policy (e.g., what needs to be sanitized how), then everyone who does dishes can simply follow that policy and determine that way what’s good enough.
In practice, operational decisions are sometimes made by consent if it is a high-stakes decision or if a lot of variables around it are undefined.
When to make policy decisions
Having a policy takes resources. For example:
- Time to craft and approve the policy
- Storing the policy where everyone can access it
- Reviewing the policy on a regular basis (and a system to remember to do that)
- Holding people accountable to the policy (including making it part of onboarding)
Yet, putting in the effort can be worth it. The benefits of a policy are (depending on context):
- Keeping things consistent (which can also mean fair, better quality, more aligned; often)
- Clarification (which can also mean settling a recurring or smoldering conflict)
- Making it easier to improve and iterate. (Once a policy is written down, it’s much easier to review and tweak than something vague and undefined.)
Therefore only make policies if
- the operations are recurring and frequent enough, or
- the operations are very high stakes (e.g., safety)
This becomes quite obvious looking back at traffic management. We would not install a traffic light for a road where there’s only one car a day. But we might install a traffic light for a road crossing train tracks even if there are only five trains a day. (That’s just common sense, and yet, some groups spend a lot of time on policies or guidelines they will never use.)
In organizations, roles are an excellent example of the difference between policy and operations.
Let’s say a circle has a question for the town office. We simply assign someone to perform the task – that’s a simple operational decision. But if we expect to have ongoing or recurring contact with the town, it might make sense to define a point person – a policy decision.
It’s quite common to go from operational decisions to policy decisions (and then more refined policy decisions) over time, as they keep coming up. In the beginning, we might not know what policies we even need, so that everything might be operational decisions. Once we notice which operational decisions come up frequently, it’s time for policy to save time. A lean way of doing governance only builds structure where it’s needed and when it’s needed.
Different kinds of policy
There are different kinds of policy decisions.
|Kind of policy||Examples|
What is allowed, what isn’t?
|A membership policy that defines what the rights and responsibilities are of specific membership categories A compensation policy that defines criteria and remuneration tiers.|
What are the steps to do X?
|A workflow that lays out how to get reimbursed for travel expensesA workflow that defines the off-boarding of a member.|
Who does what?
|Content partnership coordinator (= defining that for all content partnerships, this person is the point person)Training schedulers (= defining that this person takes care of scheduling for all training offerings)|
Roles and the operational decisions their holders make are a key to speeding things up. We don’t have to talk about everything anymore. The circle defines the role once and then only hears a quick report from the role holder from time to time. Maybe the role holder asks for feedback or brings a policy question to the circle if there is something that needs to be addressed. But mostly, they’re just taking care of things and we can all just get back to work. This equates to the difference between one task and a role, which is ongoing and also typically a bigger cluster of tasks.
Each of these kinds of policies has operational decisions as counterparts. To illustrate the difference again, let’s contrast different scenarios:
|Operational decision:||Policy decision:|
|What is allowed, what isn’t?||Can Scilla have her private birthday party in the community room next week?||In general, can members use the community room for private parties?|
|What are the steps to do X?||How should we go about approving and publishing this article this time?||Workflow defining the steps of approving and publishing an article on the blog|
|Who does what?||Task: Who will call the town office before our next meeting to ask this question?||Role: Who will serve as point person to the town office for this coming year/in this project?|
The same is true on a process level, by the way, when the decision affects how we run our circle, not how we do our work.
|Operational decision:||Policy decision:|
|What is allowed, what isn’t?||Is Jeff allowed access the notes of the meeting he is observing next week? |
How do we make this decision?
|Are our circle notes open to people from outside of the organization?|
What’s our default decision-making method?
|What are the steps to do X?||Could XY be on our next agenda?||How do we plan our agendas, and how do we prioritize agenda items?|
|Who does what?||Who facilitates today’s meeting? Who is taking notes today?||What kinds of roles do we have, what do they entail, and who serves in them for this term?|
Working with feedback
Before a decision is made, and while it’s in effect, feedback is useful on operational and on policy decisions. How intentional we will be in gathering feedback will depend on the scope of the decision. If a circle/role makes decisions, they will get feedback as they see fit to make a good decision. (Some people call this the advice process; in sociocracy, it’s already part of the distinction between decision-making and feedback, and the general expectation to get appropriate feedback before making a decision.)
We might change existing decisions. Thinking back to the traffic metaphor, let’s imagine a 120 km/h zone where a lot of accidents happen. If we notice that, we might decide to turn it into a 90 km/h zone or take other measures that will address the issue.
In the same way, we need to pay attention to whether our policies are working. To make sure we remember to evaluate our policies, they always come with a term that triggers an evaluation date so the policy can be reviewed.
- Sometimes the policy is still good, then we just approve it with a new term.
- Sometimes we notice we haven’t actually been following policy and then we either re-phrase the policy to capture our actual practice, or we hold ourselves more accountable to our own agreements.
- Sometimes we realize a policy wasn’t good enough. Then we improve it until we can approve it with a new term.
Want to read more about intentional feedback in organizations? Check out this article by Ted Rau.
Short time frames
Sometimes we make policy decisions for a very short period, in particular when we want a short feedback cycle. For example, a circle I am in just recently made a book translation workflow decision with a term of 1x use of the workflow. Is this an operational decision because it only applies to one instance? Although it looks like one, the way it’s worded is as a policy – “every time we translate a book…” so while we might review it after one instance, the intention is to use it beyond that in a potentially reviewed form.
An interesting topic is what happens if separate, individual operational decisions form a pattern: this decision here and that decision there, or somewhat unintentionally making similar choices again and again. I call those practices or habits. Those aren’t bad – we don’t want to sit down and write a workflow for everything we do. If something is working without being written down, great! For example, we don’t want to make a policy on when/how people take their lunch break if their lunch behavior doesn’t create any issues.
There are a few tricky things about practices though. Practices can be hard to acquire for new members because they might be taken for granted. They can also be unhealthy, and often, they’re unacknowledged. For example, if we make 5 hiring decisions independently of each other but they’re all male hires, this might be a coincidence, or it might be a pattern.
When we observe a pattern, we can talk about it and see whether we think there’s something deeper going on that we want to do something about.
Let’s look at an example. We had a situation once of two circles. One circle was only men and the other circle was only women.
- We could give feedback and let both circles know what we observed. We’d need to trust that they will do with the feedback whatever they do with it.
- We could make an operational decision, for example, that the next addition to the circle has to be of another gender. This would be a one-time decision only applying to that one next member.
- We could make a policy decision, for example, that every circle has to have at least ⅓ of any gender and start to enforce it.
Each of those decisions is a valid decision, and it depends on the context.
Being in choice
For every decision, a circle will have the choice – do we build more structure, or do we stay vague? A mix of operational and policy decisions over time will turn the dial a little bit towards more structure, or towards less structure. Neither is right or wrong – it’s about finding a healthy range.
Let’s look at an example again. Here’s how an organization might regulate purchasing decisions:
- Organization A: everyone can spend money. Whether someone wants to buy an airplane ticket or a new computer or a new hire, it’s allowed. Every member of the organization has a company credit card. People might get feedback before making a purchase but there’s no rule on that.
- Organization B: There’s a detailed ruleset on what purchases are allowed (agreements). Only very few people (roles) can make spending decisions, and there are workflows that define how spending decisions are made.
For each topic, we can decide how much we define and structure, and each organization will answer it a bit differently, and it might change over time. We can notice whether we’re in a healthy range.
If there are too many operational decisions, but not enough policy decisions:
- many moving parts; items are dropped; and/or people get anxious
- leaders are expected to make a lot of decisions because there’s not enough structure to cover making them elsewhere
- team members experience decision fatigue
- inaction because of not enough clarity and predictability
- people keep asking for the bigger frame/rules/strategy.
If we’re leaning too much towards policy decisions and overuse policy as a tool:
- lots of time discussing policies we rarely use or on marginal issues
- we base policies on a thin base of experience
- we make policies but don’t stick to them
- people feel stifled and try to find ways around the policies
- There is flow because we have enough boundaries to guide our operations but few enough rules not to inhibit them.
- People feel good about having a choice but they also feel safely held within a web of clarity.
It’s not efficient to be all about rules. But it’s also not efficient to never make rules.
Before solving a problem, ask yourself how significant the problem is. Policy is an excellent solution but not the only one. For example, we might notice that we already have a solution, and we just need to enforce it.
- We can choose to let it be.
- If there is an existing policy, we decide to enforce it.
- We can give feedback.
- Or we can make an operational decision.
- Or we can make policy.
You don’t want an organization that is like car traffic with zero rules and lots of need to talk. But you also don’t want an organization where everyone is like a cog in a big machine. Find balance – the trick is to know both and use them as needed, and adjust the ratio as needed.