Holacracy or Humacracy? (Book Review)

Holacracy has been on my radar for the last couple of years as an organizational paradigm that’s worth further exploration. I’ve covered some pieces of it on this blog as well.

I was thrilled to learn that Brian Robertson, Holacracy’s creator, has finally written a book about it, and was really looking forward to reading it:

Holacracy: The New Management System for a Rapidly Changing World

If you have no idea what Holacracy is, I won’t suggest jumping straight to the book, but starting with this short article instead:

Here’s Why You Should Care About Holacracy

The book provides the most holistic, yet still readable, description of what Holacracy is really all about (pun intended). Though it still leaves much to be desired (which we’ll get to in a second), it does a great job illustrating how governance and tactical meetings work and touching on some of the less known aspects of Holacracy such as its approach to strategy and to deadlines, both strongly resonating with me. The aspect that would have probably benefited the most from further exploration is the circle-based org structure. It doesn’t address some of the key org design challenges that exist in traditional hierarchical structures, like the need to alternate organization and focus by function, product/service and customer/region. It also enacts a meaningful organizational constraints that doesn’t get acknowledged: if each sub-circle is represented in governance and tactical meetings by both a lead-link and a rep-link, it puts the limit on the number of sub-circles within a circle at about 4-5. Otherwise the number of people attending the meeting quickly jumps to over 10 people, which makes them exponentially more challenging to run.

Sadly, my high level takeaway is that Holacracy is an exciting but incomplete paradigm. And there’s some reason for pessimism since this omission was made by design. Let me explain:

Many of the principles and concepts that Holacracy is based on and consists of strongly resonate with me: roles as living and evolving entities, the radical distribution of authority through the circles-based org structure, the unique and highly effective governance and tactical meeting structure, even thinking about strategy as a set of heuristics rather than a high-level, executable plan.

The one principle that Holacracy takes too far, in my opinion, is the decoupling of “role from soul”. Holacracy accurately observes that under the traditional paradigm, four “spaces” are too tightly coupled:  the person space, the role space, the tribe space and the organization space. A good example is the traditional manager’s job being simultaneously responsible for both for the business outcomes accomplished by her employee (role space) and her employee’s professional growth and development (person space). The solution that Holacracy prescribes is radical decoupling, ignoring the fact that in cases of extreme decoupling, misalignment will lead to chaos. Holacracy explicitly takes the “human spaces” (left column, person+tribe) out of scope:


Or, to use a more familiar diagram to the readers of this blog:


Dealing with “human spaces” problems such as hiring/firing, compensation, growth, etc. is not part of the Holacracy “operating systems” but mere “add-ons/apps” that each business should figure out on its own, once they adopt Holacracy. Yet at the same time, it’s been acknowledged that Holacracy is at odds with traditional “human spaces” solutions, and the friction between the two is a key cause for some companies attempting to adopt Holacracy but failing to successfully do so. To go back to our manager example, Holacracy offers clear guidance on what to do with half of her traditional responsibilities, but leaves practitioners completely on their own about the other half. To me, that sounds like a classic case of mistaking a bug for a feature.

A fix for this bug, would require viewing the organization as a sociotechnical system, acknowledging that it has a human component that cannot be fully decoupled. The human systems that align with the process components of Holacracy have to be an integral part of the Holacracy “operating system” rather than an add-on “app”.

Note that none of this invalidates any other principles and concepts that are already an integral part of Holacracy. I am confident that Holacracy is a superior organizational paradigm compared to the traditional one. I’m just disappointed that its creators decided to “call it done” and draw the operating system/apps line where they did. I fear that only addressing half of the problem space will have a substantial negative impact on its adoption (and success) rate. To use another software metaphor, they seem to be building the right product, I’m just not sure they have a Minimum Viable Product. Yet.

Holacracy or Humacracy? (Book Review)

6 thoughts on “Holacracy or Humacracy? (Book Review)

  1. Hi Itamar. I work with HolacracyOne and your article caught my eye. Great review, thank you! I want to clarify that far from us to “call Holacracy done” without key business apps — in fact, it’s now one of our main focus to develop a suite of ‘apps’ that can replace key business process like compensation, hiring/firing, etc. I think they will still stay at the level of ‘apps’, versus being incorporated in the Holacracy constitution, but they should equally address this gap that you’re rightly sensing.



    1. Hi Olivier,
      Thanks for commenting and clarifying. I think I understand Holacracy’s perspective on this, I just disagree with it 🙂
      Holacracy makes a concerted effort to create as much separation as possible between the “human” and the “organization”. Under that paradigm, it makes sense to group HR processes in the same bucket as other business processes (like procurement, planning, vendor mgmt, etc.) and call them apps that sit on top of the Operating System.
      I believe that trying to create such aggressive decoupling is fundamentally flawed. The fact that the organization consists of humans rather than machines dramatically impacts the way the organization functions. Rather than trying to make the organization as machine-like as possible, the Operating System must account for that attribute of the system or risk sub-optimal performance at best or a sever case of transplant rejection (to use a more human metaphor) at worst. If you can spare an hour, check out this talk by Jabe Bloom: https://www.youtube.com/watch?v=cA_c6Xo806g I think it does a better job articulating my perspective than me.


  2. I like where they drew the line, people systems and incentive systems are the most likely to be affected by regional legal requirements.

    Putting people systems and incentive systems into the core of Holacracy (the constitution) would be like embedding a photo editor in the linux kernel.


    1. Hi DJW,
      I believe the legal requirements put some constrains on these systems, but there’s a large enough shared core that’s not impacted, specifically around the parts that matter the most.
      The debate, however, is deeper than that. The “Operating System” metaphor breaks down when you take it one level further and view organizations as computers. Systems consisting of humans have fundamentally different attributes compared to systems consisting of inanimate, deterministic objects. If we stick to the tech metaphors, these human systems are closer to hardware drivers than a photo editor 🙂


      1. >The debate, however, is deeper than that. The “Operating System” metaphor breaks down when you take it one level further and view organizations as computers.
        You brought up software, I just ran with it.

        About your broader post, I have read similar arguments before, Steve Denning was complaining about not seeing “The Customer” in the core of Holacracy. It seems that when people read about the separation between the core OS (the constitution) and Apps (governance output) and something they believe is important is in the application layer they get all bent out of shape. It is as if being or not being in the core is an indicator of importance.
        For brevity:
        * Core = Things that do not need to vary between Holacracies and support the Apps (Bones)
        * Apps = Things that need to vary between Holacracies and with an individual Holacracy over time (Muscles & Tendons)
        Both are vital to a successful implementation.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s