Holacracy® Basics: Understanding Policies
Holacracy Practitioner’s Guide
Of the three basic governance constructs (accountabilities, domains, and policies), policies are by far the most misunderstood. Is a policy a process? Is it a corporate policy, like the dress code? Neither of those is exactly right, and after reading this you’ll have a better intuitive sense of what policies actually are and how to use them.
Technically speaking, policies grant or limit access to something already controlled by a role/circle (i.e. a domain). Since domains give exclusive control, policies are needed to further refine who and/or how someone may impact a domain.
Domains and policies always go together. Always. So, to really understand policies, first you need to understand domains — what they are and how they work (read this post on domains if you haven’t already).
So, a useful way to think about policies is to start by thinking about what your role/circle controls. You can’t govern what you don’t control. For instance, if you want a policy around what roles are authorized to add pages to the website, your first question should be “Does my role control the website?”
What Policies Can Do
- Give access to a domain or something otherwise exclusively controlled by the circle. This includes specifying conditions that need to be followed to access the domain. (e.g., “Everybody can post to the Facebook company account as long as they sign with their own name”).
- Limit access to something owned by the circle or role. It can go from simply specifying a certain way of using an asset (e.g., “Every role creating a company account with a third-party service must use a strong password with at least 8 characters”).
- Define a specific process for doing something within the circle (e.g., “All projects must be tracked in GlassFrog”).
- Or, down right forbidding an activity (e.g. “No role other than Finance is authorized to share the company’s financial data.”)
Defining Who and What (Opening or Restricting)
If a role outside the circle consistently wants to impact the domain, then a policy can be adopted inside the circle to open-up access. You cannot drive your neighbor’s car without permission, but imagine your neighbor could also pass a policy saying, “Neighbors living immediately across the street may also drive our family car.” That is opening up access of a owned domain to someone outside of the family (it should go without saying, but a real neighbor like this is both generous and imaginary).
On the other hand, a policy may further restrict a domain within the group that owns it. Your neighbors may further restrict who in their family can drive the car (e.g. “Anyone in the family may drive the car except the baby”). Because the domain is family-owned, anyone in the family may use it by default, but it may make sense to exclude some family members.
Defining How (If-Then Statements)
Sometimes just defining who can or can’t impact the domain isn’t enough. Often a policy needs to say more. So, It can further specify what one must do to have the right to impact the domain. These policies work like If-Then statements. Here’s a policy from HolacracyOne:
“Anyone using passwords to secure company-related accounts with access to company assets or sensitive data must ensure those passwords are strong, not duplicated on any other system, not stored anywhere except a highly protected repository, and may not share the actual password text with anyone else.”
In this example, you can see the If-Then structure. If you are using passwords to secure, yada yada yada, then you must ensure those passwords are strong, etc. etc. etc.
Most policies are built upon this If-Then structure, so look for it, or use it yourself when proposing governance (i.e. “How can I phrase this like an If-Then statement?”).
Policies Can’t Require Action
Policies only apply when someone wants to impact a domain, so the policy cannot mandate someone take action. And here, I am talking about the words of the policy. For example, it would be invalid for a policy to say, “Marketing will publish a quarterly newsletter,” because literally, that is requiring action (i.e. “Marketing will publish…).
In practice, policies that “require action” should get objected to as Not Valid Governance Output (NVGO), because (and feel free to use this) “The Constitution defines a policy as a limit or grant of authority to impact a domain, and in my interpretation, this policy doesn’t meet that definition.” If someone really does want someone to consider taking an ongoing action, use an accountability instead.
So, a policy can’t require action in a vacuum, but a policy can require action either before as a condition of impacting a domain, or after as a consequence of having impacted it.
Again, I’ll use the If-Then structure to illustrate: “Anyone who wishes to update the website must conform to the style guide published by Marketing.” (i.e. If you want to update website, Then you must conform to the style guide. Action comes before as a condition).
“Anyone who uses a company car, must return it with a full tank of gas.” (i.e. If who uses a company car, Then you must return it. Action comes after as a consequence).
So, another way of saying “policies can’t require action,” is to say, “policies must allow for conscious choice-making.” A policy like “If you breathe air, then you must submit your timesheet on Thursdays,” would be invalid, because I can’t control whether or not I breathe air.
Similarly a policy like, “Any role that gets an email request from a customer must submit it to customer service,” would also be invalid on the grounds that I don’t have control over whether or not I get contacted by someone else.
Adopting Policies on Delegated Domains
Domains can be delegated down of course. As when the GCC delegates the domain of “Marketing Newsletter” down to the Marketing sub-circle. At which point roles in the GCC are no longer have the authority to impact the newsletter without Marketing Circle permission (unless the governance is changed).
Constitution section 2.1.3 says, “However, the Circle retains the right to amend or remove that Domain delegation, or to define or modify Policies that further grant or constrain the Role’s authority within the Domain.”
Meaning, the GCC could still pass a policy related to the “Marketing Newsletter” domain even though the domain remains the property of the Marketing sub-circle. Like if a parent required a child to wear a helmet when riding their new bike (i.e. New Bike = domain on child sub-circle; Child = domain owner; Parent = GCC/super-circle; Policy = If Child wants to ride bike, then she must be wearing a helmet).
Policies Can’t Control Something the Organization Doesn’t Own
The organization can only govern what it owns as its property (i.e. its domains, assets, etc.). This is also true for a circle.
Since policies are always connected to a domain or something otherwise controlled by the circle (sometimes I call them an “implicit domain”), you can only adopt a policy on what you already own. For example, if you want a policy around what roles are authorized to update the customer email list, you should ask, “Does this circle control the customer email list?”
Additionally, policies related to hours of operation, or other expectations of the people which are typically captured in an employee handbook are usually not valid policies because the organization doesn’t own or control the people, it only controls the roles. For more on this, read “Policies Governing People.”