Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

Spread of domains and/or policies

Hi all, this is how I currently explain what the spread or influence of domains and/or policies are throughout the organization. I always thought this was correct, but recently read some other interpretations. So I'd like to check with you guys, are these statements correct?

If a role or a circle anywhere in the organization has a domain, the domain (and any accompanying policies, if any) applies (or apply) to all roles in all circles of the organization.

If there is a policy in a circle, but the circle does not explicitly has that domain, the policy applies only to all the roles inside the boundaries of that circle (including the roles in all sub-circles of that circle, if any, all the way down).

Thanks for commenting!

Koen

13 Replies
Jean-Michel Gode
05/07/2016

Hi Koen,

Smart statements. Wording sounds really clear.
I've similar interpretations from my perspective.

All the best,
Jean-Michel

Margaux
05/07/2016

Hey Koen,

I agree with statement 2 but not statement 1 and I would add a statement 3:

1/ If a role or a circle anywhere in the organization has a domain, the domain (and any accompanying policies, if any) applies (or apply) to all roles in all circles of the organization.

Part of it is false, if a role in a sub-circle has a domain but the circle itself doesn't have that domain (meaning it hasn't been delegated to the circle), then this role owns the domains only in regards to other roles within the circles, not outside the circle (just like policies in statement 2). You can't control what hasn't been delegated to you.

 

Statement 3 just for fun: If a circle has a domain that hasn't been delegated to a role within that sub-circle, then the Lead Link of that sub-circle can define policies to constraint/authorize how other roles/circles outside this sub-circle can impact that domain.

Hope I am right..

 

Andrea Faré
05/07/2016

I am progressively refining my understanding thanks to these bursts of dialog on the subject, my current understanding follows, but I would not walk on fire  to prove that I am right and I urge anyone to jump in and help me reshape my interpretation into the correct one.

- A 

   - B

      + D

    -  C

let's say we have 4 circles (A is the Anchor, A contains B and C, B contains D)

A Creates a Domain on B  --> Members of B and D can impact it, Members of A and C cannot (unless: they request permission OR B creates a policy to allow them)

NOW: B may delegate that domain further down to any of its directly contained roles (including Circle D), when that happens the other members of B won’t be able to impact the domain without permission anymore. (nothing will be changed for members of A and C)

IF INSTEAD B created the same domain we are talking about on D (but the domain had not previously been delegated to B by A), C would be allowed not to care about it and would be able to act as if the domain didn't even exist.

Extreme example: 

at day 1 the organization has no domains at all. B creates a domain called "partner hiring process" on D, C can still hire partners in the way it prefers and does not need to care. If However A created the "partner hiring process" domain on B  than C would be forced to care about what the domain implies.

Going back to Koen's rules:

 rule 1: would only be valid if the domain was hierarchically delegated from the top as it is or at least if it was the result of consecutive domain subdivisions in the process of delegation starting from the top down to the circle where the domain lives. 

 rule 2: every policy is defined on a domain, if the domain is not mentioned the policy is considered to be applying to default domain of the circle, which is the "set of all activities and functions of the circle" itself.

and here is where I add my little doubt to the "domain hell" ;-) It is my understanding (but again please comment)  that the default domain is by default "not delegated from above",  If it was delegated by default no one would be allowed to enact any accountability of another circle without breaching a domain which contravenes the basic principle of : "go and do what you perceive to be good for the organization until someone complains about it".

I believe this interpretation to  be correct because: art 2.1.1 seems to limit the way in which a default domain should be considered a domain (see the part in bold)

"Further, each Circle may control its own functions and activities, as if a Domain of the Circle, for the purpose of defining Policies that limit the Circle’s Roles."

My interpretation is that the default domain is not to be considered a full fledged domain.

What do you guys think?

Ciao.

Andrea.

 

 

 

Nick Osborne
05/08/2016

Thanks for raising this Koen and for the responses- this is something I've had a query about recently so I'm glad to see this here. If I've understood the conversation so far correctly, then I'd be pleased to hear responses to this slightly different way of articulating it, to see if this is a clear/accurate/simple way of saying it?

Where a domain HAS been delegated to a circle/role, from super-circles all the way from the anchor circle, the domain (and any accompanying policies) applies to ALL roles in all circles of the organization.

Where a domain HAS NOT been delegated to a circle/role, from super-circles all the way from the anchor circle, the domain (and any accompanying policies) applies ONLY with regard to other roles (and of course sub-circles) within the circle, not outside the circle.

Nick Osborne
05/08/2016

And to add to this, I'd like to apply this thinking to the issue of a policy for the 'Auto-accept time limit' for asynchronous Governance proposals. 

If a GCC creates a policy for the auto-accept time limit to be say 5 days, then does this time limit then automatically apply to all sub-circles of the GCC or not? 

According to the above, if a domain of 'Auto-accept time-limit' was created and delegated from the Anchor Circle and a policy for 5 days created, then this would apply to all circles, regardless of which circle the domain and its policy sits in. 

But if this domain isn't delegated in this way, and the policy applies only to the default 'All functions & activities within the Circle' domain, then the policy obviously doesn't apply upwards to super-circles, but there is a question of whether it applies downwards to all sub-circles of the circle its created in? 

This relates to Andrea's question above about whether the default 'All functions and activities within the Circle' is a 'fully-fledged domain' or not, and I'm not sure whether this query I have here is because of a gap in my understanding or a gap in the constitution not providing clarity on this issue? 

So if anyone else has any clarity on this issue then I'd appreciate it as this is a live issue for a client right now, thanks!

Gerald Mitterer
05/09/2016

Hi,

like this profound conversation about nuances of holarchic principles - thanks for all your perspectives and summaries, very helpful!

Here's my additional thoughts:

Where a domain HAS been delegated to a circle/role, from super-circles all the way from the anchor circle, the domain (and any accompanying policies) applies to ALL roles in all circles of the organization.

To my understanding domains and policies are holarchic (and affect all the circles down). Referring to Andrea's point about "the default domain not being considered a full fledged domain" and Nick's example of the Auto-accept time limit I would still interpret a GCC policy relevant for all sub-circles, even without an explicit domain, since it applies to "all activities and functions within the circle". 

I still have a few practical questions: how can a spread of domain show up in Governance? The domain of circle B is visible at the "super-circle boundary" (ie the LL role representing the circle B in the super-circle A). Since the domain must stay visible at the circle boundary you can only grant authority to impact that domain for subcircles via a policy. And: a policy in Circle B that allows impacting a domain of Circle B for Circle D is delegated further downwards to a Sub-Circle of D via processing a change of the policy in Circle B e.g. via Rep Links. I wonder how transparent and easy to capture that is for circle members of D, since the policy is not part of the subcircle's governance but a few circles up. And how do circle members hold themselves well-informed about changes without screening Glassfrog records every morning. For larger org that can become really tricky.

Any thoughts / experiences on that?

- Gerald

Fred Magovern
05/10/2016

+1 on Gerald's remarks re. GlassFrog.

Koen Veltman
05/12/2016

hi all, if I understand this discussion thread well then the meaning of the word Domain and Policy depend on the context, how it is applied in practice. It reads like there are at least 3 valid applications with each their different meaning/implication on how you use it pragmatically in real life. And hence understanding it is relatively complex.

What about differentiating the naming? If the concept is too broad then lets come up with easy to understand different names for each of the applications. Eg create a simple definition for the "Global-domain" (which is delegated out of the anchor circle) and the "Local-domain" (only valid within one circle). Sorry for the non creative new names... Just to give an illustration that with differentiated names for simple applications would make the constitution easier support practice. Not even sure if this example is valid/pragmatic, but just to share a thought on how different naming could reduce complexity.

Hope I made a clear point. Looking forward to read more responses on how to pragmatically apply Domains/Policies. 

Koen (Veltman)

Xavier Boëmare
08/23/2017
Nick Osborne posted:

And to add to this, I'd like to apply this thinking to the issue of a policy for the 'Auto-accept time limit' for asynchronous Governance proposals. 

If a GCC creates a policy for the auto-accept time limit to be say 5 days, then does this time limit then automatically apply to all sub-circles of the GCC or not? 

According to the above, if a domain of 'Auto-accept time-limit' was created and delegated from the Anchor Circle and a policy for 5 days created, then this would apply to all circles, regardless of which circle the domain and its policy sits in. 

But if this domain isn't delegated in this way, and the policy applies only to the default 'All functions & activities within the Circle' domain, then the policy obviously doesn't apply upwards to super-circles, but there is a question of whether it applies downwards to all sub-circles of the circle its created in? 

This relates to Andrea's question above about whether the default 'All functions and activities within the Circle' is a 'fully-fledged domain' or not, and I'm not sure whether this query I have here is because of a gap in my understanding or a gap in the constitution not providing clarity on this issue? 

So if anyone else has any clarity on this issue then I'd appreciate it as this is a live issue for a client right now, thanks!

Hi [@mention:450960215289659578], if the most common interpretation for Policies' scope is that it applies to all sub-circles, it's indeed not very "easy" to read it in the constitution. I actually had the exact same question about the auto-accept time-limit. One year later, did you finally end up with a nice smooth argumentation I could use :-)

Nick Osborne
10/03/2017

[@mention:491495232183315418] no I haven't ended up with a nice smooth argumentation you could use :-(

I interpret it as a consequence of the definition of a sub-circle being a role in the super-circle, so it doesn't need to be written explicitly in the constitution. I understand that things like this aren't explicitly written in the constitution to keep things as brief as possible. 

Sam Burnett
10/04/2017
Koen Veltman posted:

What about differentiating the naming? If the concept is too broad then lets come up with easy to understand different names for each of the applications. Eg create a simple definition for the "Global-domain" (which is delegated out of the anchor circle) and the "Local-domain" (only valid within one circle). S

I came here with this question.  When the anchor circle puts a domain on sub circle A--can that circle delegate it down or can they only  write policies to delegate it down to roles or  circles within the sub circle A and the domain still stays at the boundary of sub circle A?  Is that how we know if it is a "global Domain" vs a "Local domain"--becuase it is explicitly delegated in by the sueper circle?  

 

Artem Serdyuk
10/04/2017

[@mention:456449141667144364] I like the idea of differentiation!

It sounds like we have a case with a domain / policy inheritance, and can use access modifiers from Object-Oriented programming.

So we will have public domain or policy, private domain or policy or protected domain or policy.

What would you say?

Fritz von Allmen
10/09/2017

We've spent quite some time to understand how domains/policies work. My learnings:

1) draw a distinction between Global Domains and Local Domains (thus +1 for a name change, its just not the same instrument)

2) I found it helpful to understand that GCC holds all domains in the beginning (implicitly). If another circle needs/wants a domain, they need to get it from GCC