No more Policies, Processes and Rules in self-management with Holacracy?

When your colleagues all self-manage, who makes sure everybody adheres to certain rules? Is there some magic that does not require optimal processes to be written down? Are policies an archaic instrument not needed in self-management heaven?

Nope. Probably even the contrary: our self-managed organisation is arguably more documented, more structured and more explicit than your average corporate in a heavily regulated industry.

If it’s not written down, it doesn’t exist.

One of the base rules at Springest is that we write things down, almost always in Asana with some exceptions at circle level (eg. developers make comments on code in Github because that suits the work better). If we talk about some work that has to be done, the conversation will end with “I’ll make a task for you in Asana”.

Work itself is explicit in roles and the consitution

One of the main and first benefits of Holacracy is that there is a rule book, the constitution, that everybody adheres to. Why? Because the formal and legal power holder (me, in this case, as founder and majority shareholder) has signed a contract that it is so.

Of course, in Holacracy, there is a process for keeping track of what can be expected of whom. The governance process defines circles and roles, consisting of a purpose, accountabilities, and optionally domains and policies.

But if something is expected, it doesn’t mean that it will happen. That depends on how the role holder chooses priorities. There is always more to be done than can get done. But if work is done, sometimes you want to make sure it’s done in a certain way…

An explicit role with expectations for each employee

At Springest, this starts with your Springeteer role. It lives in our Alignment circle, our renamed “General Company Circle”, and everyone working at Springest holds it as non-core circle member. You are not allowed to drop it because it’s in your employment agreement. As you can see in our governance records (it synchronises with Asana every hour), it contains links to other policies and rules that are updated by other specific roles and communicated via Sputr or Asana.

Policies for circles and roles

In Holacracy there is a construct called Policy to basically limit access to certain things (a Domain, or something the circle by definition has authority over) unless you respect the policy. We tend not to use them too much, because they’re harder to parse than accountabilities, which are more direct.

However, we do have some policies on our Alignment circle that govern how we work together. We sometimes doubt whether to make a certain rule into an accountability of the Springeteer role which we added only a year ago, after running on Holacracy for 4 years already. Or, to add the rule as a policy. We instinctively choose accountabilities for something you actively do and that can be expected (which policies are not for), and policies for the way that you do it.

Rules of Engagement

A problem often encountered is that roles are filled by multiple people. As a platform focussed on helping people learn, we employ about 15 people that hold the role “Learning Advisor” (and often a few others as well). We want those people to work according to a certain process, to ensure quality and consistency for our customers. This is hard to express in accountabilities, might be hard to enforce and and sometimes seems to contradict with self-management.

To solve the tension of ensuring adherence to a process, we have evolved the construction where:

• Role 1 is accountable for creating and updating certain “Rules of Engagement” (link points to our General Communication Rules)
• Role 2 is accountable for adhering to those roles, with a link to the rules in the accountability.
• In some cases, Role 1 lives in the super circle of Role 2.

This creates transparency around those rules and often reasons for them, without falling back to old-school management where a Lead Link might naturally set those rules.

ISO certification

To top it off, we recently received our ISO 27001 certification. For a relatively small company, this might sound daunting. However, we found it was quite easy to pass the audit. We already have all of these constructs for documenting and guarding processes in place and it was simply a matter of adding all the demands from the ISO 27001 certification in our governance records.

We protect the ISO certification with a domain on the governance records itself that prohibits its change, unless the Security Officer role agrees. We thereby comply with one of its most important demands: that certain people (in our case, roles) can limit change that might impact security.

The ISO auditor, and earlier the consultant who helped us navigate the ISO process, literally said they were really impressed with the level of explicitness in our organisation. On any of their questions we were able to answer “oh, sure, you can find that there, and a link to it goes here, and then that role is defined there”, etc.

So, what’s the fun of all this?

To conclude… yeah it does sound pretty regulated huh?! Consider this:

• It makes me as founder very relaxed about things like security, quality, durability of my business etc, knowing that we have this covered. I can focus on our purpose.
• All changes to these regulations are incremental and iterative (except when they’re protected by a domain :)), because of Holacracy’s evolutional governance process. It’s not daunting at all!
• Everybody can influence many of those rules. Again, unless protected, but then it’s still clear how to change them if needed. This makes it so much more motivating and not frustrating for people in the organisation to follow the rules, and not abuse them in case they don’t fit with reality.

I’m curious to hear your feedback. Remember, our organisation is also just a perpetual work in progress. We also don’t strive for perfection, we merely solve tensions as we go, when they limit us to reach our potential.