Remove §1.4.5 - Creating Circles Across Roles?

[brianjrobertson]

While beta testing v5.0, some potentially weird and confusing issues have arisen with the rules in §1.4.5, which allow multiple roles across the holarchy to form a new cross-cutting circle around those roles to govern something together. The issues are rather nasty and I can't find an easy solution. I won't get into the details of those issues here, at least not yet, because they're somewhat complex to explain and I'm not sure the explanation is needed; rather, I want to ask if anyone sees a reason we can't just cut this section altogether? You can still achieve the same effect by just inviting roles to link into an existing circle in the holarchy (using the rules in §1.4.4), and you can always create a sub-circle just for that purpose if desired, instead of a cross-cutting circle. So, anyone see a good reason to try to keep §1.4.5 in this release, rather than cut it and revisit in a future version? Keeping it would almost certainly delay the release of v5.0, and I'd really like to avoid that if practical.

[bernardmariechiquet]

One problem I see is that this feature has been announced and widely published, and it has been very well received by several companies I know, when they want to be able to manage significant cross-cutting projects, make them appear in the holarchy and take advantage of the meeting mechanisms. All this in a simple way. It would be interesting if :

• either you explain to us the pitfalls that you may have noticed, so that we can build together
• or to properly set out the concrete cases observed that made you bring this new functionality into the constitution in the first place And maybe both approaches would be valuable.

Having said that, I do not see how your question could be answered at this stage, validating the fact of cutting this function. It would seem unconscious to me. We've already waited for 5.0 for a very long time, we're not one or two weeks away, it seems to me.

[brianjrobertson]

I don't want to get in to all of the nuances of the pitfalls in writing, but I'll answer the other question, and if that doesn't address your tension or you want more, feel free to let me know and I'll record a video with some of the problems with it instead of typing it all.

To your other question, about the cases, one set of examples came from one large client of ours, which has numerous enterprise-level projects that cut across their traditional departments, and they want to manage and govern them in a circle (and most of the examples I have fit this same pattern). That said, even without §1.4.5, they could still call a cross-cutting tactical meeting, and if they need governance, they can still get that as well - they'd just have to create a new GCC sub-circle to hold it, and then link all the roles into that circle to govern the cross-cutting initiative. So the only downside to not having §1.4.5 is a bit more inefficiency in creating the structure: they'd need a GCC governance proposal to create the circle, instead of just all agreeing together to do so. But once they have that circle, they can use §1.4.4 to all link into it and govern the crossfunctional project, just as they would have with §1.4.5. This was even possible of course in v4.1, but in that version, it would risk inflating the size of the GCC with all those extra Rep Links - that was another reason for adding §1.4.5. But in v5.0, there's more flexibility around excluding Rep Links (Circle Reps) already, at least within certain bounds, and a circle composed entirely of links from elsewhere definitely meets the standard required for the broader circle to exclude Circle Reps.

Another example case used to drive §1.4.5 was within HolacracyOne: We sometimes hire software developers, which involves a courting process that has many steps involving many roles across at least 3 circles, sometimes 4, and it would have been useful to have a way to govern that process across those roles. But just as in the example above, we can get this need met without §1.4.5, it just requires us to go through one extra step of proposing a circle for it to hang off of in an existing circle's governance process and then linking in the desired roles, and adding a policy to prevent Circle Reps from that circle if there's any tension about that.

So, my current sense is that §1.4.5 does not itself provide a major new function, but rather just an optimization on what's already possible from a combination of §1.4.4 plus the ability to exclude Circle Reps. And it is currently unknown whether the optimization is really all that important. I do know that the new function is important, but we've already achieved that even without the §1.4.5 optimization available.

[bernardmariechiquet]

Thank you @brianjrobertson for that explanation. I understand the two cases you present, they are almost exactly the same cases I've seen with some clients of ours. And indeed, you're right, there is always the option of creating a sub-circle in the CCG governance meeting.

And there is a major drawback from my point of view that I anticipate with §1.4.5 (and I may be fully wrong): how can the prioritization function be done within a circle created by two different circle roles without creating conflict with the two leaders of the two circles involved, and same on the attention of the partners. I would be happy if you could take the time by video to point out some of the pitfalls you may have encountered with §1.4.5.

Furthermore, I think that in the underlying needs of the organizations I met on the subject of cross-cutting projects, there is one that is trivial. It concerns less the constitution than the software that supports usage. I think that what would really help would be if the software offered elegant and automated solutions for : 1- the mechanism that supports 1.4.4 Linking Into Circles, for example, automatic linking upon creation of policy in §1.4.4. I experience that GlassFrog's current practice in this case is perceived to be far too cumbersome, and rightly so from my point of view. 2- the mechanism that supports §1.5.3 Amending the Circle Lead Role The fact that GlassFrog does not manage anything to date can be seen as very embarrassing to date, and rightly so from my point of view. 3- the mechanism that supports a cross-cutting tactical meeting, which do not exist by now.

Finally, I think the elegance and power of GlassFrog technology in its ability to support its articles of incorporation is most likely at stake here. IMO the software probably needs to go further, deeper to support, facilitate and enhance the practice, which partly explains from my point of view, the growing interest that many may have with other software.

[brianjrobertson]

@bernardmariechiquet Here's a video covering some of what I ran into.

As far as the importance of elegant software automation for cross-linking, I totally agree: we're already working on that in GlassFrog, and the UX flow we've designed seems really simple and intuitive to me. As far as editing Circle Lead, I actually think that's less important now than it used to be, now that there are no accountabilities on the role to remove, but it is still something we'll be implementing - and I've got a pretty cool design in mind for that I think, though it still needs to get vetted more with our UX design role. And supporting cross-cutting tactical meetings is high on our priority list as well.

In short, I'd say there's quite a bit to add to GlassFrog (or any other tool) to adequately support v5.0, but we've been working on it for many months now and will continue doing so until we've got all the support just right. It's proving quite tricky - there are many nuances with the v5.0 constitution that have led to many design iterations in our GlassFrog development work to support it - but I do think we've got exactly the right team in place to do that work really well, and I doubt that's as true for any other vendor.

[bernardmariechiquet]

@bernardmariechiquet Here's a video covering some of what I ran into.

Thanks, will take a look at it shortly.

As far as the importance of elegant software automation for cross-linking, I totally agree: we're already working on that in GlassFrog, and the UX flow we've designed seems really simple and intuitive to me. As far as editing Circle Lead, I actually think that's less important now than it used to be, now that there are no accountabilities on the role to remove, but it is still something we'll be implementing - and I've got a pretty cool design in mind for that I think, though it still needs to get vetted more with our UX design role. And supporting cross-cutting tactical meetings is high on our priority list as well.

You're absolutely right about the Circle Lead. Editing this role no longer makes sense with the new modalities offered by version 5.0.

In short, I'd say there's quite a bit to add to GlassFrog (or any other tool) to adequately support v5.0, but we've been working on it for many months now and will continue doing so until we've got all the support just right. It's proving quite tricky - there are many nuances with the v5.0 constitution that have led to many design iterations in our GlassFrog development work to support it - but I do think we've got exactly the right team in place to do that work really well, and I doubt that's as true for any other vendor.

Yes, it's one of my fears for all the clients who chose the other software.

[bernardmariechiquet]

Thanks @brianjrobertson for the video, very helpful. Definitely, I support the option to remove the §1.4.5 for Creating Circles Across Roles. In addition to the arguments you give in your video, I feel in this option the risk of losing the integrity of the holarchy. It's as if being able to do work "outside the circles" creates what I would call a "hole in the plane" (I'm not sure that this French expression can be translated literally this way in English). It seems to me that, at this stage, the context or initial conditions for creating this Circle Across Roles mechanism are not yet sufficiently well understood. This is a matter for the future, reality will take care of it.

[JakobEng]

Hi @brianjrobertson and @bernardmariechiquet,

Thank you so much for being part of creating the Holacracy Constitution, I'm new here and really like the idea of using holacracy across companies for smooth collaboration. Therefore I have a proposal for the cross link I believe you would find interesting.

I would argue that the anchor circle is a cross circle and any role should be able to create a cross circle with another role if they are starting an initiative that depends on both roles participating. For 2 reasons:

1. It clearly communicates the shared responsibility between the 2 roles. In your video above you suggest that creating a cross circle would create inconsistency since you can achieve the same by creating a sub circle and inviting a role to link into that circle. By doing that this new circle belongs to the role that initiated the circle and the role invited to this circle can just unlink at any time or be unlinked by the circle lead which clearly indicates that the role initiating the circle is responsible for this new circle.

2. It makes it easier for cross one organization to create a shared initiative with another organization I'm right now in a situation where I'm co-creating a new company with someone else where we will own 50 % each of the company. For us it would make sense to create a cross circle where we would also choose to adopt the Holacracy Constitution within this cross circle. So what you said @bernardmariechiquet about creating a "hole in the plane" seems quite accurate. I believe if you wanted to create a normal management hierarchy in this cross circle you should be able to do so. In my opinion a cross circle is like the anchor circle, a new entity independent of the rest of the Holacracy Constitution unless otherwise specified.

My proposal would then be to add the following rules

1. An cross circle can only be added if 2 or more roles agree to create one
2. If there are 3 or more roles in a cross circle then any role can unlink at any time unless otherwise specified.
3. If a cross circle only have 2 roles then a role can only unlink when all information (eg sub roles, domains) have been removed or moved to one of the roles own circles

The 3 rules above would prevent the inconsistency that @brianjrobertson was worried about and pointed out in the video above. You properly have a specific way of writing the rules but the above is the intention of the rules.

Hope you like the idea.

All the best, Jakob