Domains are one of the three elements of a role/circle (the others are purpose and accountabilities). You can use them to centralize control. By default, everyone in a self-managed organization has the authority to take any action or make any decision to fulfil 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 customer mail list,” “the hiring process".
Domains are great for anything that needs centralized control. Too many people tweaking the website's design? A domain of “website” might be created. 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.
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 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 delegated the domain to a specific role, then the role would control it.
Since the anchor circle (the broadest) automatically controls everything, it would be ridiculous for it to capture everything in Holaspirit as a domain (e.g. “Company logo,” “procurement process,” “sales process,” 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 functions and activities within the circle.” This means the policy is being placed on an implicit domain, which would be duplicative to call out.
For example, if the policy “Anyone coming to the on site premise must use a security badge,” was on the anchor circle, you wouldn’t need to also add the domain, “Premise security,” because that domain is implied.
Once a Role/Circle owns a domain, the Role/Circle can 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 work on the website, but you have to agree to do this…”).
Technically, policies can either grant of authority that allow people outside the circle/role to impact the domain, or constraints or limitations on how people inside the circle/role (i.e. those who already have the authority to impact the domain) may impact it.