Agile Coach at Nomad8 and Agile Encore speaker Sandy Mamoli shares her story of implementing Holacracy at a New Zealand tech company, whose CTO gave her a one-line instruction: “I’d like you to make it happen.”
At Snapper, a New Zealand-based transport ticketing service provider, things were going well. There was a culture of collaboration and respect, and a true passion for transport. People were respected and in control of how they worked.
But the company had an eye on the future and knew there were challenges ahead.
Snapper foresaw success and growth – and were well aware of the pitfalls involved in scaling up. So they wanted a foundation that would let them add people without adding pain.
They were drawn to Holacracy by its promise of better collaboration. Radical transparency, decision making at the right level, and dynamic organisation all seemed right.
They were also attracted to the potential of baked-in continuous improvement. In Holacracy each team (circle) and role are responsible for their own development. As the CTO pointed out, if you have 50 people each making one small change a quarter, it adds up to 600 small improvements a year – and all through a cultural process driven by the people, rather than a top-down mandate.
What is Holacracy?
Holacracy is a method of decentralised management and organisational governance in which authority and decision-making are distributed throughout autonomous, self-organising teams (circles). Alignment is achieved through a hierarchy of nested circles in which each higher circle defines the purpose for its lower circle(s). Decisions are made by consent, i.e. the absence of objections, rather than majority voting.
Holacracy has been developed by Brian Robertson, a US entrepreneur, who has codified the system in a now open-sourced constitution. It is based heavily on the Dutch system of Sociocracy which has been implemented in companies since the 1960s. Holacracy and its root method Sociocracy have been adopted by for-profit and non-profit organisations in several countries.
I’d worked with Snapper in the past and they asked me back to help them introduce and embed Holacracy. We all went into it with an open mind, the Holacracy constitution, and a copy of Brian Robertson’s book Holacracy.
We began to induct our circles: defining each circle’s purpose, domains and accountabilities. We created granular roles and got ready to have people fill our newly created roles. So far, so good. I fully expected to be done in a month or so. How hard could it be?
Very hard, as it turned out. We had 50 people, each with different degrees of understanding of Holacracy, trying to figure out a radical organisational change – and it got messier than we expected.
Img1: Snapper circles
People found it confusing and didn’t like the legal language and rigid rules that felt at odds with their organisational culture. And while most people understood why we were introducing Holacracy, they didn’t have a clear picture of how things would work once it was in place.
We knew we needed to figure this out if Holacracy were to survive. We decided to step back, regroup, and start over with a strict implementation that followed the rules to the letter. We wanted to try everything as it was designed to be, and then make changes from a position of knowledge and experience rather than because we found a practice too hard to implement.
Circles and roles are two central concepts in Holacracy: Circles are teams that have a purpose and accountabilities and consist of roles that support the circle’s purpose. Once the roles are defined, they are filled: because roles have a single purpose and are quite small and granular in nature, each person usually fills several roles.
Here’s an example of a Holacracy role:
We started our role definitions by looking at what people were currently doing on a daily basis and abstracting roles from their tasks. We then collectively assessed and agreed on all roles for a circle. At the time, this process felt tedious and time-consuming and our meetings can best be described as extremely painful.
But the effort paid off. The process forced us to think about what we were actually doing versus what we should be doing. We realised that many of us were spending a lot of time on detail and lower-value aspects of our jobs. Some of the coaches, for example, were spending up to 70% of their time doing hands-on work rather than coaching others.
Defining roles created clarity and helped us focus on the important parts of our work. It made it possible to split what had been one job held by one person into several smaller roles that could be offered to different and appropriate people. We considered that a win!
We started off running our meetings exactly as described by Holacracy. During our first meetings we had to look up the rules in the constitution many times. We found them confusing and ambiguous but after a couple of months we got the hang of the mechanics and our meetings started to follow the official Holacracy process more naturally.
But there was a problem – the meetings were horrible. They were tedious and unengaging and the prescribed format, which was strictly enforced by the recommended tools Holaspirit and Glassfrog, felt stifling and contrived.
Tactical meetings in particular became tense as we worked through a list of projects in round-robin fashion, giving each other status updates that no one wanted. The meetings seemed to hinder rather than help our collaboration.
Tensions are the real power of Holacracy. A tension is the gap between what is and what could be. By that definition, a tension is a very positive thing. Sensing a tension and proposing an improvement is what propels circles and companies forward and ensures continuous improvement.
Identifying and processing tensions produced great results. Holacracy provided visibility of people’s areas of work (domains), which allowed us to see when something could be improved. People realised that they had the power to improve the areas they worked in, and that once a problem had been identified by the domain holder it could be solved with input from many contributors.
In the beginning, we found it was important to keep the definition of a tension in mind – a gap between what is and what could be – and to remember that tensions are opportunities, not negatives.
Making it work
There were clearly some things that weren’t working for us but overall we felt we were on the right track and that Holacracy had huge potential. After three months we felt ready to make some changes.
Changes to meetings
The first change was to stop using Holaspirit to drive meetings. It drove us crazy that the tool was policing our collaboration: we couldn’t just agree on something and then update Holaspirit for documentation purposes, the tool forced us to follow the entire process again. It was stifling and we felt instant relief when we stopped using it to run meetings.
We also loosened up the process. Our tactical meetings are now free-format and we always remember the purpose: collaboration and discussing ideas people want to share and get input on. How we do this differs from meeting to meeting, which keeps it purposeful and interesting. All our meetings are optional.
For governance meetings we use Holacracy’s process to make decisions by consent. Consent is one of the most powerful aspects of Holacracy and it has helped us to make decisions quickly and well. We don’t always follow the exact governance meeting format. We know each other well, know how to collaborate, and are good at communicating, so we can now be guided by principles rather than using process to police our collaboration.
Living with the language
We all felt weird about the legalese language of Holacracy at first. But then we remembered we’d had similar issues back in 2010 when we introduced Agile. People found Agile terms strange in the beginning, wondering, for example, why we couldn’t just call a product owner a project manager if the roles were so similar?
We realised that new concepts need new words and that using existing terms would hinder our grasp of new ideas. So we decided to stick with the language and get used to the new terms like circle, tension and linking. Over time we lost our ‘new terminology’ awkwardness and now use many Holacracy terms naturally. We’ve also started explaining the concepts and ideas behind Holacracy in more relatable language, while still using the correct terminology overall.
Following the principles
For us, Holacracy is a system we employ to support principles and values we agree with, such as distributed leadership, accountability, continuous improvement and transparency.
But it’s easy to lose sight of the principles and become obsessed with the system itself when there are so many rules in the constitution. In Agile terms it’s like the difference between “being Agile” and “doing Agile”. When we face this problem in the Agile world we resort to the Agile manifesto and its associated 12 principles for guidance.
So, we decided to do the same thing here and focus on the principles. It gave us something we could evaluate decisions against and allowed us to communicate the essence of Holacracy to the rest of the organisation in a clear and concise manner.
9 months in
Snapper are now running Holacracy across the organisation and are on track to achieve what they set out to do. People like it and want to keep running it: the learning curve was worth it.
We’ve seen how powerful Holacracy can be to drive continuous improvement, provide clarity and visibility across an organisation, and get decisions made quickly with the right people involved.
Holacracy today feels a bit like the early days of Agile and Scrum 1.0. The frameworks will change and the guidelines will be updated as we learn more and gain more experience. But it’s exciting to be part of something emergent and I believe Holacracy, mixed with Agile and a good dose of common sense, will make a huge difference to organisations.
You can hear Sandy Mamoli’s highly-rated AgileAus 2017 talk, ‘How the Olympics can make you a better person’, at Agile Encore this November in Sydney and Melbourne. Find out more online: www.agileencore.com.