Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

Decentralising Leadership: Holacracy in Practice

Sandy Mamoli, Nomad8, www.nomad8.com, @smamol

Research shows that 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. 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 a system called 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.

A year ago 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.

Why change?

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?

Hold on, let’s define what we are talking about. Holacracy is a method of decentralized management and organizational 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, that is the absence of objections, rather than by majority vote.

Holacracy was developed by Brian Robertson, 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 organizations in several countries, the most famous being Zappos in the US.
And now, back to our story already in progress.

Getting started

I have 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.

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.

Doing it!

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.

1) Roles

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 some 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 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!

2) Meetings

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.

3) Tensions

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 Holacracy work

There were clearly some things that were not 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 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 have 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 have also started explaining the concepts and ideas behind Holacracy in more understandable 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 is 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 is 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.

Nine 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 have 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.


Related software development articles

The Core Protocols, an Experience Report - Part 1

Fear of Intervention - How Subordinates Grow to be Entrepreneurs

The Work Situation in Software Development

Self-Selecting Teams - Why You Should Try Self-Selection


Click here to view the complete list of Methods & Tools articles

This article was published in October 2017

Methods & Tools
is supported by


Simpliv IT Courses

Vornexinc.com

Testmatick.com

Software Testing
Magazine


The Scrum Expert