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

Can I include a condition in a domain ?

Hi,

I'd like to setup a domain only under a specific condition. For instance : "Meeting room XXX in case of Disaster Recovery Plan crisis". Is this a good way to do that ? Or should I create a domain "Meeting room XXX" and a policy "Outside Disaster Recovery Plan crisis, the Meeting room XXX is available to anyone"

8 Replies
Jean-Michel Gode
10/04/2016

Hi Xavier,

From my perspective, the first proposal could be clarified such as "In case of Disaster Recovery Plan crisis, meetings will stand in room XXX". Otherwise the policy sounds like an accountability!

I prefer from far your second proposal. Room XXX becomes clearly a domain, and a policy grant other roles using this room under certain conditions. As I suppose there are some security and reliability issues in the tension behind, this sounds a clear-cut and more consistent option.

Hope that helps,
Jean-Michel

Xavier Boëmare
10/04/2016

Hi Jean-Michel,

Thanks for your reply, however my first proposal was a Domain, not a policy. I guess you read too quickly ! 

In this perspective, does it makes sense the way it is proposed (domain with a condition) ? or should we definitively go with a Policy or a Domain+Policy ?

 

Margaux
10/05/2016

Hi Xavier,

 

It depends on your specific tension but if we take a look at the domain definition in the constitution:

  • 1.1 (b) one or more “Domains”, which are things the Role may exclusively control and regulate as its property, on behalf of the Organization.

 

My interpretation would be that it can only be an entire property, not constraint by any specific situation.

Thus, I would go with your second proposal.

Does it make sense?

 

I don't think you could delegate the domain + define a policy at the circle level (in governance mtg) saying anyone could use it outside of disaster recovery plan because of section 2.1.3

2.1.3 Delegation of Control

When a Circle defines a Domain upon one of its Roles, the Circle’s authority to impact, control, and regulate that Domain is instead delegated to that Role and removed from the Circle.

However, the Circle retains the right to amend or remove that Domain delegation, or to define or modify Policies that further grant or constrain the Role’s authority within the Domain.

By default, any Domains delegated in this way exclude the authority to dispose of the Domain itself or any significant assets within the Domain, or to transfer those assets outside of the Circle, or to significantly limit any rights of the Circle to the Domain. A Circle may delegate these retained authorities as well, by explicitly granting the desired permissions in a Policy of the Circle.

In any case, all Domain delegations are always limited to whatever authority the Circle itself had in the first place.

 

What do you think?

 

Jeff Kreh
10/05/2016

The second optiin feels cleaner. It's "this resource is under this role’s control by default; and unless this role requires this resource for fulfilling its accountability regarding X, any other role in the organization may access this resource for its purposes." Thank you for raising this tension and providing options for solution! 

Karilen Mays
10/05/2016

Xavier: I think you can go either way, as long as the domain is an activity or process that you want to "exclusively" control; I am not sure if that would be a valid domain as written, as I wonder "what is the activity or property you are looking to control".... one time we had a domain which was something like "pricing for services, except private trainings" or something. I don't know that it would be the "best" solution, though perhaps that is all the clarity you have. And if no one objects, it could serve as a valid domain.

In either case, the role w/ a domain must create policies or allow others to impact that. So I would try to stay focused on the tension, and if you know what / how you want to constrain something you can try a circle policy to start, or a role domain and let the role figure it out.

Try not to address all the related tensions, and it can inform if you want a role domain or a circle policy. 

Sometimes there is no clear answer, and you just need to try something.

Xavier Boëmare
10/10/2016

Hi,

Sorry for my late reply. Thanks everyone for your inputs !

 

[@mention:449974511452179429] Interesting the approach of a domain as an activity/process. Might not be easy in this specific case, but I have to think about it.

[@mention:449693036337664795] I'm afraid I missed you point on 2.1.3 : "the Circle retains the right [...] to define [...] Policies that further grant or constrain the Role’s authority within the Domain" => my understanding is that I can have a role with a domain, and a policy at the circle level which constrains the role authority over that domain. So I imagine a domain "Room xxx" on a role and a policy at the circle level allowing use of this room outside "DRP events" would do. What do you think ?

Kevin
10/12/2016

Xavier,

I think I interpret 2.1.3 the same way you do with regard to a Domain + Policy situation.  The key sentence to me is this one:

However, the Circle retains the right to amend or remove that Domain delegation, or to define or modify Policies that further grant or constrain the Role’s authority within the Domain.

So you can distribute exclusive control over property (a Domain) except as defined by a policy.  That usually strikes me as a clean solution to this issue.

Kevin

Margaux
10/14/2016

Xavier,

 

“[@mention:449693036337664795] I'm afraid I missed you point on 2.1.3 : "the Circle retains the right [...] to define [...] Policies that further grant or constrain the Role’s authority within the Domain" => my understanding is that I can have a role with a domain, and a policy at the circle level which constrains the role authority over that domain. So I imagine a domain "Room xxx" on a role and a policy at the circle level allowing use of this room outside "DRP events" would do. What do you think ?“

My interpretation is that you can delegate a domain and have a policy saying that other roles can impact that domain within certain conditions (2.1.3) but it would be weird to give the property to someone and then allow others to have impact on it...