For the past eight months, we’ve been implementing Holacracy. I think it’s great, and we’re going to continue using it at UC. Last week, I posted four great things about Holacracy. Today, I offer four things I could do without.
1. Confusing word choices
Having a shared pattern language for describing the organization is crucially important. But the language provided by Holacracy is hard to use. A sample:
- “Tension” is a word that, in business contexts, leads people to think about issues instead of opportunities. Why not “Data”, “Opportunity”, or “Issue”?
- “Circle” has some nice meaning and history, but it’s a head-scratcher for most: why not just say, “Team”?
- Calling a “Governance” meeting guides people to think in legal, anti-human terms; we end up proposing changes to our organization like shitty lawyers with no experience writing policy, tossing “shall” and “whereas” around like we own the joint.
- And for what it’s worth, “Lead Link” and “Rep Link” are almost always accompanied by air quotes. Why not “Leader” and “Representative”?
Word choice is important. To play the game, you have to understand the terminology. And many of the words included in the system reinforce bad behavior.
What to do: Re-think every defined term in the system with a user-focused lens.
2. The Constitution
It’s too long, mostly because it’s written in a dense, unapproachable style that comes from its intended use: to be adopted as an addition to the operating agreement of a company. The length and density of the content effectively makes Holacracy a product for org-design masters, and limits its applicability at the edge of an organization. If you can’t commit the rules of the game to memory, it’s going to be hard for the game to spread.
For example, here’s a core concept of the system, as expressed in the constitution:
4.2.2 Requests for Processing. Each Circle Member of a Circle shall engage in any processing required under Section 1.2 promptly upon a request made by a fellow Circle Member to so process a specified Accountability or Project. To the extent the Circle Member receiving such a request has no Next-Actions tracked with respect to the specific Accountability or Project so requested for processing, such Circle Member shall continue processing until such a Next-Action is identified and captured, unless such Circle Member can instead reference (a) a specific Next-Action or Project explicitly captured and tracked by another Role that must be completed before any further Next-Actions are reasonably appropriate to enact the Accountability or advance the Project so requested for processing, or (b) a specific event or trigger condition beyond the reasonable influence of such Circle Member that must happen before any further Next-Actions will be reasonably able to enact the Accountability or advance the Project so requested for processing. In any case, a Circle Member so processing upon request shall inform such requester of the results of such processing.
Here’s a minimally lossy version of that: “When a teammate asks you to process an Accountability that you hold, we expect you to consider writing down an action associated with that Accountability.”
I’ll grant you that many games have long, extensive rulesets – the NBA’s rules are hella long, for example – and I’ll also allow that rules are crucial to the functioning of the system. I’d just say that the constitution as written impedes the adoption of Holacracy.
What to do: Radically simplify the constitution. Write it for people, not for wonks.
3. Dogma
Just to take the first bit from Dogma from Wikipedia: “Dogma is a principle or set of principles laid down by an authority as incontrovertibly true. It serves as part of the primary basis of an ideology, nationalism or belief system, and it cannot be changed or discarded without affecting the very system’s paradigm, or the ideology itself.”
I think of dogma inside the Holacracy system in a couple of ways.
First: it’s an all-or-nothing proposition. As we were getting trained up on the system, it’s clear that there is a “right way” and a wrong way. A pretty good portion of the final day of the training was devoted to a discussion on the incontrovertibility of the system; to practice a bit of Holacracy was to fail at it.
Second: there’s a single, central source of knowledge. Local derivations of the practice (“house rules”) can be built into local constitutions, but there’s no clear process for incorporating those adaptations into the broader system. True, there’s a community of practice, but it’s a paid forum – hardly the type of open, branch-edit-commit communication norms that one would expect at the leading edge of a movement. And yes, all companies using the system could open up their Glassfrog accounts (make them public), but the secret sauce isn’t the record of governance, it’s what worked and didn’t. It’s the flexing of the constitution. It’s the house rules. Because the structure can change so quickly, the stuff that doesn’t work is as important as the stuff that does.
What to do: Accept that there is a massive amount of variation possible in the system, and that this has historically been a good thing. Encourage users to try new ways of operating, and see what emerges.
Which brings me to the next point.
4. Closed-source
This is the big one for me.
For better or worse, I expect the systems around me to be tended by an open-source community. The blog you’re reading this on started in 2006, originally hosted on version 2.0 of WordPress. WordPress has seen 17 major releases since then. The open-source community behind WordPress has made it an undeniably powerful tool that will be around long after Squarespace, Tumblr and Typepad are dead (much love).
Holacracy, by contrast, is closed-source: its constitution is released under the Attribution, Non-Commercial, No Derivatives Creative Commons license, which effectively prevents me from publishing my own updates to it – even if I don’t sell those updates. This is a major, always-in-the-back-of-my-head disincentive against using the system, but broadly means that the system isn’t able to be moved forward by the community. Instead, we rely on HolacracyOne’s founder, Brian Robertson to “[Draft] successive versions of the Holacracy Constitution to concretize and formalize effective patterns and core best-practices that have emerged in the practice and application of Holacracy.”
I can’t handle the idea that the core system that undergirds Undercurrent’s business will be updated when its editor has the time. To wit: at the training, the projection that I got for the next release was in the next two years. That’s too slow, in a world where Oculus Rift can go from Kickstarter campaign to functional hardware to $2bn exit in the same amount of time.
What to do: Put the constitution on Github. Let it free. Kill the licensing program and get really good at making software to support the practice.
For the past eight months, we’ve been implementing Holacracy. I think it’s great, and we’re going to continue using it at UC. Last week, I posted four great things about Holacracy. Today, I offer four things I could do without.
1. Confusing word choices
Having a shared pattern language for describing the organization is crucially important. But the language provided by Holacracy is hard to use. A sample:
Word choice is important. To play the game, you have to understand the terminology. And many of the words included in the system reinforce bad behavior.
What to do: Re-think every defined term in the system with a user-focused lens.
2. The Constitution
It’s too long, mostly because it’s written in a dense, unapproachable style that comes from its intended use: to be adopted as an addition to the operating agreement of a company. The length and density of the content effectively makes Holacracy a product for org-design masters, and limits its applicability at the edge of an organization. If you can’t commit the rules of the game to memory, it’s going to be hard for the game to spread.
For example, here’s a core concept of the system, as expressed in the constitution:
Here’s a minimally lossy version of that: “When a teammate asks you to process an Accountability that you hold, we expect you to consider writing down an action associated with that Accountability.”
I’ll grant you that many games have long, extensive rulesets – the NBA’s rules are hella long, for example – and I’ll also allow that rules are crucial to the functioning of the system. I’d just say that the constitution as written impedes the adoption of Holacracy.
What to do: Radically simplify the constitution. Write it for people, not for wonks.
3. Dogma
Just to take the first bit from Dogma from Wikipedia: “Dogma is a principle or set of principles laid down by an authority as incontrovertibly true. It serves as part of the primary basis of an ideology, nationalism or belief system, and it cannot be changed or discarded without affecting the very system’s paradigm, or the ideology itself.”
I think of dogma inside the Holacracy system in a couple of ways.
First: it’s an all-or-nothing proposition. As we were getting trained up on the system, it’s clear that there is a “right way” and a wrong way. A pretty good portion of the final day of the training was devoted to a discussion on the incontrovertibility of the system; to practice a bit of Holacracy was to fail at it.
Second: there’s a single, central source of knowledge. Local derivations of the practice (“house rules”) can be built into local constitutions, but there’s no clear process for incorporating those adaptations into the broader system. True, there’s a community of practice, but it’s a paid forum – hardly the type of open, branch-edit-commit communication norms that one would expect at the leading edge of a movement. And yes, all companies using the system could open up their Glassfrog accounts (make them public), but the secret sauce isn’t the record of governance, it’s what worked and didn’t. It’s the flexing of the constitution. It’s the house rules. Because the structure can change so quickly, the stuff that doesn’t work is as important as the stuff that does.
What to do: Accept that there is a massive amount of variation possible in the system, and that this has historically been a good thing. Encourage users to try new ways of operating, and see what emerges.
Which brings me to the next point.
4. Closed-source
This is the big one for me.
For better or worse, I expect the systems around me to be tended by an open-source community. The blog you’re reading this on started in 2006, originally hosted on version 2.0 of WordPress. WordPress has seen 17 major releases since then. The open-source community behind WordPress has made it an undeniably powerful tool that will be around long after Squarespace, Tumblr and Typepad are dead (much love).
Holacracy, by contrast, is closed-source: its constitution is released under the Attribution, Non-Commercial, No Derivatives Creative Commons license, which effectively prevents me from publishing my own updates to it – even if I don’t sell those updates. This is a major, always-in-the-back-of-my-head disincentive against using the system, but broadly means that the system isn’t able to be moved forward by the community. Instead, we rely on HolacracyOne’s founder, Brian Robertson to “[Draft] successive versions of the Holacracy Constitution to concretize and formalize effective patterns and core best-practices that have emerged in the practice and application of Holacracy.”
I can’t handle the idea that the core system that undergirds Undercurrent’s business will be updated when its editor has the time. To wit: at the training, the projection that I got for the next release was in the next two years. That’s too slow, in a world where Oculus Rift can go from Kickstarter campaign to functional hardware to $2bn exit in the same amount of time.
What to do: Put the constitution on Github. Let it free. Kill the licensing program and get really good at making software to support the practice.
Read Next
Five Org Design Things N° 10
Pattern languages and org analysis; RTO is bad, even if offices are good; old maps made 3D; diverging values worldwide; exit interviews
Five Creativity Things
Challenges facing creativity; owning ideas from beginning to end; opinionated palettes; are we doing zines again?; randomness that didn’t fit in the first four categories
How to Combine Pace Layers, Org Design, and Strategy
4 ways to use Pace Layers in strategy and OD work: 🚀 As a career planning tool; 🎓 As a strategy tool; 🔬 As a diagnostic or sense-making tool; 🎨 As a design tool for value-adding layers.
Five Org Design Things N° 9
Organizational health essential for firm performance; Avinsa; the heat death of Google; team performance research; platform teams @ PepsiCo