Policies Governing People in Holacracy

The organization can only control what it owns, and it doesn’t own people. It can make agreements with people, but it cannot unilaterally mandate or determine people’s behavior.

How NOT to Handle Things Like Working Hours, Dress Code, and Social Norms

Policies related to hours of operation, or other expectations of people which are typically captured in an employee handbook, are usually not valid Holacracy-compliant policies because the organization doesn’t own or control the people, it only controls the roles (i.e. its functions, its resources, etc.).

These invalid policies usually look something like, “GCC Policy: All timesheets must be submitted by Thurs.” Of course, the organization needs a way to update expectations on people, not just roles. To explain how that happens, I’ll divide these needs into two categories: 1) Expectations that are so important they determine whether or not someone can join/remain a partner in the organization; and 2) Expectations on how someone will behave within a limited scope or role.

Partnership-Determining Expectations

These are the foundational terms made between an individual and the organization, without which there is no relationship. These typically include things like working hours, full-time vs. part-time, travel-related expectations, dress code, etc. These are best documented in a “relationship contract” (or “employment contract” or “partner grant agreement”), which is codified when someone joins the organization. Expectations on both sides are clarified and conscious choices are made.

But what happens when these expectations change? It doesn’t feel right for either party to suddenly demand a new expectation under threat of ending the relationship. That would be like a spouse saying, “From now on you must be home by 6pm or we’re getting divorced.” Ultimatums are weird because they leverage a previous agreement (which was made freely), to unfairly impose new agreements. Which is why you can’t simply cut-and-paste old “organizational policies” into organization-wide Holacracy policies.

But that doesn’t mean that governance isn’t needed. Instead:

• Give the domain of “Partnership Grant Contracts” to a specific role (see HolacracyOne’s example here).
• Give the role an accountability like, “Creating and maintaining partnership grant contracts that capture terms required by the organization.”
• Then let tensions drive what happens next (you might need to define a process for how to update those contracts — maybe not). Don’t worry about designing the perfect solution. Just get started with something.
• Be prepared to have adult conversations. If the organization wants to update a partnership-determining expectation (e.g. “All partners must now be willing to work weekends”), then it should be prepared to hear a conscious and honest, “No.” And to work to get that agreement, negotiate, or consciously terminate the relationship without resorting to threats and ultimatums.

Role-Determining Expectations

Sometimes the organization would like the right to expect certain behaviors of people within the scope of a particular role (e.g. “Customer calls must be answered within three rings”). This isn’t usually a partnership-determining expectation, unless someone’s employment contract/agreement states that only certain types of work will be performed.

But it’s an important expectation none-the-less. Usually, the first attempt is to use an accountability like “Answering the phone within three rings” on a Customer Support-type role. The problem is that an accountability, by definition, is really just an allocation of conscious attention. Meaning someone CAN expect that the role-filler is regularly reviewing that accountability and prioritizing it against all the other work they have to do, but they CAN’T expect that the phone will actually be answered within three rings.

However, since the circle’s Lead Link has a domain on role-assignments, that role can specify the conditions, qualities, or behaviors to which someone must agree in order to get that role assignment (i.e. technically these would be “policies” on the domain of “role-assignments within the circle”).

Note: ^^^ This approach only works if it’s absolutely clear that Lead Links cannot assign someone to a role without their agreement to accept it. So, this is purely a matter of convenience to make these role-filling agreements explicit (i.e. a policy), rather than a method for forcing expectations upon an individual person without their consent.

Meaning, the Lead Link of the Customer Service circle could say, “I’m not assigning anyone to the Customer Support Role unless they agree to answer the phone within three rings.” This is a perfectly valid way to control one’s domain (but since the constitution says “Implicit expectations hold no weight” the Lead Link should probably keep track of who agrees).

Of course, this power is offset by each individual’s right to refuse to take any role (unless a policy says otherwise) without impacting their overall relationship with the organization. And if the Lead Link couldn’t find anyone to agree to those terms, well, then they’re stuck energizing that work until something else can be arranged (not to mention, though I am…someone could always propose removing the domain of role-assignments from the Lead Link).

In conclusion, org-wide policies intended to apply to all partners or employees don’t work well (or are straight-up invalid), and using an accountability to define a continuous behavioral expectation doesn’t work either. So, hopefully now you have some simple alternatives.

Read “Introducing the Holacracy Practitioner Guide” to find more articles.