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 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.
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).
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!!”).
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.
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.