Grind the tension: Holacracy Practitioner Training

This is an interim blog post defining my thoughts whilst attending the five day Holacracy Practitioner Training in Philadelphia. I will probably repost my final thoughts or add some comments when I return back to Australia.

So why do Holacracy Practitioner Training in the first place? It certainly wasn’t because I had client that had an appetite. It was because I wanted more depth on the logistics of how it worked after reading the book a few years ago and after hearing a few people from zappos and other institutions talk about their implementations. I wanted to hear the tips and tricks from the expert and creator, Brian Robertson. I also wanted to do it because I felt that it would be the logical next step for organisations after or mid Agile transformation, especially those that had tried self selection, so I wanted to prepare myself for the future.

What I got was all my desires and more. For the logistics of how it works, the five day practitioner course really is practice focused, with a complex simulation that enables multiple opportunities for everyone to fulfill the facilitator and secretary roles in a very safe to fail environment. As for hearing about zappos and other institutions, well I haven’t heard much about Zappos yet, but I have heard from a lot of people on the course about how it is going in their organisations. The number of attendees already doing Holacracy somewhat surprised me and some of them already had a few months experience up as facilitators (and it showed). I have found that I have gotten as much value out of the people attending the course as those running it. I have enjoyed watching some of these people who have had honest concerns that they are still on the fence about the value of Holacracy change over the course of a few days – often because they didn’t understand the purpose of a particular activity, but more commonly because it was being implemented incorrectly (because this never also happens in Agile transformations right?).

As for Holacracy being the next logical step past Agile, well I am really not sure about that now and probably need more processing time on that one. It certainly isn’t a pre-requisite (though I never thought it was), but I don’t think people early in the Agile journey have to rule it out either (where I once thought maybe mindsets may not have been progressed enough for this leap).

So for some more detailed thoughts on the course, in a somewhat time based progression format feel free to read on:

Day 1

Introduction of theory was expected but felt long taking up most of the first morning.
Brian really is as engaging in person over a long duration as he is talking in videos. His energy is quite infectious.
Afternoon session – simulation. Now I build games for my training so I know the value of a good simulation and this simulation is the second most complicated one I have ever experienced (Lean car factory being the most complicated one I have). As we went through the simulation I guess I had the unique perspective of not just doing the activity but also analyzing at the same time the simulation itself for the outcomes expected, the constraints and the rules. Now when I build games I build them so they fail first, which this does. But I don’t build them with so much failure that the goal is 100% unachievable – that is, if you are a master, you might still succeed. The Hygean game – well it was built with a 100% failure rate. I could tell very early on what the constraints were, I also had a good background in the simulated value chain so I knew that well. From minute zero of the game I began working to the roadblock of the delays in the value chain. But when the constraint never responded in the first round at all it meant that value was never a possibility. Now I realised in the evening of Day 1 that I had made two incorrect assumptions about the simulation – that value was important (ie the business not running out of money). Lean thinkers will see very quickly that the business is about to run out of money, but it is a bit of a red herring, in some ways the simulation doesn’t reflect reality because people would care a lot about this information. The second assumption was that it mattered to win (ie successfully deliver value). It doesn’t, the point of simulation is to arm yourself with enough ammunition to run through the governance and tactical meetings, nothing more.
Checkins. They feel really clunky. I’ve never been a huge fan of them because I have seen them abused in the past but they did feel authentic in the meetings we had.
Building agenda items – the usage of only one or two words for an agenda frustrated me. I can see the similarities of the activity to lean coffee, but unlike lean coffee, where you spend fifteen to thirty seconds talking about your agenda item, in holacracy there is zero time spent on what the agenda item means. The consequence is that no one actually understands the agenda. This felt incredibly uncomfortable, mainly because I wasn’t quite sure if someone else’s agenda item was similar to my own as the two words were the same and so I didn’t know whether I should raise my agenda item. What I subsequently resolved that evening was that it didn’t matter. It was my responsibility to put my agenda item up regardless. The agenda item is only a refresher for the single individual that created it and nothing more.
Reaction round – the process in a lot of respects feels like the Cynefin Ritual Dissent activity – in that it creates space for a proposer talk without interruption, that respondees can ask questions, respond emotionally without interruption (with a small element on Non Violent Communication) and with dissent. After that it is more like a facilitated processing activity with similar restrictions on who can talk when. In the scenarios that we went through I found this activity at first incredibly frustrating, not because of the process, but because it felt that there were gaps in the structure of the process. As an example, in our simulation with the financials running out a proposal was put forward to make the financial runway visible to the organisation so that we didn’t go out of business. The proposal was opposed because of a concern that people would leave the organisation if they thought it was about to be bankrupt. This was based upon an assumption that was perceived, but was not rooted in metrics and because the objector felt that the information wasn’t safe to test, it was considered a valid objection. My main concern with this outcome was that the assumption was statistically invalid, just that the objector was not aware of it, but importantly that I had no ability to even say this, that the falsehood of information was allowed to continue unabated. Now in fairness, I now know that if we had time it would have gone to integration and that hopefully that information would have come out then, but it felt like time was being wasted.

Day 2

The feeling of a lot of time wasting in these governance meetings continued as I pondered time and again where lean elements of root cause analysis and value stream analysis fit in. People changing roles and accountabilities without any understanding of the value chain seemed inane. But what I realised by the evening of Day 2 was that it didn’t matter – because the value chain would be discovered over time through continual incremental refinement. In essence, getting roles, accountabilities and the value chain right occurs over time (and isn’t ever right). It is like Agile, the software will never be right by the first sprint, but through continual build, reflect and adaption it will get good enough in the end.
Proposal tension analysis takes a lot of time when the change is a large merge/refactor. It felt slow waiting for everything to be typed in, but then I found out afterwards that you can propose items in advance and write up all the proposed changes beforehand. This made me feel comfortable that corporates would balk less at the time waste if they knew information could be processed asynchronously (which was demonstrated to me afterwards by someone doing holacracy already).
It really hit home to me by the end of this day that tensions are best when they are micro and are frequently worked on. Weekly governance over monthly would be the best way to start, much like short Sprints allow more frequent adaptation. My favorite quote of the day – “Design the org, just in time, for what you need not what you might need.”
Not a huge fan of the ’cause harm’ language, prefer the longer language of ‘can impact delivery of the circle’s purpose’.
The term ‘project’ also feels like the wrong language to use. Many corporates have a deep tie to this word and I feel it would be better changed.
A comment was made (either this day or day 1) that an example of an outcome for a project would be ‘Product page redesigned’ – I would argue that that is not an outcome, an outcome would be the why – ie “Provide a more user friendly experience to increase customer clickthroughs”
How to prioritise tensions – strength of tension, first in first out, shared tension or time criticality. The answer is it depends on your needs and almost all options can be used at the discretion of the facilitator.
Can the facilitator and secretary be the same person? Yes, but it is not generally recommended. I can see through the simulation why for beginning teams this is not recommended.
How do you balance workload if you are working in multiple roles? The answer is holacracy doesn’t specify a solution for this.

Day 3

Root cause analysis can happen, but only if the proposer asks for help/it. So if, as a respondee, I am needing root cause analysis to get onboard with the change then it isn’t the proposers problem, it is mine. Consequently the proposers change should go through without objection and if I care about root cause analysis then I need to raise the tension (proposal). Processing tensions is all about processing the tension for the proposer, not for opinionated people.
Back to the earlier quote – ‘what might happen’ objections which are invalidated result in only a 10% new proposal rate. This isn’t due to people feeling petulant that their objection was invalidated, but that when it comes down to it, the concerns aren’t really that big of a deal, we are just so used to providing opinions that we can’t help ourselves.
Feeling very comfortable with the process and its micro adaptation of the organisation.

Day 4

If you are the sort of person (like me) that likes to help someone refine their need (ie paraphrase) then you would feel frustrated with the experience of the governance meeting as you cannot help the person get there. You have to be more patient and accept it will take more time.
Tactical meetings – not a lot of new content or concepts in here for Agile folk.
Use lead in narratives about the current step so that people understand what they are allowed to do (or not). If people get off track (out of process) guide via “We have space for that comment in the next step,” and then return to the current step.
“It is not a valid objection, but it sounds like you have an item that you may want to add to the agenda.”
Today reminded me a lot of Kanban’s rules – start with what you do now, know your constraints, your policies, respect.
Tactical tipsheet – if the action is volunteered by a person and there is no role accountable then the action is classified as “individual action”
Domain – full ownership for that thing, it no other roles can meddle with it without the express authorization of the domain role owner.

Governance Tipsheet

Present Proposal – proposer can ask for help or root cause, but normally will just be proposer.

Clarifying Questions – NOT a round robin, only people who have questions. Can have multiple questions. Ensure questions aren’t leading or an alternative solution is being presented. Stop people quickly if the question doesn’t start with a “what, how, why, when, or who…” Does not include proposer. Facilitator can ask questions.

Reaction Round – Does not include proposer (even responding). One by one go around, including facilitator.

Amend & clarify – Proposer only. They can choose to change things based on the reactions and clarifying questions. They can also choose to not change.

Objection round – Have proposer last, includes facilitator. Ask “Do you see any reason why adopting this proposal causes harm or moves us backward. As a facilitator you can jump around the objection questions if you feel there is a hint in what is said as to which objection it may fail on. The goal is to facilitate the process, not have emotions. Ask both sides of the question sheet. Anyone can ask in the integration round for an objection to be re-tested if they felt it wasn’t done.

Integration round – In integration, anyone can contribute as long as the facilitator has no objections and as long as the proposer and objector have opened it up. Ask the objector if they have an alternative proposal that will meet the need of the tension. Once done, confirm with objector if this meets their needs. If both are happy then it is integrated, otherwise it goes back for resolution. Another round of objections occurs after accepted integration.

Day 5

Just because you have a need from someone doesn’t mean you can’t talk to someone and ask them to do it. Use the governance process for tensions were expectations are NOT being met…. otherwise you will have dozens of accountabilities.
We seem to try to get agreement on the tension before we process it (consensus build). Holacracy accepts the tension regardless in order to process it. In this respect, you transition the time in an organisation spent consensus building outside of meetings to tension processing in governance. The time is likely to be less in the later.
Can use ‘curator’ rather than ‘secretary’
For Agile areas – keep your retros, have them feed straight into governance. Sprint Planning is often combined with tactical meetings, especially if the circle is the Scrum Team. If the circle has a few extra people outside of the Scrum Team then you may want to split the two.
Have governance straight after a tactical meeting as tactical meetings are likely to drive desire for change.
Address what happens with compensation early in the selling of holacracy discussions.
Existing policies get moved across into the appropriate circle.
Use the habit support program in Glassfrog
Don’t over do the setup at the start. Don’t be tempted to fix tensions as you breakdown job titles into roles.
Don’t give roles very status titles
Don’t try both (ie management and holacracy) at the same time
Developer role with a focus on product X is better when multiple products need to be supported in an area.
Have a role for guild lead, otherwise don’t have circles for tribes.
Be clear on how meetings relate to holacracy – stop doing or cut out the parts that are covered by tactical and governance meetings.
And for meetings that you keep, be clear on holacracy links – ie what roles are invited, tracking, actions, projects, tensions etc.