In the next days i'll be attending a Holacracy course and i wished to take some time to think about my feelings and hopes with this new system of company organization.
Holacracy is part of the more generic “Teal”/”Self-management” movement. The goal of this post is not to detail precisely what Holacracy is, but to keep it short let's say that it aims at defining an alternative to the hierarchical structures we are all used to, taking as basis the motto “organize the work, not the people”. The first time i heard about it was at our annual “conference” where someone from management gave a talk titled “Let's get rid of management” (yes, someone from management!! That's also why i love working at Liip!). I was quite sceptical at first and had concerns about the potential chaos this could lead to, but after reading the “official” book i must admit i'm quite excited about this new paradigm! Since then i realized that Holacracy is very far from chaos: it just replaces a hierarchical structure with a more organic -very structured- one. So it's not “about getting rid of management” but rather “let's find a new way to organize ourselves”. Liip is very interested in moving to “self-management” in general, but the exact implementation (through Holacracy for ex.) is still uncertain.
Here are a few things i'm especially looking forward to learning more about:
That's the base of Holacracy: define roles and circles (groups of roles), their domain of competence and their accountabilities. Have a look at your current job description: if it reflects what you actually do, you're lucky! Mine for sure doesn't… In Holacracy a role is defined in 3 steps:
- its purpose: why it exist
- its domain of authority: on what does it have authority. Meaning what domain you can take decision on without consulting other people
- its accountabilities: what concrete actions can people expect from this role
It's important to make the distinction between a role and a person. This goes back to the initial paradigm “organize the work, not the people”, meaning we are defining roles and then people decide to embody one or multiple of them (a person owning potentially more than 1 role).
I see a lot of potential for this at Liip: having clear -stated- expectations about what is awaited from a role should help both the person owning the role in prioritizing what to do and others in being more realistic about expectations, which should eventually and hopefully lead to less frustrations. Same for accountabilities/responsibilities which are somehow defined but not clearly stated at the moment. Finally, separating the role (and its duties) from the person “owning” the role seems like a good way to limit personal conflicts.
Structure but different
Roles and circles definition offer a new paradigm in defining a non-hierarchical structure. At the moment at Liip the structure is very flat (only 1 level: management, 6 persons from 130) and teams have a lot of autonomy. This is great and enables fast decision making, at least for limited scope decisions (ie. that don't influence other offices for ex.). But information sharing and global decision making is getting harder each time we grow. It's either too much (are we all interested in everything?) or too little (“let's create a work group to do this and that” without coordination with the rest).
Holacracy offers through the circles and roles a different way to structure companies, keeping freedom and ease of decision on your cicle's domain but making possible to take global decisions as well.
As transparency is a first class citizen in the methodology you are still able to follow what other circles do and decide without having to be part of every discussion.
As at Liip we use Scrum not only for project management, but also for most of the things we do in general, we already have established improvements circles. At the “squad” (ie. sub-team dedicated to a project) level we do a “retrospective” after each development iteration (sprint retro) and we do the same at team level 4 times a year. The goal of those meetings is to make sure we dedicate a moment to think about the “how” (ie. the process) rather than the “what/when” that you typically find in project management.
Holacracy introduces this at all “circle” levels with so called “Governance” meetings. The meeting format is quite formal and focuses on felt “tensions” (a gap between the current situation and a potential status). Restricting attendance of Governance meetings to circle member ensures only interested people take part, and probably scales better than what we do now, while keeping the possibility for everybody to raise tensions (and thus get “heard”).
Words are important
As you probably have understood already, Holacracy uses a defined vocabulary and insists on using those exacts terms. “Tension” rather than “problem”, as it gives a more neutral way of expressing a need (which can be either negative or positive), and “processing (a tension)” rather than “solution” or “fix”, as it implies continuous improvement and adaption rather than a “one shot fix”. In the same way, it suggests to always state “problems” (yes, “tensions”) in terms of “proposal”, to always search for possible solutions rather than problems, even if those proposals are only a first shot and nothing like a final solution. The vocabulary also supports the iterative approach by defining how to formulate “objections” as “does anyone see any reason why this isn't safe enough to try, knowing we can revisit the decision if it doesn't work?”
As stated in the book, evolving to Teal/Holacracy is not about redefining your day-to-day job (web/application development and consulting for us) but rather the underlying “Operating System”: the structure, the links and bounds. In a company like Liip where authority is already quite distributed, it's also a lot about making clear and visible what already exists.
I'm really excited about attending this course and i hope to develop further my thoughts very soon!