Policy & Operations

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.

Introduction

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.
Exit with
⌘↩
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
.
(*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.

Decision-Making

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.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.