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

Policies affecting "all functions and activities within the circle"

Hello!

In our organization I've noticed a tendency to create "policies" which are actually just rules to govern behavior or norms, and while I've always felt this wasn't really valid but I'm not sure I know enough about policies to be sure.

As per §2.1.2 and §1.3 of the constitution it's implied that policies are only for granting access to certain domains, which makes sense if the domain is explicit. But most of these suspect policies in our organization are labeled to impact "all functions and activities within the circle." 

What does THAT mean? Does it refer to any work that's done by any role? Does it refer to behavior of people (I assume not)? Or does it, as I suspect, only refer to the constitutionally-defined expectations and obligations of the circle, meaning - what it can do holacratically?

As a followup, I noticed in Brian Robertson's video proposal on a "people pool" app that he needed to actually amend the constitution to create space for behavioral agreements between people in the organization. As he explains it, as per §4.1.5, ONLY governance output, the constitution, and legal contracts between partners or team members can constrain work or define responsibilities. 

Does that mean there's no way to create binding agreements for behavior or relationships?

8 Replies
Tom Mulder
02/05/2019

[@mention:577633875653772077]: maybe this articles will shine a light on it. 

https://blog.holacracy.org/und...domains-54af3ba955f4

https://blog.holacracy.org/und...olicies-d1258264d2ab

Chris Cowan
02/06/2019

[@mention:577633875653772077] Great question! Would you be willing to share a specific case you're dealing with? 

Here's my general advice, because from your post I can tell you've already looked into this a bit, so I'll just jump to your question, "Does that mean there's no way to create binding agreements for behavior or relationships?" The answer is simply, "No." 

No, it doesn't mean that. The point of this section is to avoid implicit expectations related to how the roles should interact with each other. That stuff should be made explicit in the governance records. That's the point of it. And even though it's going to be made more clear in version 5, I think there are several different ways you can interpret this section as currently written to do what you need to do.

One reasonable interpretation is that it only applies to 1) "former" and 2) "implicit" agreements. Meaning, change a word and write it down and you can use it. 

Or, consider the behavioral agreement a "basic obligation," like something you might capture in an employment agreement. 

And finally, you could always say that an agreement we have is personal. And therefore even the constitution doesn't have any say over it. If you and I agree to meet for lunch at noon and I just don't show up, well the constitution might not care about that, but I'd bet you'd personally care about that!

So, to take a work example, if I'm always saying I'll be at meetings, but then I never show up, you could share and ask, "Hey, when you flake on meetings it really throws me off, so could you agree to let me know if you're going to bail on a meeting?" And I say, "Yes," then this agreement is neither "former" nor is it "implicit." 

But my big caveat to this is to remember the point of section 4.1.5 which is that this could easily become a loophole to not capture things in governance. So, watch for that, especially for anyone new to the practice. But there's a learning curve no matter what. 

REFERENCE:

4.1.5 Implicit Expectations Hold No Weight

All of your responsibilities and constraints as a Partner of the Organization are defined in this Constitution, and in the Governance that results from it. No former or implicit expectations or constraints carry any weight or authority, unless a Circle’s Governance explicitly empowers them, or they come from a basic obligation or contractual agreement you personally have to or with the Organization.

 

Malachi Rempen
02/06/2019

Thanks both.

Chris: makes sense that we would still have agreements outside of governance that would guide our behavior with one another, thanks for clarifying. So essentially what you're saying is that we could easily create documentation to "govern" our human obligations to one another and that would be perfectly fine (unless, I guess, something in governance superseded it?). Do I have that right?

If so then I go back to my question about the meaning of "all functions and activities within the circle."

For a few specific examples, we have a number of policies in our GCC impacting the domain of "all functions and activities," including one requiring team members to update their away times in a specific Google Calendar, another restricting how holiday time can be taken, and another requesting that we avoid the word "staff" in favor of "team member." 

While I don't disagree with them in principle, these just don't seem like holacratic policies to me. The first is an oddly specific guideline, the second is trying to tell people (not roles) what to do, and the third is a sort of best practices recommendation. If a policy grants or restricts access to a domain, and a domain is something controlled by a circle or role, then these seem non-constitutional - at least where they currently are sitting. How does a circle control holiday or working hours? Roles don't have working hours or go on holiday, people do. And how does a circle control word usage??

I feel like "all functions and activities" is meant to refer to the holacratic structure and governance, not "anything that any person in this circle is doing." Even if these are perfectly legal policies, it feels like they should be pointing to a specific domain. But some clarity on that would be much appreciated! Maybe I'm the one with a fundamental misunderstanding here.

Thanks very much! Great to get such quality feedback and guidance.

Chris Cowan
02/07/2019

[@mention:577633875653772077]

Ah, Ok!  So, you're right that there are issues with the policies you mentioned (read general guidance here). Things like requiring team members to update their away times in a specific Google Calendar and another restricting how holiday time can be taken are invalid but you have other options. The main issue with them is that they impact the people, yet "a person" isn't a role and therefore can't object to any of this. So, essentially the organization is unilaterally mandating something and the impacted parties have no direct pathways to do anything about it.

That's probably the off-ness you're sensing. But there are some simple alternatives. Now, the best solution is really case-by-case, so it might require some more direct coaching because I don't know what might work best for you, and all of these have some downside, but some approaches I've seen work: 

  • Have a role responsible for documenting and updating these types of expectations (see our Partner Agreement Steward role). 
  • But a Rep-link-type role in the GCC (or whatever circle has the authority over "partner relationships") to represent the partners thus giving them a pathway to object.
  • Finally, you can leverage the domain of "Role assignments," to define specific conditions under which someone may be placed in a role. And these can be about the person. So, in my company's case some roles can only be filled by partners with the Holacracy Coaching certificate (e.g. Holacracy Coach).  So, if you need to define specific working hours for specific role-fillers, then it's basically like saying, "Hey, I'm not going to put you in this specific role unless you agree to generally be available for these hours," or whatever. There are lots of potential problems with this, but it might be a step forward.

And in any of these cases, I don't expect that the overall effect would be much different than how you're using the policies now. But it's a more aligned way to get there. 

---

Now, regarding this policy, "and another requesting that we avoid the word "staff" in favor of "team member," that one isn't invalid, it's just not a good policy. You can read more here in the section "Watch Out for "Should". Basically, don't use policies as guidelines. Policies should be clear and categorical.  

But there's nothing wrong with publishing guidelines. In HolacracyOne we have accountabilities like "publishing guidelines" in several places, but they are all specific to what roles may be doing. It sounds like you're talking about defining some sort of cultural norm, in which case you may want a role to figure out the best way to harvest, publish, and update those guidelines.  

And this is the rub...we have to clearly differentiate "control," from "influence." Like, when you say, "How do you control word usage?" well, in specific cases of marketing materials or contracts you might actually want governance policies to control usage, but that's all about the roles.

But when it comes to the people (as people) and how they talk to each other, you can't control that. And I don't mean "you shouldn't." I mean you can't. It's kinda like trying to mandate that "everyone be nice to each other." It's a paradox. What you want is to influence word usage. 

So instead, if you provide guidelines and those guidelines make sense, then people will use them as appropriate because they get it. Not because someone else is telling them that they must. It's a much better way to influence actually.

Personally, I think this is an important philosophical point, but hard to convey in writing, so I hope that makes some sense (I wrote something on how I think about control vs. influence here). 

And if you want to explore this more, then I highly highly highly highly recommend reaching out to one of the licensed Holacracy providers. They can save you a lot of time and suffering.

---

Finally, you're right that the domain of "all functions and activities," is kinda weird. But you can try to think of it like an implicit domain (not an official term), and I wrote about them here, but here's the relevant section: 

Implicit Domains

Since the broadest circle (i.e. the GCC or whatever your company calls it) automatically controls everything, it would be ridiculous for it to capture everything in Glassfrog as a domain (e.g. “Company logo,” “procurement process,” “coffee machine,” “coffee filters,” “coffee beans,” etc.). So, instead we think of these as implicit domains. Meaning they don’t need to be called out explicitly in governance because the constitution already says, essentially, “the company owns what it owns.”

This is why you will sometimes see policies listed on the domain, “All Company property & ordinary business affairs.” This means the policy is being placed on an implicit domain, which would be duplicative to call out.

For example, if the policy “Anyone using passwords to secure company-related accounts must ensure those passwords are strong,” was on the GCC, you wouldn’t need to also add the domain, “Company-related Accounts,” because that domain is implied.

Now, personally, I think it's probably best to try and define the specific domain whenever you're doing a policy that would otherwise rely on the generic, "All functions..." thing. Especially in early practice because it just tends to confuse things, but this may not be that relevant an issue to you given my breakdown above.

I hope this helps! It's a really important topic!

Malachi Rempen
02/08/2019

Wow! Thank you, Chris, for the incredibly detailed reply. This is very helpful. I will have a look through your resources and try to understand policies a bit better. 

Very much appreciated! 

Anne Nynke
02/08/2019

Such a relatable tension! At Springest I have also had a similar tension. Some 'Rules' (like how to request or process vacation days) are important to apply for every employee, but how do you process this into Holacracy?

The way I solved my tension at the time was by proposing a 'Springeteer' role in the GCC. It's basically a 'team member' role that everyone in the company holds (and is non-core). 

Some accountabilities of this role involve:

  • Adhering to the Springest sickness policy (*link to internal helpdesk article about sickness policy*) and updating Arbo-role on absenteeism before 09.30 daily.
  • Sharing in Slack when you are late or away
  • Reviewing GTD every week
  • Adhering to Communication Rules of Engagement: *link to internal helpdesk article about RoE*
  • Cleaning your desk and cleaning up after yourself in general (also clean up after guests)

So everyone in the company holds this role and is therefore accountable to adhere to certain 'rules of engagement'. The communication RoE includes rules about tone of voice for example (which you mentioned something about too) 

In turn there are roles that have an accountability to write and update these Rules of Engagement (e.g. arbo-role being accountable for writing the sickness policy, etc). 

Don't know if it's the prettiest solution, but it helped in our case! Wanted to share just as an example of how we dealt with it

Very curious to hear about other solutions. Do keep us updated about how you'll process your tension! Interesting topic.

- Anne Nynke

 

Malachi Rempen
02/11/2019

Thanks Anne, that's very interesting and really great to hear about how other orgs are tackling these issues. 

I wonder though if your solution actually solves the problem - the problem being that a role is not a person, and can't be held accountable for "people" things. But I might also not be understanding the role/soul distinction so well.

Also, as per Chris' point above ("the main issue...is that they impact the people, yet "a person" isn't a role and therefore can't object to any of this."), does that mean that everyone at Springest can come into the GCC meetings to propose changes to the Springeteer role?

Rachel Hunt
02/26/2019

I've been solving this problem by including "people" type accountabilities within each role. It's similar to what Anne has done, but avoids the added bulk of including every partner in an additional role. It's also kind of a legacy of previous employment contracts, which included many of these things as hiring requirements.  It occurs to me that my approach could be unholacratic in that it blurs the line between roles and souls. 
While the old solution of including these types of requirements in hiring agreements is one way of solving it, that approach could make it harder to change the requirements later if there is a tension.
Including them in roles is much more flexible and also avoids having partners negotiate exceptions in their contracts which could end up seeming both unfair and not subject to remedy by tension.
I wonder if Anne's approach to create a new "person" type role for each partner is more holacratic or if it's okay to leave those personal-type accountabilities embedded within each role.