Holacracy for Humans

Dec 05, 2017 · Sandy Mamoli

How we created a networked organisation

5 Key take-aways

Holacracy provides radical transparency and timely decision making at the right level. Decision making by consent is awesome!

The freedom, autonomy and responsibility to achieve a clear purpose enables self-organisation.

Holacracy will amplify the culture that's already in place. It won’t change or improve it!

Start by following the rules and mechanics. Once you have mastered them, be guided by principles.

Holacracy has potential - much like the early days of agile and Scrum. The frameworks will change and the guidelines will be updated as we learn more and gain experience.

“Every time the size of a city doubles, innovation and productivity per resident increase by 15 percent. But when companies get bigger, innovation and productivity per employee generally go down.” —Tony Hsieh, CEO, Zappos.

Snapper, a New Zealand based transport ticketing service provider, wanted to be more like a city, and less like a bureaucratic corporation. In a city, people and businesses are self-organising.

That's why in 2016 they introduced Holacracy, which enables people to act more like entrepreneurs and self-direct their work instead of waiting to be told what to do. Today, Snapper, a 60 person company, use Holacracy across all areas of the business and this way of working applies to everyone.

Why change?

In 2016 things were already 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.

What is Holacracy?

But first let’s define what we’re talking about. Holacracy is a method of decentralised management and organisational governance in which authority and decision-making are distributed throughout autonomous, self-organising teams. In Holacracy teams are called circles.

As we don’t want autonomous circles to pull in different directions we need to make sure they are aligned towards a shared purpose. Alignment is achieved through a hierarchy of nested circles. In this hierarchy each higher circle defines the purpose for its sub-circle(s). For example, the circle whose purpose is “Service customers on the go” could have a sub-circle with the purpose “Create a great customer experience on the iPhone”.

Autonomy is achieved by letting each circle decide how to fulfil its purpose. As long as they do, no one from outside the circle has the right to interfere with their ways of working. Some circles could use Scrum, others Kanban and others again their own magic creation.

The system has been developed by Brian Robertson, a US entrepreneur, who has codified it 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 many organisations in several countries. The most famous is Zappos in the US.

And now, back to our story already in progress.

Beginning the experiment

I knew Snapper well. Already in 2010 I had helped introduce agile and when I got the opportunity to return and implement Holacracy I was excited.

In 2016 neither Snapper nor I had had any experience with Holacracy. Stories of Zappos were contradictory and not always positive. The system seemed to be overly rigid and based on a plethora of rules. However, the underlying philosophy of self-management and collaboration was attractive.

Snapper’s leadership team grasped the potential and decided to make this a company-wide experiment. So, we all went into it with an open mind, the Holacracy constitution, and a copy of Brian Robertson’s book “Holacracy”. My instructions literally were: “We want to try Holacracy and we want you to make it happen.”

Redesigning the organisation

Inducting circles

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.

A purpose tells us why the circle exists and what it aims to achieve.

A domain is an area the circle “owns” and has full control over.

An accountability is an ongoing activity that the circle is expected to perform.

The most important circle is the general circle. That’s the circle that defines the company’s purpose and encompasses every circle, role and person.

As Snapper has always had a clear purpose defining the circle was actually pretty easy.

This is Snapper’s general circle:

We have adapted the concept of a domain: Obviously we don’t “own” the experience of moving people all over the world. Domains are not mandatory in Holacracy so, we thought it’d be okay to use them more like an “area of concern”. It worked well for us.

Then we designed the sub-circles. All sub-circles support the general circle’s purpose, so you get a hierarchy of purpose. We planned the circles we wanted and made an adoption plan. To begin with we literally recreated the existing organisational structure with a technology team, a marketing team, a finance team etc. Each of these teams would run with Holacracy principles and practices.

Our starting point was the technology team because they had been driving the agile adoption eight years ago and were used to working in small cross-functional teams already. We thought it would be easiest to start there.

This is our technology team of ca. 40 people. It has additional sub-circles that are small agile development teams.

The structure of circles and sub-circles with its hierarchy of purpose worked really well for us. It wasn’t particularly hard to implement: phrasing the purpose of the company circle was straight forward as we all knew Snapper’s raison d’être. It only took one session with the leadership team to find the right words.

Defining the purpose and accountabilities of sub-circles took a bit more time but was usually resolved within one or two sessions with prospective circle members. Having a direct line of sight of the outer circle’s purpose helped us agree on how the sub-circle could support it.

People found the clarity and transparency of nested circles helpful. People said that the autonomy to pursue a circle’s purpose gave them focus and helped prioritise.

Communication across teams improved as the defined responsibilities and accountabilities for each circle made it easier to know what to expect from another circle. People said they felt they could rely on things getting done and knew whose responsibility a thing was. It felt “lighter” not having to know the details of other circles’ domains.

One major breakthrough was realising that there was no actual reason to recreate the existing organisational structure. One of the most powerful things in Holacracy is the self-organisation and ultimate responsibility to achieve a purpose. We realised a few months into our adoption that it would make more sense to structure our circles around a clear external focus. This meant that we for example abolished finance, customer care and marketing teams and made those roles part of customer-centric circles.

We transitioned gradually over a period of 9 months. Looking back I believe that the staggered transition approach helped create a space for some people to find their feet and learn without the risk of technology, the most aware and confident part of the business, taking over. It also let us develop enough perspective to realise that we could (and should) completely change the structure of the entire organisation.

Creating Roles

Roles are parts of circles and are in themselves like tiny circles: They have a purpose, a domain and accountabilities. They are held by one person only, and because they are so small and granular one person usually fills many roles.

Here’s an example of Holacracy roles:

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. We defined and discussed roles with all circle members present and having to go through the details of the daily tasks of 6-12 people in a group setting was excruciatingly boring. Our meetings would 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.

For example, one of our solutions architects realised that he really loved designing technical solutions with existing transport clients but disliked drawing up ideas that were not certain to come to fruition. Holacracy gave him the opportunity to split those areas into different roles. A colleague who likes technical sales has taken over that role and the architect now focuses on solution design and his new additional role of a development coach.

My initial reaction to the detailed definition of roles in Holacracy had been a feeling of restriction. I thought roles would stifle creativity and would be de-humanising but I was positively surprised by how well they worked for us.

Clear boundaries between roles have made collaboration and conversations about who is doing what easier. “Me or you” conversations have become less personal and things no longer fall through the cracks. Someone said “We’re now talking about stuff we otherwise wouldn’t have talked about.”

Some people feel protected from being overloaded through having clarity and transparency of their roles. “It’s like having a blanky: You don’t have to use it but it’s good to know that my role definitions can serve as a boundary.”, one sales person said.

People also said that the greater autonomy made it easier to get things done and to make decisions. “The clear boundaries and accountabilities make it easier to know what I can decide and that I only have to ask permission from the people who are affected.”

Since we have gone through the work of defining roles we don’t look at them all them time. They have become part of people’s daily lives and they rarely have to look up their roles’ purpose or accountabilities. We only change them when it becomes necessary and every three months we do a greater check-up to see whether our roles are still current.

Getting stuff done

Improving through sensing tensions

Tensions are the elements that make sure we’re getting things done. A tension in Holacracy is defined as “the gap between what is and what could be”. By definition that’s a positive thing.

Examples of tensions are:

If I had this marketing tool I could have a much better dialogue with prospective customers.

If I had access to the customer service system and someone showed me how to do it, I could save so much time just doing this daily update myself.

If we could close down unused AWS instances, we could save a lot of money.

People are asked to bring up tensions during the circle’s Holacracy meetings or at any other time. Everyone is encouraged to keep an eye out for improvement projects to help with and to suggest their own when they sense a “tension” in their role or circle. The only caveat is that you can only raise tensions that directly affect you or your work. If you just tell someone what you think they should do better without being directly affected it’s not a tension.

In the beginning, we found it was important though 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. In newer circles there often was some uncertainty and reluctance to bring up tensions in the beginning.

We also needed to remind ourselves that Holacracy should not slow us down - if something should be done there’s no reason to wait for a meeting.

Sensing a tension and proposing an improvement is what helps circles move forward and ensures that we constantly keep improving. The increased visibility of other people’s areas surfaced things that could be done differently and has helped people come up with ideas for improvement.

One of our major successes was the ability of our systems architect to save a considerable amount of money every month by consolidating and shutting down AWS instances. Holacracy had allowed him to sense the tension, propose a new policy and know who was affected. The decision making process by consent (see later) made this a quick and pain-free process.

Processing tensions at Holacracy Meetings

Tensions are processed at special Holacracy meetings. Each circle runs their own meetings.

1. Tactical meetings

Some meetings deal with operational stuff, such as “This is the status of the VPN project. Could someone please help me collect information about who needs access?”. Those types of meeting are called tactical meetings.

In tactical meetings people deal with ongoing operations, update each other on their work, decide what needs to be done and ask for help. They deal with concrete, tactical tensions.

Here are some examples of what we typically discuss:

Should we have code reviews for all code? If so, how do we do that?

How do we avoid product owners being bottlenecks?

Can I take you through my Hubspot marketing project? I could also use the wisdom of the group.

The customer service slack channel has created an avenue for passing on customer issues rather than resolving them as they arise. What do we do about that?

2. Governance meetings

Other meetings deal more with “how the work works”. This is the time when people for example decide that the circle needs a security coaching role and create it. Those meetings are called governance meetings because they deal with the structures and policies of the circle. People deal with structural tensions in governance meetings.

Here are some examples of what we discuss:

The pre-sales role is too big. I think we should split it up into a technical pre-sales and an outgoing sales role.

I propose that attendance of all our meetings should be optional.

Nobody is getting back to clients after we solve an issue. Should we add this as an accountability to the customer service rep role?

The website is not updated and this seems to fall through the cracks. Do we need a role for “website updater”?

Meeting formats

There is an official format for how to facilitate these meetings and in the beginning we really struggled. The meetings 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.

After three months we felt ready to make some changes. The first change was to stop using a Holacracy tool 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.

Decision making by consent

We heavily use Holacracy’s process to make decisions by consent. Consent is my favourite aspect of Holacracy and it has helped us make decisions quickly and well.

Consent is different from consensus. When deciding by consent we don’t need everyone to agree. We just need no one to have valid objections. A valid objection is an objection that means the decision would stop us from achieving our purpose, slow us down or it would not be safe to try.

This is for example how we decided to make attendance to all circle meetings optional. Someone proposed the idea, no one had an objection and we deemed it safe to try. After all, we could always change the decision later through the same process.

The same happened for one of our marketing people when she after months of being stuck managed to buy a direct marketing tool by simply proposing it to the circle.

Consent is what usually keeps meetings short and productive. We don’t have to unanimously agree, we just have to make sure there are no objections to go ahead with a proposed idea.

What did we learn?

Snapper are now running Holacracy across the entire organisation and are on track to achieve what they set out to do. People have stepped up to the accountabilities of their roles and are beginning to own their domains. Circles are self-managing and perform well.

Some circles have achieved a level of maturity at which they are guided by principles rather than rules and mechanics. Others are still learning. Everyone I talked to would like to keep Holacracy and believes the learning curve was worth it.

Things were definitely difficult in the beginning. People found Holacracy confusing and didn’t like the legal language. The rigid rules felt at odds with the organisational culture.

However, we didn’t give up, tried everything for ourselves and things have worked out well.

Here are a few things we learned along the way:

1. Start out following all the rules

We always need to consider local flavours and special circumstances. However, it is important not to move too fast and to make changes to things we don’t properly understand.

So, our intention was to try everything as it was designed to be, and then, if needed, make changes from a position of knowledge and experience rather than because we found a practice too hard to implement.

We have benefited from this approach in that we now all have an understanding of why each practice is in place and are aware of the consequences of changing or removing any.

2. Follow the principles, not the rules

Holacracy is a system we employed 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, at some point 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 each other in a clear and concise manner. We see this as “being holocratic” as opposed to “doing Holacracy”.

3. Live with the strange 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.

4. Focus on improvements

A major breakthrough was the power of baked-in continuous improvement. In Holacracy each circle is responsible for its own development. We now have improvement projects for roles and circles and everyone can just make them happen.

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. We consider that a win!

What I think about Holacracy now

Starting Holacracy I wasn’t sure whether Holacracy was good or evil. I have come to the conclusion that it is neither. It is a very powerful system running on and amplifying a culture that’s already in place.

In a collaborative culture I have experienced just how powerful Holacracy can be to drive continuous improvement, provide clarity and visibility across the organisation. It can get decisions made quickly and with the right people involved. It amplifies and improves collaboration.

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.