Processing your role's Accountabilities

An accountability on a role doesn't mean that the person filling that role must absolutely get this work done. Depending on how many other roles that person is filling, and the time constraints he or she has, it may or may not be possible. Instead, according to article 1.2.5 of the Constitution, they're responsible for consciously considering all the actions they could take to energize all of their roles' accountabilities, prioritizing them, and executing on the highest-priority actions.

Best Practices for Writing Accountabilities

Here is a list of verbs often used in accountabilities to mimic a conventional relationship between roles. Here is why they aren’t the best choice, then some alternatives.

Accountabilities starting with “Enforcing…”, “Ensuring…”

Usually indicates an attempt at mandating a result, e.g. "Ensuring 20% growth in revenue". This is typical "what by when" thinking: setting a target and pushing our way toward it. Unfortunately, we cannot control reality, we can only try to influence it as best as possible. So the question becomes: how should we do that? The “how” is the activity we want to capture in an accountability. For example, instead of "Ensuring 20% growth", one could propose "Generating demand for our products that converts into closed deals". Then, it's up to the circle to prioritize this sales activity versus other work, so that we have the most chances to reach the 20% growth target. (Prioritization of the work happens outside of governance; it’s set by an explicit strategy or directly by the Lead Link).

Sometimes, these accountabilities convey an intent for the role to control the work of other roles, e.g., A Customer Service Lead with an accountability for “Ensuring that all Customer Service Agents provide a service of quality to customers”. The problem here is that this accountability is not achieving the intended goal: an accountability does *NOT* give any extra authority to control how another role does its work!

To accomplish the intended effect, an alternative would be to propose adding an accountability on the Customer Service Agent role itself for “Responding to customers’ questions and helping them get what they need from our company, while offering the customer a positive experience of going through that process”. Then it’s up to the Lead Link of the circle to assess whether each person in that role is a good fit for the role—and to remove them from the role if they’re not.

Another alternative would be to create an additional role, e.g., Customer Service Experience, accountable for “Defining and implementing tools and processes to help Customer Service Agents support our customers as effectively and pleasantly as possible”, and to add an accountability on the Customer Service Agent role for “Helping customers by following the process defined by Customer Service Experience”.

These are just examples — there are countless ways of organizing the work and defining the relationships between roles. Some are better than others. Holacracy isn’t here to tell you which way to choose, it will simply force the clarity around it.

Lastly, I’ve noticed that often times, results we want “enforced” or “ensured” are clues to the Purpose of a role. Our Training Operations role at HolacracyOne has a Purpose of “Flowing logistics for great experiences” — that’s certainly something he wants to ensure happens!

Often used to ensure that a role will work with others to do its work, even though the role-filler already has the authority to work with whoever makes sense to them to get their work done. Spelling it out in an accountability is often a clue to a misunderstanding of the basic authorities given to a circle member by virtue of filling a role in Holacracy — i.e., anyone can already collaborate however they want with whoever they want to express the purpose or accountabilities of their roles. As a result, those verbs may have the counter-productive effect of implying that if it's not spelled out, then a role-filler must do its work without collaborating with others (which is not true).

If we really want a role to "collaborate" with another role, then it’s much clearer to specify the nature of the collaboration. Do we want the role to "consider suggestions" from another role? Or "integrate objections"? Or even "integrate input"? Or do we really mean "Execute ... as directed" by another role? Some options are better than others depending on the context, but regardless of which we choose, clarity has the merit of forcing us to make a conscious decision about the kind of relationship we propose between the roles.

Usually indicates an attempt at controlling someone else's work. As explained above, an accountability does NOT convey this authority. Again, Holacracy forces us to be clearer on the relationship between roles. Ask yourself the question: what type of activity are you envisioning when “supervising” the work of another role? Is your goal to be available to support and coach because you have more subject matter expertise? Or do you want your role to be a gatekeeper, so that the output of the work can’t be released without your approval? Or something else? Here is how you can improve the proposal depending on the actual need/tension behind the proposal.
If you want to offer support to other roles, you can simply call it out by using one of those verbs instead: "Supporting...", "Assisting...", "Coaching...".
If you want your role to be a gatekeeper to another role's work, call it out clearly. Let’s see how below.

One caveat about “Managing”: even though using “Managing” is sometimes an attempt at describing an authority over another role’s work (e.g., “Managing the Customer Service Agents”), at other times it’s a perfectly appropriate accountability when it’s describing the administration of something (e.g., “Managing relevant vendor relationships with Internet providers”).

Accountabilities starting with “Approving…”

Usually indicates an attempt at creating a gatekeeper over some process or resource. Here again, an accountability does NOT limit other roles in any way, so the desired result is not achieved with such accountability. If you think about it, technically an accountability for "approving" means that other roles can expect this role will be "approving" stuff — not “evaluating and making a decision”, just “approving”... And even if the role decides not to “approve”, there is no constraint on other roles to align with this decision... so what’s the point? Indeed, it’s not very meaningful.

Instead, you usually want a Domain or a Policy to restrict other roles from impacting a particular process or resource. For example, at HolacracyOne we currently have a Writer role accountable for writing blog posts, and a Web Publisher role acting as a gatekeeper to our blog content. To get this blog post published, I’ve had to write it and submit it to Chris, in his Web Publisher role, who had the authority to decide whether to publish it or not (thanks Chris for approving it!). This authority is given to his role because of the Domain it has over “HolacracyOne’s blog content” — which means no other role can impact the blog content without his permission.