Holacracy for Humans

FIVE KEY TAKEAWAYS

1. Holacracy provides radical transparency and timely decision making at the right level. Decision making by consent is awesome!
2. The freedom, autonomy and responsibility to achieve a clear purpose enables self-organisation.
3. Holacracy will amplify the culture that's already in place. It won’t change or improve it!
4. Start by following the rules and mechanics. Once you have mastered them, be guided by principles.
5. 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 use Holacracy across all areas of the business and this way of working applies to everyone.

WHO ARE SNAPPER?

Snapper are a 60-person company which has been in existence since 2008. They create transport ticketing solutions, i.e. the systems that make it possible to pay your bus/rail/metro fairs in cities using a chip card or mobile apps. The company is based in Wellington, New Zealand and services customers all over the world. Amongst others they provide the technology for transport ticketing systems in Wellington, Dublin and Riga.

About 40 people work within business improvement (developers, coaches, architects, CX and UX specialists, etc) and about 20 people in positions such as finance, 2nd level help, marketing, CEO/CFO/CTO, etc.

WHY CHANGE?

Snapper had been agile since 2010 and because of its benefits were looking for a way to be agile across the entire organisation, not just within the IT and customer focused teams. In 2016 things were going well but Snapper foresaw success and growth – and were well aware of the pitfalls involved in scaling up.

Already at the time small cracks were starting to show. Communications between teams and also between different business units failed at times and we noticed we had started to slow down. More people meant more hierarchy and more levels of approval which in turn would create bottlenecks and impede speed.

Snapper looked to Holacracy to help build 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.

(Note: If you don’t know how Holacracy works it’s a good idea to read or watch the introductory guides on https://www.holacracy.org.)

BEGINNING THE EXPERIMENT

I knew Snapper well. I am an Agile coach and consultant and had helped introduce Agile at Snapper in 2010. Despite per in 2010. This time I was asked back to lead the company-wide transition to Holacracy.

My role was not that of an Agile coach but as a Holacracy coach. Here’ s my official Holacracy role definition:

Role: Holacracy Coach
Purpose: Ensure we are running Holacracy and we are running it well
Accountabilities:

• Implement, measure, champion and support Holacracy practices
• Raise tensions and propose improvement ideas when we don't do Holacracy correctly
• Teach/coach circle and sub-circle members on Holacracy (as needed or requested)
• Assess whether Holacracy is the right thing method for Snapper

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. I was deeply sceptical about Holacracy which is why, when I got the chance to try it out I jumped at the opportunity to learn more.

Snapper themselves were skeptical too but 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. The idea was that we would give Holacracy a fair chance and to decide after 6 months whether we would continue or not.

They also consciously chose me as a trusted and un-biased partner with a track record within the company instead of a certified Holacracy expert who would have an interest in making Holacracy work rather than conducting a true 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.”

REDISIGNING THE ORGANISATION

Introducing 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:

 

Snapper have adapted the concept of a domain: Obviously they 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.

Then we designed the sub-circles. We in this case means the CTO, CEO, me and everyone who’d be part of the circle to start out with. 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 business improvement team, a marketing team, a finance team etc. Each of these teams would run with Holacracy principles and practices.

This is what the organisation (largely) looked like when we started with Holacracy, so below are our first circles. Only the sub-circles for the BI circle are shown. The other circles have sub-circles too but aren’t shown in the diagramme.

 

Our starting point was the business improvement (BI) 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 business improvement team of ca. 40 people. As shown in image 2 above it has additional sub-circles that are small, often agile development teams. 

 

The structure of circles and sub-circles with its hierarchy of purpose worked really well. It wasn’t particularly hard to implement: phrasing the purpose of the company circle was straight forward as everybody 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.

Snapper employees found the clarity and transparency of nested circles helpful. They 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. Employees 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.

Outsiders often ask me if managers had issues giving up control or if people found it hard to deal with the increased autonomy. As an Agile coach by trade I frequently find myself fighting these problems and was fully expecting them to manifest. Interestingly enough, this simply wasn’t a problem. One major breakthrough once our circles were established was to realise that there was no actual reason to keep the existing organisational structure.

One of the most powerful things in Holacracy is the self-organisation and ultimate responsibility to achieve a purpose. Employees realised a few months into the adoption that it would make more sense to structure 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. The main reason for this was that we wanted to make sure that all circles had a direct line of sight of the customer and Snapper’s purpose.

Snapper went from this organisational structure:

 

To this organisational structure:

 

(Note that because circles can easily restructure themselves this is just a moment in time and has changed since. It will also change again in the future.)

What was most amazing was that circle members, i.e. employees could initiate the change in organisational structure without having to go through more than one governance meeting for each circle. Compared to a traditional “restructure” this adaptability of and agility in organisational structure was remarkably undramatic and employee driven.

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 are some examples:

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.

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. Through conscious use for about four to five weeks they have become part of people’s daily lives and they rarely have to look up their roles’ purpose or accountabilities. They only change them during their governance meeting when it becomes necessary and every three months they do a greater check-up to see whether the 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 constantly remind each other 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 Snapper’s Holacracy successes was the ability of the 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. And while most of the decisions didn’t have a major impact by themselves, having hundreds of them added up to considerable positive change.

Processing tensions at Holacracy Meetings

Tensions are processed at special Holacracy meetings. Each circle runs their own meetings and chooses the frequency and cadence for each meeting type.

A. 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?

B. 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 over the 9 months it took us to make the entire organisation Holocratic 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 through the awareness of tensions and mechanisms for processing them. 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. All that’s needed is a proposal and a decision by consent.

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!

5. Don’t forget what we know about change

Like any other organisational change, such as introducing Agile to a company, it is important to start with a small, bright spot where people can learn and we can try out things. This bright spot should be a full vertical slice through the organisation to make sure that the change is neither too big nor too small and local to matter. Despite the Holacracy book recommending to change the entire organisation at once we spent the first 5 months creating the bright spot before we spent the subsequent 4 months rolling out Holacracy to the rest of the organisation.

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.

So, am I still skeptical? No, not at all. With the right culture in an organisation it can be extremely effective and powerful.

ACKNOWLEDGEMENTS

I’d like to thank Snapper for placing trust in me and for contributing to the community by allowing me to write about their Holacracy journey. Thank you to Brenda Leeuwenberg and Julie Starr for their input and to Nienke Alma for her input, proof reading and advice. A huge thank you also to Luca Leeuwenberg for her continuous inspiration. This experience report wouldn’t exist without any of you!