Holacracy: Policies vs. Domains. Why do we typically push for policies?

When in Governance, circles typically spend a lot of time and energy focusing on Roles, specifically on their Purposes, Names, and Accountabilities. Some groups spend a smaller amount of time on Policies, but most circles rarely spend time talking about Domains. Why is that? After all, when you’re creating a Role, the slot to add a Domain is right there under the name and purpose. Well, if you’ve ever been through Holacracy Practitioner Training or had coaching from most HolacracyOne® consultants, you’ll likely have gotten the vibe that we kinda… avoid those. Much like taking a handful of mints when leaving a restaurant, it’s not against the rules per say, it’s just frowned upon.

But why?

Well, some of this confusion may arise from the fact that HolacracyOne® doesn’t really go to great lengths to provide insight anywhere outside the Practitioner Training. Even the Holacracy Constitution calls out how one gains authority over a Domain, but it doesn’t actually define what that is. There is one spot, however, that you can easily find the definition of a Domain- in the handy-dandy help bubbles in GlassFrog. Here’s what it looks like:

To boil that down, just look at the first sentence: “Asset or activity owned and controlled by this circle” (Note: This would also apply to a role-level Domain). So, in it’s simplest form you can think of a Domain as a noun. It’s an “ownable” thing, which could range from physical objects, like employee desks, to something intangible like “the Holiday Party.” By establishing a Domain on a particular piece of “property” you are essentially putting a fence around it at whichever level it takes effect (circle or role). You’ve made a statement that if anyone across the entire organization wants access to your property, they need to go through your role/circle. Now, before I go further, I want to call out that this article isn’t going to talk about how to procure a Domain (Believe it or not, it isn’t as easy as simply calling “Dibs!!”). That’s a conversation for another day. The focus of this article is why you may or may not want to use a Domain, and when a well-crafted Policy may get even better results.

So far, Domains sound like a pretty useful tool, right? They certainly can be! So, what’s the downside of a Domain? Well… there are actually a few. First, a domain can create unnecessary friction where none needs to exist. For example, let’s say that Company XYZ has a Product Manager role for the Website circle. This role’s purpose is, “A cohesive, customer-focused website.” To achieve that end, Lisa (the role-holder) comes to Governance and adds a domain of “The Website” to the Product Manager Role. She does this to ensure that all changes are indeed cohesive and customer-focused, thus helping her achieve the role’s purpose. However, the next week she begins receiving emails from people across the organization that now need her permission to make routine changes to the website- things like new product uploads to surface in search results, small bug fixes, or recent blog articles to upload. The intent of the domain was really to ensure the PM was able to maintain a consistent look and feel of the site, but in the process it ended up handcuffing several roles that wouldn’t even affect the site’s look & feel.

Additionally, what tends to happen when people start listing Domains is that other roles and circles feel the need to follow suit, and a sort of “land grab” ensues. Holacracy is intended to be a tension-driven system, meaning that it’s not actually engineered to minimize risk through anticipation or fear. It’s built to optimize for innovation and iteration, and operates best when people have the freedom to sense needs and respond to the environment around them. That’s part of what keeps it so agile. When people start creating unnecessary layers of complexity through claiming domains that don’t truly cause harm if left unclaimed, the system becomes increasingly heavy and less nimble, crippling one of Holacracy’s biggest strengths.

Finally, Domains have the potential to transform the empowering, “You have the authority!” spirit of Holacracy to a depressingly familiar one of, “Ask permission first!” When we start drawing lines in the sand unnecessarily, we can begin to (wittingly or unwittingly) re-establish a traditional hierarchy, politicizing the workplace. This is counterproductive to the environment Holacracy is typically brought in to help create.

So, is there an alternative? Good news! You’ve got options. A quick fix that still uses a Domain is to simply redefine it from its current, broad definition to something a bit more focused. You could also use a hybrid approach, keeping the Domain intact but adding a policy that grants permission in certain cases (like, “Roles in the Content, Engineering, and Merchandising circles are allowed access to this Domain without getting permission). Or, to make it nice and easy, our Product Manager could craft a Policy by itself.

In the Holacracy Constitution, a Policy is described as, “either grants of authority that allow others to control or cause a material impact within a Domain, or limits on how others may do so when otherwise authorized.” The first half of that statement is basically what I referred to as the hybrid approach in the previous paragraph. For now though, let’s focus on the second half of that statement: limits on how others may do so when otherwise authorized. This passage is referring to placing a limit on an action that is, by default, allowable. Still a bit fuzzy? It helps me to picture a standard policy as an If/Then-type statement (“if you want to do that, you need to do this first”).

Let’s look at the example we mentioned earlier with our Product Manager, Lisa. If Lisa’s chief concern is maintaining a consistent look and feel of the site, then she might craft a Policy like, “If making changes to the color scheme, fonts, or layouts of the homepage or global website settings, you must first contact the Product Manager for approval.” This allows our kings & queens of content keep cranking out blog articles, our engineers to keep exterminating site bugs, and our merchandisers to continue updating the product catalogue without getting approval from the Product Manager while still putting a safety measure in place for people making changes with serious implications across the business.

As is the case with a lot of things in Holacracy, there are multiple ways to solve a tension. Much of the time, you can make a Policy that would achieve what a Domain aims to accomplish, and visa versa. To me, it boils down to the use case and the intent.

Here are some questions to ask yourself before deciding which makes the most sense in Governance:

1: Is there actually enough access to the property to necessitate a Domain?

Looking at the PM example- how many people actually have permissions to access the website codebase and deploy changes? Who are you most concerned with causing the damage to your Domain? Do they have the practical capability to even access your Domain? If not, you may not need to craft any Governance around this at all. If you’d feel safer with something officially captured, however, a Policy would likely do the trick.

2: How far-reaching is your Domain?

A lot of times (like in the PM example) we underestimate the true scope of our Domains. The more focused you can make your Domain, the easier it will be to enforce, and the more likely it will be to minimize “collateral restriction.”

3: Does this keep happening, or was this just a one-time occurrence?

In organizations, we have a tendency to overreact to negative outcomes. It’s in our nature. We want to protect ourselves and those around us, so when something bad happens we do all that we can to make sure it never happens again. Unfortunately, a rash reaction is rarely the most effective solution. If >90% of the time things have gone fine without this proposed governance, perhaps it makes more sense to craft a Policy around the specific use case that led up to the <10% problems rather than assuming that the whole system is broken and building a wall around your property.

4: What message am I sending by crafting this proposal?

This is a great question to ask when thinking about most elements of Governance, but especially Policies and Domains. To me, a Policy tends to convey more trust in an organization than a Domain. Policies typically imply, “We trust you in most cases, but in this one instance, we just need to double check things.” A Domain, on the other hand — at least in my mind — implies, “Don’t even think about touching this. We only trust a select few to actually understand this.” Now, what you may be trying to convey is that this piece of property is so important that you can’t afford to have even minor mistakes when engaging it. That’s completely valid and a Domain probably is your best option in a case like that (think things like “Contracts” as a Domain for your Legal circle). Unfortunately, what I’ve found is that there’s a tendency for people to claim that importance/fragility is the reason for their Domain, when in reality it’s more about a lack of trust or a need to be in control.
(HINT: Even if it’s truly about fragility of the property, Domains will likely come across as a power grab/lack of trust/disempowering to employees unless it’s really obvious, like the Legal & Contracts example. So, make sure you’re over-communicating your reasons if you’re at all worried about that perception)

I guess what I’m trying to say is to be thoughtful in your Governance. Sense and respond to your environment, but temper the urge to overreact and “stake your claim” in the organization. Your coworkers and your customers will thank you for the resulting lack of complexity.

What about you? What has your experience been like with Domains and Policies? Share your thoughts!