Experiments with Holacracy: Why we stopped doing it, and what we learned along the way.
My colleague Minke’s recent article ‘Getting started as an employee experience chief’ triggered some questions about why we at Organize Agile abandoned Holacracy. It’s not an easy question to answer and while I have my own thoughts on the subject I also asked my coworkers to offer their opinions. This article will offer some insights from our journey, what Holacracy did (and didn’t do) for us, and some learnings should you want to start your own Holacracy experiment.
If you’re unfamiliar with Holacracy, I like to describe it as a way to constantly reorganize and refactor your organization. While it might seem terrible to work in an organization that is constantly reorganizing itself, the point of course is that by constantly changing, change becomes an incremental process rather than occasional and infrequent shock therapy. Ideally, Holacracy makes organizational change easy and helps to ensure your organization is always in tune with what outside forces and the people in the organization demand of it.
Key to this is the concept of a ‘tension’; something in the organization that isn’t quite right, could be better, or is simply missing altogether or superfluous. Anyone can signal a tension and can offer a proposal on how to address the issue. Such a solution might be to assign a new responsibility to a pre-existing role, create a new role, or change an organization policy. To discuss and decide on tensions and solutions Holacracy uses clearly structured governance- and tactical meetings.
Roles are not the same thing as job descriptions, rather they are flexible things that can be created, adapted or disbanded according to the organizations needs. Similar roles or roles that contribute to a shared purpose are grouped together in a ‘circle’. An organization is therefore likely to consist of one main circle with several subcircles. People can have multiple roles at any given time, meaning they should be able to use all their talents and carry all manner of responsibilities, rather than just do what is in their job description. We tried to keep things pretty light-hearted. Minke’s quite seriously named Employee Experience Chief role was contrasted by an IT Troll (one of my roles, basically responsible for making sure we had the right hardware such as phones and laptops), and a Metrics Monster (One of Mikel’s roles responsible for helping us work in a data-informed way).
Crucially, Holacracy is also about distribution of power. To do ‘pure Holacracy’ is to have the owners of a company relinquish their power over it by signing a ‘constitution’. It therefore goes beyond self organization into the realm of self-management.
Should you want to read more about Holacracy, ’Holacracy’ by Brian Robertson and ‘Getting teams done’ by Diederick Janse and Marco Bogers (In Dutch) are good places to start, although I found ‘Holacracy’ a pretty tough read. Alternatively, there is the Holacracy blog.
What did Holacracy ever do for us?
I’m not out to bash Holacracy. We stopped doing it, but before we did, it helped us do many things. So to paraphrase Monty Python: What did Holacracy ever do for us?
Like Agile, Holacracy doesn’t solve all your problems, but it is pretty good at making them visible. Holacracy’s meeting structure and the concept of tensions helped us to bring issues to the surface and forced us to have a conversation about them, even when sometimes maybe we didn’t really want to.
Some of the things it forced us to discuss where our company values, strategies and policies. Any mismatch between them would often result in a ‘tension’ which we would then have to resolve. That wasn’t always easy but at least we were actively discussing them. We also found many of our company policies were implicit. ‘Everybody knows this, right?’ Making our policies explicit definitely raised the quality of our work and helped us to build a culture by doing certain things the same way.
Explicit policies also proved valuable when on-boarding new people, it gave them (including me) something to fall back on. Please note, our entire policy book consists of a thirty row excel sheet, so it’s pretty lightweight.
The Holacracy meeting structure also allowed us to involve everyone in our governance process. We’re not a large organization but it is still nice to be able to use everyone’s knowledge and experience when dealing with something. Holaractic meetings can give everyone a voice.
When our strategy was in flux we were constantly able to adapt the organization to this. Don’t get me wrong, this still hurt, but it gave us a mechanism for clearing up organizational debt.
Finally, we never became stagnant. My favorite thing about Holacracy is that it’s an anti-consensus model. Rather than not deciding anything Holacracy helped us make a decision and experiment with a solution to a tension. If a solution proved ineffective we could always bring up a new tension next week (and we often did).
So in fairness, Holacracy gave us lots. So why did we abandon it?
Why did we stop?
There is not a single reason why we stopped doing Holacracy, rather there are many reasons both large and small which added up to the disadvantages outweighing the benefits. These disadvantages were not necessarily caused by Holacracy, rather they are what we experienced when we used it.
By using Holacracy we sometimes ended up trying to address an issue by assigning a new responsibility to a role or changing a company policy. Sometimes there is another way; simply solve the problem. Holacracy does allow ‘one of- actions’ and you can ask a role to pick up an issue but having a framework for discussing tensions in place sometimes resulted in waiting for the next governance meeting to address something when it could have been solved well before then. In other words in some cases we allowed Holacracy’s framework to limit our thinking in coming up with the right solution.
One such solution we tended to forget about was leveraged assets, meaning simply hire someone or some organization to do the job for us. We moved certain responsibilities between roles (even several times), or sometimes created new ones to solve problems that would have been easier to solve by outsourcing rather than by trying to finetune our internal division of responsibilities.
In Holacracy tensions are dealt with by proposals that can create or adapt roles or policies. If there are objections to such a proposal these need to be validated and if proven valid they need to be taken into account. In our Organization process the validation process created its own tensions. A colleague would have an objection to a proposal but would know from experience this would not be a valid objection. This resulted in people not even bringing up these objections, or already mentioning that they would not be valid. It didn’t make for a very constructive debates and was a cause for some rumbling in the undercurrent of our organization.
Holacracy is also about how power is divided in an organization. It can energize an organization by giving individuals the power and mandate to act. However, we sometimes ran into friction when a role would clash with the implicit hierarchy in our company. It is all very well to put to paper what role is responsible for what but at some point that can clash with what founders (who still own the company) feel the organization should do. This can be partially tackled by giving them the Lead link role, but it doesn’t solve everything. Distribution of power is not just about (explicit) power structures, but also what’s going on beneath the surface.
A key thing my colleague Jens mentioned is the nature of our company. We are a consultancy company, and spend most of our time with our clients. Friday is the only day we all always spend at our own office, in order to work on our shared backlog, share knowledge and improve as an organization. As such governance and tactical meetings were quite a drain on our time. Our time together is very precious to us and we do not take kindly to unnecessary overhead.
Last but not least. We are a company of Agile Coaches, and it shows. Meaning, we tend to have an opinion on pretty much anything, especially on anything in the realms of process, governance and decision making. Our meetings sometimes devolved into soul-sucking discussions. Especially when people felt strongly about issues, and personal tensions might get mixed up with professional ones or elevated to the level of team tensions. I have facilitated my fair share of our tactical and governance meetings and some of those rank among the most difficult sessions I have ever facilitated. I tried following both the process to the letter and being more lenient with the rules, both created issues. It was very hard to get right.
I am fully aware that most of the things above were at least partially our own mistakes, but here’s the thing: Holacracy as a framework should have helped us make our lives, and organizational governance, easier. It did not. Holacracy is anything but simple, and the holacratic road is riddled with pitfalls. Maybe we simply were not good enough, but I believe there are simpler ways to achieve what we set out to do with Holacracy, one of them is organizing ourselves into Agile teams and working from a shared backlog.
How did we stop?
We didn’t just stop doing Holacracy overnight. In fact, for a long time we weren’t even sure whether we had actually stopped doing it. The roles were still there, but we stopped having regular tactical and governance meetings. Basically Holacracy was slowly bleeding out.
We found for instance that administrative roles, or components thereof had all ended up with our Office Manager. Theoretically we could still move these roles to another person, but we never did. In other words, these roles had become waste because in reality they corresponded to a job description.
It took us a long time to make the decision explicit but eventually we decided to formalize what in reality we stopped doing for a while.
What are we doing now?
We still use roles in our company, but there are far fewer than there used to be. We love the flexibility roles offer, but not everything should be a role. For instance, Minke, one of our Agile coaches, has taken on the role of Employee Experience Chief, but most of our colleagues no longer have ‘extra’ roles besides their regular job of Agile Coach.
We have learned from our mistakes and have explicitly given Minke time to fulfill her role. Also we will evaluate her performance in this role on a set date. Not to judge her, but to help her and our organization improve. In doing so we have also shifted towards Sociocracy 3.0. Where Holacracy felt very formalistic, this feels more human to us. It allows more space for discussion but isn’t soft.
One of the key concepts that allows us to keep our momentum is ‘good enough for now, safe enough to try’. Instead of wanting to get everything right, this helps us to take a more experimental approach. Something that is close to our hearts, but was sometimes lost along the way.
Putting responsibilities in roles meant work was often done by individuals. As mentioned elsewhere we now use our own stable agile teams to do our development and maintenance work in a structure that could be described as a very lightweight version of LeSS.
Combining elements of Sociocracy 3.0 and stable agile teams allows us to have the benefits of flexible roles, but also simply get stuff done. We still have all sorts of discussions, but the focus has returned to delivering value.
Conclusions, and is Holacracy right for your Organization?
I still like Holacracy, my favorite bit about it is that it is basically an anti-consensus model. It allowed us to be a different organization pretty much every week and experiment rather than get stuck merely talking. ‘Doing’ holacracy is definitely not easy though and bits of it feel overly restrictive to me. Conceptually it is very strong, but execution is hard and to my mind many of its goals can be achieved in simpler ways.
In some ways Holacracy reminds me of yoga. Can yoga help you become more limber? Maybe. Probably. But quite possibly yoga is suited most to people who are already very limber. In the same vein Holacracy can help you become more agile and responsive to change, however it is probably best implemented by organizations that are already very agile. Starting to do Holacracy in an organization that is not ready for it is likely to result in accidents.