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

Are accountabilities and purpose implicit domain ?

As in the subject...

For instance:
we have the role: "Mobile designer" with purpose: "Consistent, elegant, and usable interfaces" and accountabilities: "selecting application colors"
than we have the role: "Mobile developer" with purpose: "Develop best mobile application" with some accountabilities...

Mobile designer choose the green as buttons color
Mobile developer develop the application and they use the green for all buttons. Reading the line gide of them framework they (Mobile developer) discover that the button should be yellow.
Can they change the colors of the buttons and deploy?

 

hi

  Giuseppe

7 Replies
Dien Kwik
03/10/2016

Hi, Giuseppe:

Yes, I believe in this case the mobile developer can choose whatever color he/she chooses even if it conflicts with the choice of Mobile Designer.

Domain is the only thing that can restrict access from all roles.

In the example you gave, since the domain of application color is not defined on any roles/circles, then any role can impact the application color the way they see fit, thus mobile developer can choose to use yellow for the button if he/she thinks it's best.

Now, since there is no accountability of selecting application colors on mobile developer, he/she doesn't have to do it.  He only needs to do it if it is needed to fulfill one of his accountabilities.

Mobile Designer,on the other hand, has to do it, because it is expected of this role since it is written as an accountability. He, however, can not force mobile developer to use the color the mobile designer chooses, since the domain of application colors is still communal, i.e. belonging to the circle or one of its super circles.

I believe to get the effect you want, i,e, mobile developer using onky the color specified by mobiel designer, you need to define an "application color" domain on mobile designer, with the accountability of "selecting application color".

I think this is enough to make sure other roles, including mobile developer, follow what mobile designer decides for application colors. You can also add an accountability on mobile developer to "create application using colors specified by Mobile Designer" to make it crystal clear, but it seems like it's not actually needed once you have the domain defined.

Dien.

 

 

 

DeAngelo
03/10/2016

Dien lays of the options as I think of it as well. The only clarity I would add is you could do this one of two ways: 1) specify a domain as Dien describes or 2) create an accountability for mobile developer as Dien described in his last sentence.

Personally, I try to avoid domains where I can because they are such a heavy tool (use accountabilities instead) and they can be abused to make things feel too much like command-and-control. However, domains may be necessary and can be an efficient way to convey needs to more of the organization.

If it makes sense, you may start with some linked accountabilities and see if that resolves the tension.

 

 

 

 

giuseppe_c
03/10/2016
Are you saying that accountabilities do not limit other roles ? where is written this thing in the constitution  ? 
 
 

 

 

 

DeAngelo
03/10/2016

Not intending to say that at all.

However, accountabilities are a more precise restriction i.e. Role X: "Creating applications using colors specified by Role Y" rather a broad restriction i.e Domain: "Application Color" which would, at the very least, restrict all roles in the circle. Which, in the end, may be the scope of the tension.

Eric Babinet
03/10/2016
giuseppe_c posted:
Are you saying that accountabilities do not limit other roles ? where is written this thing in the constitution  ? 

Yes, that's correct. An accountability only tells you what you can expect from the role that has the accountability, but has no impact on other roles. 

The authority to act comes from §1.3, unless limited by a Domain:

1.3 Authority to Act

As a Partner assigned to a Role, you have the authority to execute any Next-Actions you reasonably believe are useful for enacting your Role’s Purpose or Accountabilities.

However, you cannot exert control or cause a material impact within a Domain owned by another Role or another sovereign entity, unless you have their permission. The authority granted in this paragraph is further limited by Section 2.1.3.

 

 

giuseppe_c
03/14/2016
Eric Babinet posted:

Yes, that's correct. An accountability only tells you what you can expect from the role that has the accountability, but has no impact on other roles. 

The authority to act comes from §1.3, unless limited by a Domain:

I thought that mobile developer could change the color of the button but acting as Mobile Designer.
I thought that this was granted by article 1.3 (Individual action).
why is not correct this interpretation ?

Dien Kwik
03/14/2016

Hi, Giuseppe:

Individual actions can only be taken by a role if all the conditions laid out in the constitution for individual action are true. 

 

If only an accountability of selecting color is defined for Mobile Designer (no domain), then:

  • Mobile Developer can change application color, without taking individual action, if it's needed to express the purpose or one of the accountabilities of Mobile Developer
  • Or, Mobile Developer can take individual action when selecting button color is actually not needed to express Mobile Developer's role or accountabilities, but only if all the conditions laid out in the constitution for individual actions are true.

 

If Mobile Designer has the "Application Color" domain, then in most and normal circumstances, other roles, including Mobile Developer, have to get permission from Mobile Designer or follow the policy that Mobile Designer has set to select application color.

If Mobile Developer wants to break this rule by taking individual action, again, all the conditions laid out in the constitution for taking individual action need to be true, including that the role feels that "the action can't be delayed long enough to get the permissions normally required, or proposing in governance to allow the action without losing much of its potential value"

 

Dien.