Is Holacracy the Answer?

This is the second of four posts on self management. To start with the first post, click here.

In “The Building Blocks of Self-Management,” we started to examine four propositions that characterize different potential features of self organization:

1. Autonomy of execution: once an objective has been delegated to someone, they can decide how to achieve the goal within the agreed-upon constraints
2. No “people managers”
3. Autonomy of role selection
4. No explicit mechanism for setting enterprise level strategy and objectives

Few organizations apply all four of these propositions; a wider range apply one or more. This series of posts represents an effort to make sense of the broad family of approaches to self-managing organization, to characterize how they work and where they can be expected to work well and poorly. Most parallel investigations of this space begin from a stance of advocacy or from a stance of global skepticism about self-management. My objective here is to steer a middle path between these two hardened perspectives.

Of all forms of self-management, perhaps the one getting the most attention now is Holacracy, an “operating system” incubated at Ternary Software, a Pennsylvania-based tech company. I believe the reason Holacracy is receiving so much attention is that it’s a fully-specified answer to the question of what a baseline model for self-management should be. If we had many fully-specified answers that could serve as roadmaps, perhaps this wouldn’t be so notable – but there are very few. Let’s look at Holacracy more closely, in order both to understand its specific value and limitations, and as a jumping off point to ask if there is some other kind of model that might serve better as a baseline.

Holacracy’s foundation is a constitution, currently in version 4.1. Here’s one representative passage from the constitution, regarding how “circles” (i.e., groups that own a particular organizational function) create and flesh out specific “roles” to take on work that needs to be accomplished:

2.1.3 Delegation of Control

When a Circle defines a Domain upon one of its Roles, the Circle’s authority to impact, control, and regulate that Domain is instead delegated to that Role and removed from the Circle.

However, the Circle retains the right to amend or remove that Domain delegation, or to define or modify Policies that further grant or constrain the Role’s authority within the Domain.

By default, any Domains delegated in this way exclude the authority to dispose of the Domain itself or any significant assets within the Domain, or to transfer those assets outside of the Circle, or to significantly limit any rights of the Circle to the Domain. A Circle may delegate these retained authorities as well, by explicitly granting the desired permissions in a Policy of the Circle.

In any case, all Domain delegations are always limited to whatever authority the Circle itself had in the first place.

It’s easy to imagine an incredulous reaction to reading this: it sounds as though everyone in a company would need to go to law school before resuming their day-to-day work. For someone who has mastered Holacracy, a passage like this simply represents precision. Brian Robertson asks us to consider the rulebook that provides a backdrop to a professional sporting competition:

The intricate set of rules and processes that keep the game going have faded into the background. Without them, of course, the game would descend into chaotically kicking a ball around. When everyone in the game has embraced the rules and agreed to play by them, they become habit – unnoticed, implicit and automatic. That is, until the rules are broken. The minute a player violates a rule, its existence springs into the conscious awareness of the athletes on the field, the coaches, the referees, and the fans. The whistle blows, the card is waved, and appropriate action is taken, so that the game can return to its smooth flow and the rules can fade into the background once again.

Holacracy works in much the same way. When you replace top-down leadership with a process, that process needs to be robust and sophisticated enough to keep everyone aligned and unified as they navigate the complexity of their daily business.

The constitution is formal and minutely detailed because it is designed to do precisely what a legal system is designed to do: to be the ultimate authority in a “government of laws, not of men.” Quoting Robertson again:

With Holacracy, distributing authority is not just a matter of taking power out of the hands of a leader and giving it to someone else or even to a group. Rather, the seat of power shifts from a person at the top to a process, which is defined in detail in a written constitution. Holacracy’s constitution is a generic document applicable to any organization wishing to use the method; once formally adopted, the Holacracy constitution acts as the core rulebook for the organization. Its rules and processes reign supreme, and trump even the person who adopted it. Like a constitutionally backed congress defining laws that even a president can’t ignore, so too does the Holacracy constitution define a seat of authority for the organization as resting in a legislative process, not an autocratic ruler.

If one views traditional hierarchy as a corrosive force that will seep back into an organization if there isn’t a sufficiently airtight alternative, then it becomes essential to have a procedure that’s robust enough to become the repository for authority and can serve as a bulwark against the reemergence of traditional hierarchy.

Let’s look at Holacracy through the lens of the four propositions:

• Holacracy establishes autonomy of execution (proposition 1), with mechanisms to surface and process “tensions” (“a gap between how things are and how they could be”) that ensure the owners of roles respond in tight, frequent ways to the externalities their decisions create for others
• Holacracy has no people managers (proposition 2). Different forms of performance management can be layered on top of the basic Holacracy “operating system” as “apps,” but in no case will one individual deploy, direct and evaluate another in the traditional boss-subordinate model
• Holacracy does not have autonomy of role selection (proposition 3) and instead has a formal and elaborate governance process by which roles are defined and people appointed to roles
• Holacracy creates a context in which enterprise-level strategy and objectives do not have the same stability and force they have in conventionally managed enterprises (proposition 4)

The Holacratic view of proposition 4 is important to evaluate. Robertson writes:

When you impose a “should” – as in “I should be X in five years’ time” – you create an attachment to that outcome; the attachment limits your ability to sense when reality is not going in that direction, or when other possible opportunities arise that might conflict with what you first set out to achieve.

Robertson explains that in Holacracy, where “a ground rule of governance is that any decision can be revisited at any time,” “… if you want to do conventional strategic planning, the Holacracy constitution certainly doesn’t prohibit it – but under Holacracy’s rules and processes, you will find it very difficult to drive others’ behaviors on the basis of targets defined in advance.” What takes the place of objectives, strategic concepts and plans are strategic rules of thumb that often take the form of “emphasize X, even over Y” (e.g., a Zappos strategic principle might, in my own words, be framed as: emphasize creating a personal connection with the customer, even over achieving the fastest and most efficient resolution of their problem).

What should we make of all this? It depends on one’s context, beliefs and priorities. To reach an evaluative perspective on Holacracy as a broadly applicable, baseline form of self-managing organization we should zoom in on a few considerations:

• Are the benefits of having a process air-tight enough to be the repository of ultimate authority sufficient to justify the burdens of adherence to the constitution (e.g., the learning curve to master the rules, the range of required meetings and documentation)?
• Are holacratic mechanisms for surfacing and processing tensions the most effective available mechanisms to make operating decisions?
• Is the “dynamic steering” approach Holacracy embodies preferable to steering approaches that attach greater weight to enterprise-level objectives and strategies?

As careful students of organizational design know well, most organizational design decisions are both features and bugs. Holacracy’s system of governance meetings and tactical meetings is designed to make an enterprise exquisitely responsive to tensions while also enabling individuals carrying out their roles the latitude to make operating decisions.

This is an elegant balance. The flip side of this elegant balance: elaborate roles, constrained formats for dialogue in meetings, difficulty setting or keeping a strong-form strategy (e.g., a strategy that could fulfill my formulation of “commitment to a destination and to core concepts that shape the choices for how to get there”).

Where is this set of benefits and trade-offs worth it? Obviously, this depends on what alternatives we’re evaluating Holacracy against. I do believe that there are a certain contexts in which more radical organizational forms like Valve’s, which embody all four propositions, can be set up to flourish. Radical forms of organization like Valve’s can also be used to create a “volunteer economy” that lives alongside the “directed economy” of a more hierarchical organizational system (e.g., 3M and Google).

For most organizations in most contexts, however, there’s a need for more structure than the Valve model creates.

Most of those who adopt or are drawn to Holacracy, however, aren’t considering moving all the way to a model like Valve’s. They’re drawn to be more self-managing than they are now, or than they perceive a traditional corporate model to be, and Holacracy represents a model that is sufficiently coherent and well-specified to be implementable. If the alternative is to cook up their own model for self-management, any coherent and well-specified model has significant advantages. To build on Robertson’s analogy to an operating system, I may not love Windows, but it is a lot better to use Windows than to try to build an alternative from scratch.

For all this, organizations that have at least one of the five attributes below are unlikely to find Holacracy their best alternative:

1. The organization highly values being able to make and deliver on durable commitments embodied in an enterprise strategy
2. The organization operates at a scale and complexity where the prospective volume of tensions becomes difficult to process laterally
3. The organization wants to unleash the energy and creativity self-management can deliver, but doesn’t need a process to be the ultimate store of authority (e.g., they perceive dangers from the misuse of authority, but not much from the mere fact of authority)
4. The organization cannot easily afford the disruption, cost and risk associated with the organization-wide learning curve of a new system of management with a heavy load of process requirements
5. A rules-based approach to management processes feels out of sync with their organization’s cultural values

Of course, an evangelist for Holacracy could argue that many leaders perceive factors like these five in distorted ways – overvalue the making of strategic commitments, overestimate the burdens of lateral processing of tensions, fail to appreciate the sense of flexibility and creativity that people feel once they’ve “learned the rules,” and so on. My objective here isn’t to take sides on these arguments, although my own view is that many leaders have good reasons to raise objections like these five. Rather, I’ll lay out in my next post another conception of self-management that can achieve the relevant benefits – in a way that fits the needs of a large range of organizations better than Holacracy can.