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:
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!