Hi Anne,

I would think that in most cases a role that is responsible for X would already include an accountability that X meet a certain standard. Approving other changes seems implicit in that accountability to me, especially as the person holding the role would presumably want to approve changes made by others. However, I suppose if such an accountability is not clearly implicit in the current role description, or if there is any kind of tension around the task, then it makes sense to add it. 
I'm kind of wondering what would trigger this question. Is the person holding the role not making approving changes a priority, creating a backlog? Does that person perhaps feel that such supervision and approval is extra work that is not included in their compensation package or that is interfering with their other priorities? Is someone else trying to do these tasks without having the clear authority to do them?
As always, my guess is that things need to be added only as they are needed to resolve a tension, not to try to meet some idealized standard of perfect role description.
I'm curious to know how others see this. 

> Example: "Any role who wants to make changes to training slides, must first ask approval from Training Design role"

To me this reads like the very definition of a domain, only packaged as a policy.

In general, domains should be used with caution (and only created based on concrete tensions /examples), but in this case, "Training Slides" as a domain on the Training Design role would make more sense to me than this policy. Clearer this way, in my opinion. ( A domain also clarifies, that the domain owner needs to specify a reason why the access to a domain was denied after the request. The policy above does not specify this duty on the Training Design role, thereby inviting an abuse of power.)

With a domain in place you don't need an accountability for "approving or declining requests to impact domain X" on that role then.

That would be a problematic accountability anyway, since such an accountability doesn't limit any other role's behavior (which was the intended effect of it) - even if your job is to "approve", I am not limited by you "not approving". Ok, fine, you did not approve - doesn't mean your role can tell my role what not to do. Accountabilities can't do that - only domains and policies can set boundaries and force prior synchronization with centralized points of control (domains).

Either way, you should consider testing the proposal for the policy to find out, whether there is a real tension / example behind creating the policy/ domain in the first place. Otherwise, you create a lot of red tape without the need for it. 

Hi Anne Nynke,

In my understanding :

1- Such a policy + an accountability can bring the same effect than a domain t(if the accountability include the obigation to explain the objection to the demander in case the role's filler give a "no", you reach the same effect cf 4.1.2 (c)). Little difference nevertheless : a role with a domain can create policies on the domain by its own. If you have a policy + accountabilit, you have no right to edit a proper policy (but you could edit  a document explaining how you express your accountability with some rules, which would have the same result)

In my opinion, such a policy + acc. is valid governance. In that case, I find Domain a more elegant way, but it's totally ok.

2- Such a policy without an accountability : would be quite bad governance, because the role has no clear expectation on it to consider and process the requests. If I coach the circle, I would consider it as probably a sign of misunderstanding of policy (that don't require action). But personally I would consider it valid if phrased this way. Because there is no explicit call to action. And if the role filler judges that it serve his role's purpose to process the requests he receives after the adopton of this policy, that will work. If he doesn't, someone will have a tension and wil bring it to the next governance meeting.

3- such a policy + a domain on the role : valid but redundant (valid & bad).

So to answer your last question :

"Can you make a circle policy, expecting a role to give approval without giving this role an accountability or domain for it?"

It's better not to, good governance recomand point 1- ; but you can (bad governance is not necessarily invalid governance ; it might trigger coaching -picking up wisely your battles depending on the situation- and not NVGO objection)

Hope that helps

Vincent