Domains: The Basics
Domains are one of the three elements of a role/circle (the others are purpose and accountabilities). We use them to centralize control because, by default, Holacracy gives everyone the authority to take any action or make any decision to fulfill their role/circle’s purpose or accountabilities.
Domains are like a piece of property controlled exclusively by a role/circle. But they needn’t be physical property. They could be things like “the official mailing list,” “the hiring process,” or, “expense reporting and reimbursement standards.”
Domains are great for anything that needs centralized control. Too many people tweaking the website? A domain of “website” might be a good solution. When a role/circle owns a domain it means they can do what they want with it, while others have to ask them for permission.
Impacting Domains
We typically talk about impacting domains rather than controlling or using. We use impacting because it’s more generally applicable to the wide variety of possible domains and how one might interact with them. For instance, what is impacting your neighbor’s car? It’s up to interpretation. Is looking at it impacting? Probably not. How about standing next to it? Ok, how about touching it? Or trying to open the door? Getting in and driving around?
At some point, the impacting threshold has been crossed. Everyone can use their own interpretation and should interpretations be misaligned, then the domain can be furthered clarified in governance. So, in some cases using the domain may be impacting (e.g. using my neighbor’s car), and in others it may not (e.g. using the hiring process owned by another role, which would be just fine).
Owning and Delegating a Domain
If your role owns a domain, then it’s yours to control. No one else can impact your domain without your permission. However, others may request the right to impact the domain, and you need to consider their requests by allowing or withholding permission (and if you deny the request you have to provide a reason why it would cause more harm than good).
If your circle owns a domain, then it’s like family property; any role in the circle may impact it. However, this is only true as long as the domain hasn’t been further delegated down to a specific role. For example, if the Marketing circle had the domain “website,” then any role in the circle could make changes without asking anyone else for permission.
But if the circle had a governance meeting and delegated the website domain to a specific “Webmaster” role, then the Webmaster role would control it. When this happens, the domain is listed on BOTH the Marketing circle (so that those outside the circle will know who controls it) and the Webmaster role (so that those inside the circle will know who controls it).
Note: “Owning” a delegated domain means you have exclusive control over how it is constructed or used, but it doesn’t give you the authority to sell off or destroy any material assets of the company (i.e. You don’t want to hear, “Great news everyone! As Webmaster, I sold our website for a great price!!”).
Defining Policies
Since you have to consider requests to impact a domain you own, you may find it easier to publish policies, which are like rules or stipulations which make it easier for others to know what they can or can’t do within the domain (i.e. “I’ll let you use this thing, but you have to agree to do this…”).
So, imagine the Facilities & Equipment circle has the domain, “company car.” But every time you borrow the car, it’s low on gas. You’d like to expect everyone to fill the car up after they use it, but it doesn’t make sense to capture that as an accountability (what role would you put it on?), so instead, you can propose adding a policy on the circle: “Anyone who uses the company car must return it with a full tank of gas.”
No matter how sophisticated a policy may look (some could be several pages long), they are by definition always connected to a domain. Technically, policies are either 1) grants of authority that allow outsiders to impact the domain, or 2) constraints or limitations on how insiders (i.e. those who already have the authority to impact the domain) may impact it.
If your role owns a domain, then you can publish policies yourself outside of governance since you own it exclusively and there is no one else to integrate with (these can be captured as role notes in Glassfrog). You can read more about policies here.
Implicit Domains
Since the broadest circle (i.e. the GCC or whatever your company calls it) automatically controls everything, it would be ridiculous for it to capture everything in Glassfrog as a domain (e.g. “Company logo,” “procurement process,” “coffee machine,” “coffee filters,” “coffee beans,” etc.). So instead, we think of these as implicit domains. Meaning they don’t need to be called out explicitly in governance because the constitution already says, essentially, “the company owns what it owns.”
This is why you will sometimes see policies listed on the domain, “All Company property & ordinary business affairs.” This means the policy is being placed on an implicit domain, which would be duplicative to call out.
For example, if the policy “Anyone using passwords to secure company-related accounts must ensure those passwords are strong,” was on the GCC, you wouldn’t need to also add the domain, “Company-related Accounts,” because that domain is implied.
Common Domain Mistakes
- Once companies start to understand domains, we sometimes see “A land grab.” Meaning, everyone starts proposing domains for anything they might want control over — rather than proposing them based on real tensions. This is based on a misunderstanding of what domains are and how they work. In this instance, domains are being used to define what the circle cares about when those functions are more accurately captured through an accountability (in this sense, “owning” a domain is misinterpreted to mean the sentiment, “own your work”). Having an unneeded domain doesn’t usually cause immediate harm, except that it encourages the misunderstanding and can artificially add bottlenecks/red tape.
- A variation of the first mistake is that sometimes people propose domains over things no one else outside the circle would have any interest in. For example, an IT circle with domains like, “IT purchasing process,” or “IT tickets.” It’s very unlikely these domains would ever need to be impacted by any role outside the circle (Therefore, it’s unlikely they were based on real tensions). This doesn’t cause harm directly, as there’s no rule against it, but it does encourage a misunderstanding of what domains are and how to use them.
- Proposing policies like, “Anyone may access the domain as long as you ask first,” when in fact, the domain automatically provides that option. Having a domain doesn’t necessarily even prevent others from impacting it, because you still have to consider requests. Having this policy is problematic because it encourages confusion over how domains work. Someone is likely to interpret from this policy that other domains are somehow inaccessible. Remember, domains are useful as a checkpoint, not a roadblock.
- Understanding the scope of authority for domains (and delegated domains) can be confusing at first. Sometimes a domain is captured in governance which is intended to apply to the whole organization, but doesn’t because the domain wasn’t delegated. For example, imagine the Sales Circle is inside the Marketing Circle, which is inside the GCC. The Sales Circle could propose to give itself a domain of, “Website” in the Marketing Circle governance meeting (and let’s imagine that no one in the Marketing Circle objected). But even though that domain is captured in governance it doesn’t apply outside of the Marketing Circle. This is because no one proposed delegating the “family property” (a domain owned by the GCC) to a specific “family member’s property” (a domain of Marketing), so from the GCC perspective and any sibling circles within it, the Website is still family property. It’s as if a child gave their friends permission to drive the family car (i.e. the Marketing Circle gave permission to Sales to control something it itself didn’t control). In these cases, the domain is listed as belonging to a sub-circle or a role, but it only applies within its own family (and not the neighborhood).
Read “Introducing the Holacracy Practitioner Guide” to find more articles.
