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 hopefully have a better intuitive sense of what policies are and how to use them.
The Basics
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. So, in essence, a policy is a constraint you must honor when acting.
Domains and policies usually go together. 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. Example: You want to limit what roles can change 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 by 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, downright 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 pass a policy saying, “Neighbors living immediately across the street may also drive our family car.” That is opening up access of an 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 (i.e. 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 policy 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 that someone take action. And here, I am talking about the words of the policy. Meaning, 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 the website, Then you must conform to the style guide. The action comes before as a condition).
Or…
“Anyone who uses a company car must return it with a full tank of gas.” (i.e. If you use a company car, Then you must return it with a full tank. The 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.
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 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 of 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 first ask, “Does this circle control the customer email list?” If not, get the domain delegated, or process the tension through Rep-Links until it gets to the circle with the appropriate scope.
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. To better understand this point philosophically, read “This Time it’s Personal,” and “Policies Governing People” for more concrete guidance.
Watch Out for “Should”
The word “should” doesn’t belong in a policy because policies are official rules, not guidelines one may or may not apply. For example, a policy like, “Everyone should update the equipment ledger when they borrow equipment,” doesn’t actually help very much. Because I’m still responsible for figuring out whether or not that policy applies in any given case.
Instead, policies should be phrased categorically; “Everyone must update the equipment ledger…” because the goal is to get clarity on what is or is not allowed. And if that restriction needs to be changed, you can do so through governance. But until then, it is what it is.
Now, of course, language is always about interpretation. So, there may be ambiguity over what “update” means, or what qualifies as “equipment,” but there shouldn’t be any ambiguity about the nature of the expectation.
What if a Policy is Consistently Violated or Ignored?
Well, then you have a problem. Holacracy doesn’t make this situation any more likely than in any other company (how does any company deal with someone who consistently violates a company policy?), but there are some Holacracy-specific best practices that work.
First, we have to assume all of the normal options have been exhausted. Meaning, the violating party has been educated about the policy and they know they are supposed to follow it. Also, they know they could propose a change to the policy. Knowing all of this, they are still violating a policy and they don’t give a hoot.
Sometimes the solution is already clearly defined in governance, and the problem is enforcement. For example, imagine someone consistently violates the policy: “All travel reimbursement requests must be received within 2 months of expenditure.” In this case, whichever role controls expenses (let’s call it “Finance”) has the full authority to withhold funds if the reimbursement request falls outside of 2 months. The obvious solution would be for Finance to deny the reimbursements and let any affected party process their tensions about it, but if they are uncomfortable enforcing that policy, then the intervention needs to be made with the Finance role first.
Or maybe the organization needs something captured in the employment agreement/partner agreement which is signed when someone joins the organization. For example, “Anyone who consistently and consciously violates a valid policy after having been given sufficient notice, will have their compensation reduced by 20% each week by Payroll Circle until they make an effort to align to the company’s policies.” Something like that. Note: threatening immediate dismissal doesn’t usually work in practice, because few companies are prepared to follow through on that threat.
Another interesting approach shared by Paul Walker at Zappos is to allow the most impacted party to define the penalty. He shared on Holacracy Community of Practice,
We have had this issue for a long time as well, and we tried many approaches to try to convince people to adhere. Alas, between the sheer number of Policies in place (partially because we are a large company) and some Lead Links simply not caring if a Circle Member adheres to a rule that doesn’t affect their Circle, there was little enforcement on any Policies.
So, what we’ve since done is to start adding consequences into the Policy that gives whoever is most affected by it the authority to enforce it. For example, if our Finance department is having Tensions with people not reporting their spending, they can propose a Policy at the GCC that says something like:
“If company money is spent, an expense report must be filed within one month. If this Policy is violated, @Finance has the authority to adjust that Circle’s budget accordingly and/or hold the violating Circle Member accountable in the same way(s) as their own Lead Link could.”
As always, there isn’t one cookie-cutter solution for how to resolve blatant policy-violators, but the options above should give you some ideas.
Read “Introducing the Holacracy Practitioner Guide” to find more articles.
