I often struggle with how to convey the history of Holacracy’s development in a way that honors both its many influences and the source of its novelty. The challenge stems in part from the sheer number of influences and the fact that Holacracy grew from the combined soup of all of them rather than extending any one or two direct predecessors. Yet a more significant challenge comes from the nature of Holacracy’s developmental process itself, and how different it is from what people often assume, myself included.
Many methods I run across seem to be created and refined by someone taking a set of ideas, or core principles, and constructing a system around them, to embody and express those principles. That’s how Holacracy’s development started too, in its early years (pre-constitution). At some point though, I began to realize that rules and methods stemming from my ideas and principles were actually getting in the way of my ultimate search for a better way to organize a company. As I might language it now, I was designing from mind, rather than liberating a more empirical design process guided by real tensions — like the leader who tries to apply a design to their organization, vs. letting the design emerge in the evolutionary process Holacracy instills.
To realize my ultimate goal, I had to give up on my ideas of what the system would look like, and what principles had to show up in it. I had to let go of my answers to better pay attention to my question. And my question was simply: In the context of working in an organization, what gets in the way of sensing something that could be better, and acting on that awareness to move things forward? And then: How can we evolve the fundamental system design to remove that obstacle? Without presuming an answer, my job became simply to experiment — to hypothesize an answer, test it in reality, get feedback, and then adapt the system further as I learned what worked. Rather than building “my idea” of how companies “should” run, I was searching for the most natural way to structure a system for processing individual tensions to express an organizational purpose.
The Holacracy constitution encodes the system that resulted from that experimental, evolution-fueled journey. And the result continues to surprise me — this is not the system I would have imagined, and I can extract principles from it that I never would have thought to instill into it in the first place. So, while I certainly played a central role in discovering and capturing the rules of Holacracy, I maintain that I did not create them; the process was more like discovering some basic laws of physics, through a lot of experimentation.
That discovery process is also an ongoing one — I’m under no illusion that we fully understand the most natural way to organize, and I believe it’s a moving target anyway, as humanity and technology continue to co-evolve. As of this writing, Holacracy is on version 4.0 — meaning the Holacracy constitution is on version 4.0 — and I have no doubt we’ll see future versions as we continue to evolve the rules of this game in light of real tensions that surface from the application of Holacracy. In fact, I already have many pages of nuanced notes covering tensions experienced by myself and others around the core rules of Holacracy in their actual application, all of which should provide great evolutionary fuel for Holacracy v5.0 and beyond.
With all of that framing out of the way, I’ll now share some of Holacracy’s backstory, especially in the early years prior to Holacracy v1.0, which I define as the launch of the first Holacracy Constitution in 2009. My goal is to give a sense of what led to it and what influenced it, as well as pay homage to the many thinkers, practitioners, methods, and models that provided grist for the mill of Holacracy’s evolution, and ultimately contributed to what it is today.
The Search For The Code
It’s difficult to say exactly when my search for the “code” of Holacracy truly began, but for the sake of starting my story somewhere, I’ll choose March of 2001. I had just quit a well-paying job and founded Ternary Software, a start-up that I would use as an experiment ground for new organizational methods for the next seven years. We went through several iterations of capturing that company’s purpose over those years. Most of them were variations around “build the healthiest possible system where people thrive”, which felt pretty true to the spirit of that company, though we eventually found the words I thought captured it best: “There’s Got to be a Better Way — Find it, Build it, Live it”. I started that company because I was hungry for better ways to work together, and I wanted a laboratory to find them.
In the early days of the company, my cofounders and I experimented with more conventional methods of running a post-conventional company. We discovered and captured our purpose, we defined company values, we focused incessantly on developing our culture around those values, we looked for every opportunity to empower people, to support people, to be more conscious leaders ourselves, and to create an atmosphere of learning and development. I devoured every book I could find on building a better and more empowering company culture, and the work of Jim Collins, Peter Senge, Barry Oshry, Patrick Lencioni, and several others were influential in these early days. I also did my best to integrate the lessons I learned from Linda Berens, a leader in the study of psychological type and harnessing individual differences across team members — many of our experiments were tested against the criteria of “does this integrate the core energies/strengths brought by all types of people, or bias towards just a subset?”
After a couple years of predominantly cultural experimentation, it became clear that we needed to focus at a process level as well — we were growing pretty quickly, and the lack of clarity in structure, process, and decision-making was becoming painful. I had been following the agile software development movement since its beginnings and saw it as a big leap forward, and that made it a natural starting point for a software company seeking novel ways to organize. So in 2003 we focused on integrating everything we could from the principles and practices of agile software development into the company. Agile calls for self-organizing teams with the power to make decisions about how they’ll work together to deliver results, so we structured the company as a collection of self-organizing teams and got out of their way as best we could. Agile calls for adaptive planning and responding to change vs. predictive planning and control mechanisms, and it offers lots of concrete processes to enact those principles at a software development level, so we adopted and adapted them for our context. Agile calls for visual project boards and information transparency, which we took to heart — our walls were floor-to-ceiling corkboards in some places, covered in useful project data. And agile calls for a feedback-driven evolutionary approach to design and delivery, for providing customers with an empirically-grounded and continuous flow of value, so we integrated that at the process level and instilled it in the culture.
The impact of our deep dive into agile software development went far beyond just “how we built software” — it infused our culture and gave us a foundation of principles and practices for the management of the company as well. Over the next several years, we’d do our best to express this paradigm in everything we did. Agile principles became a guidepost and a measurement for all of our future experimentation, as did the highly overlapping principles of the lean movement. Eventually, agile also seeded an appreciation of the incredible power and liberation that comes from discipline and clarity, and this was further reinforced and deepened by my own practice of David Allen’s Getting Things Done method (“GTD”), which began around this time as well. The search for deeper levels of discipline and clarity in organization would become a significant and ongoing driver for further process experimentation, and my understanding of their importance and potential began with experience from agile methods. The work of many practitioners in the space was likewise influential during this whole phase of absorbing and applying agile/lean principles and practices, including the writings and teachings of Kent Beck, Ken Schwaber, Jeff Sutherland, Mike Cohn, and Mary Poppendieck, among others.
In parallel with our focus on agile practices, we also began experimenting with various group facilitation and decision-making methods to enable more of the self-organization we sought. We started with techniques from the Facilitator’s Guide to Participatory Decision-Making by Sam Kaner, plus some of our own homegrown approaches derived from agile principles plus some of Peter Senge’s distinctions. These early experiments would ultimately lead to Holacracy’s integrative decision-making process, although getting there from this starting point would still be a long journey — and there were some really painful meetings along the way. One particularly memorable experience was attempting to set a company mission via a structured consensus process in late 2004. While it ultimately got us to a decent result, the pain of getting there was pretty intense. This left me hungry to find more efficient processes for integrating multiple perspectives, and some way of filtering down to those relevant to the organization’s purpose, while protecting it from the personal desires and egos always at play in any human endeavor.
As a next-step towards that goal, one of my co-founders googled “collaborative decision-making methods” in December of 2004, hoping to identify other processes to experiment with. From that search he discovered sociocracy, an organizational system developed in the 1960’s and 70’s by Gerard Endenberg, who experimented with alternate management techniques at an electrical company he ran in the Netherlands. There was much in common between sociocracy and what we were already doing at the time, plus some interesting ideas that were new to us. Our focus on self-organizing teams from agile methods also showed up in sociocracy under the language “circles” — this is where Holacracy’s use of the word originally came from, although the definition used in Holacracy today differs from sociocracy’s meaning. Sociocracy was also built around principles of enabling more adaptive steering, again similar to what we had taken from agile techniques — in fact, the same steering metaphor of a naturally weaving bicycle that I originally found in the agile community also showed up in one of the books on sociocracy. While sociocracy seemed to lack some of the depth and concrete implementations of these principles compared to what agile methods offered, it did serve up a novel idea I hadn’t seen anywhere else: the concept of an elected rep link, who would take part in a broader circle’s meetings. This idea proved quite useful in our experimentation and shows up in Holacracy to this day. Finally, sociocracy included a structured decision-making process based around reaching “consent”, which was similar to what we were already experimenting with at the time, but seemed more effective.
All of this looked promising, and I was excited we had found a system that captured and added to what we were already doing, which we had previously just called “The Ternary Way”. So, in January of 2005, we continued our experimentation by adopting sociocracy’s remaining practices, using the books Endenberg authored as our primary teacher and guide. This phase lasted throughout 2005 and into 2006, during which time I came to appreciate sociocracy as a great step forward in many ways, yet also not what I was ultimately searching for. Its consent-based threshold for decision-making and lack of criteria for what concerns were valid to bring into the process left lots of room for unconscious fusion of personal and organizational interests, and allowed everyday ego to infiltrate and slow down organizational decision-making. While sociocracy offered an inclusive and well-structured decision-making process, and a structural link for moving feedback up the organization, it left us in a heavily personal paradigm of organizing around the people vs. organizing around the work, at least not to the degree I had experienced from the highly pragmatic focus of our agile methods. Sociocracy also relies on a conventional management hierarchy and managers holding power outside of occasional special meetings where the consent process is used for every decision. While that was a step towards distributed authority for us, the lack of any kind of “pattern language” for defining where authority is held for day-to-day operational decisions was a major limitation to generating true organizational clarity, and prevented the differentiation of people and organization we were seeking. Of course no other process I knew of had fully tackled these issues either, so this wasn’t so much a failing of sociocracy as simply an unsolved challenge.
Overall, sociocracy offered us some great pieces of our puzzle and a nice next-step, yet it was limited to a management hierarchy wrapped with a consensus-like group decision-making process. The more I lived and worked in the environment it created, the more I came to believe I wouldn’t achieve my goal by either using a conventional management hierarchy nor anything that could be described as consensus-like. I sought a system that allowed more autonomy, more purpose-orientation, and more rapid decision-making and evolution than I could find with either top-down managers directing the action or a culture and process built around the “tyranny of consensus”, as I came to call the downside of the personally-oriented group decision-making methods I had experienced thus far, sociocracy included. With time and practice, I realized we’d need a more comprehensive organizational operating system that enabled clarifying and distributing role-based operational authority and expectations. Without authority distributed clearly into roles instead of a hierarchy of people, all we could fall back on was “the boss decides” or “the group decides”, neither of which I found very satisfying. I also realized we’d need a less personal process for defining these roles, with enough built in discrimination to ensure only organizationally-relevant perspectives impacted decision-making.
And so, as we began to look at changing core aspects of our process and developing significant new pieces, in early 2006 I realized continuing to call what we were doing “sociocracy” was misleading and inaccurate, and would become even more so as we rolled out our intended changes. We needed a name for the system we were building. After some brainstorming we landed on “Holacracy” as a leading contender, and then adopted it formally some months later. It captured the spirit we were looking for — governance of and by the organizational holarchy; through the people, but not of or for the people. It also had the benefit of being an entirely new made up word — there were exactly zero Google hits for “Holacracy” when we created it, which gave us an entirely blank slate to start conveying to the world our intended meaning of this new term, and what to expect from the operating system it branded.
Under this newly minted name, we continued experimenting and evolving our system throughout the rest of 2006 and for several more years before christening version 1.0 of the Holacracy Constitution. Most of our efforts at this stage were focused on two interrelated fronts. First, we began creating an organizational pattern language to capture a structure of clear roles with clear expectations and authorities, all differentiated from the people involved. And second, we began evolving the rules of the facilitated decision-making method we’d use to generate and evolve that organizational structure, to allow organizationally-relevant perspectives to impact the structure, but without ego or personal desires getting in the way. Our efforts to create a clear pattern language for organizational structure were influenced by several models, including Ken Wilber’s integral theory, which offered some great insights and distinctions around natural holarchies, and Elliott Jaques’ requisite organization model, which offered some great insights and distinctions around types of expectations and structures in organizations. We eventually landed on an initial version of the structure you see in Holacracy today, although the meaning of each element of a role definition wasn’t fully clarified until the Constitution was drafted. Even then, the “domain” field in particular and its significant effect on authority only really showed up in Constitution version 3.0 (under the name “Scope”), and wasn’t fully fleshed out until version 4.0. I’m not sure I’d classify earlier versions of Holacracy as a true distributed authority system, because domains form the basis of Holacracy’s system of property rights, and that’s a foundational component required for any society to truly respect the autonomy of its agents.
In addition to evolving Holacracy’s structure and pattern language, there was parallel development happening in its decision-making rules and process for governance. That evolution was driven mostly by my own observations and experimentation in practice, as there was no other work I found that offered much help — it seemed I was tackling a challenge that was subtly yet significantly different than what most other decision-making methods focused on. Eventually, I developed an early version of Holacracy’s integrative decision-making process; it used a series of mechanical steps that were similar to sociocracy’s consent process, but with different distinctions and rules within each, and a different facilitation style. These rules encoded Holacracy’s one-tension-at-a-time focus, the clear distinction of governance vs. operational outputs, and all the rules to sort out what tensions and objections are relevant for the organization to process now. A rough early version of this process would eventually appear in the first Holacracy Constitution years later, although it wasn’t until version 3.0 that the Constitution’s rules around objections got clear and detailed enough to capture them fully and move from a looser facilitation tradition to a concrete set of testable rules. Those rules would make another big evolutionary leap in Constitution v4.0, with the addition of rules of integration and rules for valid proposals, which further cemented an evolution-powered decision-making process that’s highly integrative yet less personal than anything else I’ve encountered.
For historical accuracy, I should mention that the experimentation described above during the pre-Constitution stage, from 2006 through 2008, was actually split across two organizations. The initial experimentation happened in Ternary Software, my software company where this experimentation originally began, and then it shifted almost entirely over to HolacracyOne, a new organization formed in early 2007 to further mature Holacracy and package it for use by other organizations. I began transitioning out of Ternary Software in late 2007 to join HolacracyOne full-time, to continue my efforts in an organization dedicated specifically to this work. For their role in supporting the early development towards Holacracy at Ternary Software, and for (mostly) putting up with me in the meantime, I’m particularly grateful to Anthony Moquin, who co-founded and built the company with me and served as a major thought partner, and then to my other co-founder and wife Alexia Bowers, as well as to our more process-focused agile software developers, Bill Schofield and Gareth Powell. It’s hard to pick just a few names to mention though — almost everyone in that company contributed to Holacracy in some way. They were all great sports, as the experimentation that eventually led to an elegant system was often not elegant itself.
Fortunately, my new business partner and co-founder of HolacracyOne had no qualms about joining in the messy experimentation process. In early 2007, Tom Thomison and I founded the company, and my wife Alexia joined us as well, to form the initial team of HolacracyOne and continue the work we had started at our software company. Tom was a serial entrepreneur I had met a year or so earlier who was also interested in better ways of working together as humans, and he acted as a near-perfect foil for my own energy and focus. He challenged Holacracy in ways no one else had, and forced us to get more clear with its rules and processes in several key areas. He also helped me personally differentiate from Holacracy in the same way Holacracy now helps founders differentiate from their organizations, which was critical to my being able to see it objectively enough to capture it in a written code. Ultimately, our working relationship was the primary catalyst for my drafting version 1.0 of the Holacracy Constitution in May of 2009. This forced me to pull together everything we were doing up until this point into a tangible and objectively-testable system and rule set. Even with all of its faults and missing pieces, this marked a huge milestone for us and allowed the system to be much more easily tested and further evolved.
It was at this point in 2009 — after the birth of Holacracy v1.0 and the Constitution — that Holacracy’s development really accelerated. Over the next several years we’d release a version 2.0, 2.1, 3.0, and 4.0, each with substantial evolutions to the core rule set, driven from on-the-ground tensions from experience in our organization and later with client companies. Holacracy’s tactical meeting structure was formalized as well, first as an add-on app to v2.0, and then formally incorporated into the Constitution in v3.0 — some of Patrick Lencioni’s work provided a basic blueprint that inspired this meeting structure and some of its core rules. It was also during this phase that I discovered and absorbed the work of Nassim Taleb and Eric Beinhocker, both of which deepened my own understanding of Holacracy’s significance and how to explain it, as did the work of many others.
Another major milestone achieved in version 3.0 was the deep integration of Holacracy’s authority structure with the core operational concepts and insights from David Allen’s Getting Things Done (GTD) method. I had been a GTD practitioner myself for many years at that point, and the exquisite clarity and purity of how David captured and conveyed the method was a huge inspiration and guidepost in my own work well before this point. GTD seemed to be profoundly “natural” — an inevitable discovery of the most effective way to process, organize, and respond to the world, given the nature of human mind and consciousness. It was an empirically discovered system and set of useful distinctions, not just a creation of mind coming from a specific mental model or value system. That’s exactly what I was seeking to uncover with Holacracy, and I think it was a disciplined GTD practice that first gave me a taste of what a method like that feels like, and a bar to measure Holacracy’s development against. And so when we finally fully bridged Holacracy and GTD in v3.0 of the Constitution, I was pretty ecstatic.
There were other significant shifts as well with each successive version, and while I’ve highlighted some of the bigger ones in this text, I think the sum total of Holacracy’s micro evolutions was at least as impactful. For each of the bigger leaps, we made dozens upon dozens of little tweaks in the rule set — to allow tension processing to flow a little more efficiently, or to make a type of tension easier to address, or to prevent some potential issue we found could occasionally gum up the works or slow things down. And as long as there are companies interested in applying the Constitution, tensions about Holacracy’s core rules will continue to surface and fuel its evolutionary journey.
Yet, I also sense a big shift coming in how this evolution happens. In many ways, I think Holacracy is outgrowing both me and HolacracyOne, and I suspect its future evolution will be driven more and more by its larger user community and the tensions they sense while applying the system in their organizations. Fortunately there’s a pretty amazing community springing up to carry it forward, and our role at HolacracyOne in the development of Holacracy and its Constitution is shifting from source to steward. That’s a new challenge we’re still in the process of orienting around, yet I’m not worried — evolution has a knack for finding just what’s needed, and I welcome its exquisitely ruthless gaze.
Brian J Robertson
Birchrunville, Pennsylvania
June 2014
