Holacracy-constitution: Need Clarity for Multi-filled Role Authority & Constraints

[brianjrobertson]

As a role-filler in a multi-filled role, I'd like constitutional guidance on how multi-filled roles share authority/autonomy within the role when a Focus is not provided, so that we don't feel the pull to default to consensus on many issues.

[brianjrobertson]

The approach I'm currently envisioning to implement this story is to clarify that role-fillers each have autonomy to execute the role independently, however integration is required across all role-fillers before any one of them defines a role-based policy, disposes of the role's resources, or makes any hard-to-reverse commitments/decisions. And allow a role-based policy to further modify or constrain role-filler interactions or authorities in the role.

Any reactions?

[karilen]

In general I really appreciate making all this explicit. I am wondering what is needed for the policy or disposing of assets part. Is it a proposal by one role and opportunity to only integrate objections? Did you mean full IDM process by integration? That could be interesting to say it needs to be done via IDM with other role fillers, or maybe you have a good reason for leaving unspecified.

[brianjrobertson]

@karilen: I was envisioning something very similar to what we see in practice when one role has a requirement to integrate objections from another role for a certain operational decision: usually, a very informal checking-in to verify with that other role-filler. Yet, this also relates to this issue I just submitted: sometimes you do want a more formal process when that gets painful, and I think that other feature will cover it in this case.

[brianjrobertson]

I'm considering introducing a distinction made upon assignment when a role is multi-filled: are the assignments "joint" or "independent"?

An "independent" assignment means that each person who fills the role is treated as if it's an entirely separate role, with no connection between them; each role-filler can ignore the others and use the full power of the role, and requests for projects/actions have to be made to one specific instance/role-filler of the role, as if each were a separate role; a focus may be used here to further differentiate these assignments, or not when that's not useful, but in either case each assignment instance behaves as if a separate role.

A role multi-filled with a "joint" assignment means it acts as if it's one role vs. many; each role-filler may use the power of the role, but must integrate objections from others before making hard-to-reverse decisions, allowing others to impact a domain, or just upon request of a co-role-filler for any specific decision of the role; projects and actions can be requested of the role in general and enter a single queue for all role-fillers to pull from; and the role-fillers can further govern the role by defining policies changing those defaults or limiting expression of the role through the governance process, but with just their co-role-fillers (whole circle not needed). Focus is not allowed/relevant here.

I could use some input on this: Do these two distinctions make sense in your organizations? Do you see multi-filled roles in your org falling clearly into one or the other of those patterns? Any other thoughts here?

[chrcowan]

Feels like this is heading in the right direction, but I can't think of a specific tension I've felt about it, which makes me wonder, so I might provide a better reaction, what is the tension you felt about the multi-filled roles specifically?

Bracketing that for the moment (a lack of information has never stopped me from sharing an opinion), something feels a little off about it upon initial review. The joint versus independent feels right. You're onto something there, but I don't know if they actually need to have different rules.

So, for instance, if you kept the "hard to reverse decision" piece, that could easily apply to both since it would still be helpful for the "independent" version (as in H1 we have that across roles).

And I don't think you need integration in, "allowing others to impact a domain, or just upon request of a co-role-filler for any specific decision of the role," my concern there is that it could pull towards consensus-based decisions.

And if there was a tension about another role-filler allowing another to impact a domain, then that tension could be processed according to the "role fillers can govern the role by defining policies," which I really like and think it would help clarify the more subtle dynamics at play with multiple people in the same role.

[cassus]

"joint" vs. "independent" makes sense, I already make this distinction for multi-filled roles in our company

The joint multi-filled roles usually mean 2 people want to jointly do something, without defined structure. I like the default rule of checking for objections of hard-to-revert decisions with joint role-fillers, that makes sense, I think most jointly multi-filled role fillers already do this.

I wouldn't put _allowing others to impact a domain_ in the same category as hard-to-revert decisions. Allowing impact to a domain is often not hard-to-revert, so I'd only expect my fellow role-fillers to ask me if they think it's hard-to-revert.

[cassus]

We also have a "helping out" setup when a role holder delegates some pieces of a role to another partner. The work delegated in this way is usually less than 5% of the available time of a partner.

In these cases, creating a separate, well-defined helper role would be just too much governance overhead, and the primary role filler is still responsible for the entire role. (It's like the proto-version of a subcircle, or maybe splitting into two roles later).
Not recording the "helping out" focus at all created confusion before, people didn't understand why X is repeatedly doing things in a role that he didn't hold.

[brianjrobertson]

The "Role Supporter" concept in the latest update has covered part of this need; still TBD:

• Clarify governance/integration is still needed (across Role Leads) to define Policies for a Role that isn't yet a Sub-Circle.
• Article 3's constant references to "Circle" need to be revisited, since governance can now be done by a multi-filled Role that isn't a Circle.

[brianjrobertson]

Solving these remaining issues by merging the definition of Role and Circle; so, rather than a Circle being something that only some Roles expand into, the inside of any Role is always a Circle (although it could be an empty one, with no Roles or Policies within, or a simple one with just Policies but no sub Roles).