I’ve seen Holacracy as a common feature in high performing teams, delivering products in months not years. Teams of 3-6 people creating and delivering with what more traditional companies expect from 30 people or more.

Holacracy aims to distribute authority and decentralise management in self-organising teams. It shifts the paradigm of a line management hierarchy to shared responsibility and accountability to the team level.

Roles over levels

At its core, Holacracy separates roles from titles or levels attached to the individuals that fulfil them. Roles are seen as a set of activities and responsibilities which can be shared, many people can fulfil a role, for example two people can facilitate being a delivery lead. For smaller teams this often means individuals wearing many hats - for example one person could be a technical lead and delivery lead.

A typical delivery team often requires roles including:

  • Engineers
    • Backend
    • Testing
    • Infrastructure
    • Automation
  • Scrum master
  • Product owner
  • Delivery lead
  • Tech lead
  • Project Lead

Do we need 9+ people / job descriptions or could five people facilitate the roles, self organise and be an effective team?

Could it be:

  • One tech/delivery/project lead, who is accountable and responsible for the technical vision and overall delivery
  • Four cross-functional engineers coving the technical implementation including the backend functionality, infrastructure that hosts the systems and automation pipelines promoting code to production

This may sound like a separation based in hierarchy, it is a separation of responsibility and accountability based in experience and who’s right for the role. holacratic teams are self organising but not self directing; they still require leadership from the business, agreed governance and likely centralised decisioning.

Decision making

The holacratic decision making process is known as “integrative decision making”. It’s goal is to distil relevant input and experience from each member to ensure the proposed changes are honest and fit for purpose in the roles’ needs and outcomes, aligning to the larger business needs, rather than individual bias.

For example, the tech lead may understand the overall problem and have created an architecture for the solution, but individual engineers can contribute or own the implementation design for individual components. In this instance the tech lead should set the direction and outcome, understand the overall problem and align the team - then the engineers can lead the technical discussion and implementation details, with or without the lead present.

Organisational Hierarchy

So far we’ve looked inwards at the team level but how does this apply to an organisation? Holacracy as a model was originally developed at Ternary Software by founder Brian Robertson [ref]; Robertson’s original organisational structure and the learnings derived from it are what later became known as Holacracy.

Robertson recognised that a team, or circle, with a clear purpose and set of responsibilities, or accountabilities, could self organise and own the purpose end to end. There are different circles at different levels, one circle could be the aforementioned delivery team and another made up of engineering managers responsible for multiple teams and accountable for the continued development and delivery of the overall product, such as an online store.

Getting technical

If we dive deeper into the language of Holacracy there are two roles which face inwards to the circle and back to the business in a broader circle; these are the “lead link” and “rep link”. These roles ensure alignment to the business’s overall mission and that the team are aligned to their defined goal and outcome. Again, this could be one or many people. An obvious choice in current language is the delivery lead or tech lead or who create alignment, give purpose and understand the day to day challenges facilitating an environment for the team to succeed in.

Governance process

A business should give direction and purpose, they should answer the what and why, they should also understand the sector and environment they do business in - they should understand the regulatory requirements and establish governance processes and protections.

Individual circles, or teams, are guided by the business and these requirements, they can set clear processes and policies of what each role facilitates, which should be regularly reviewed - particularly with young teams. There will likely reach a point which can be comparable to business as usual, where consistent stability suggests no change is required. Given how company visions and roadmaps change, you may experience product or feature realignment causes a team change and restructure before long-term stability is reached.

Adapting to change

As an organisation or project evolves, requirements typically change. If a team grows in numbers, it can be difficult to orchestrate the delivery, having enough relevant work for everyone to actively contribute to or even contribute concurrently on singular tasks which may yield system conflict (think stateful infrastructure). As the team evolves it could be sensible to split the team into two or three teams, each focusing on a single, well defined delivery stream. One or more team members can step into the technical lead shoes of the new teams, bringing with them domain and system knowledge. The original technical lead may need to focus more as a delivery lead for the three teams and delegate the tech lead activities.

Holacracy provides a culture that allows team’s roles to adapt to change

Operational process

Authority is given to roles and the team members that hold them; roles are bound by the governance processes put in place globally across the organisation and locally to each team, this can be as restrictive or freeing as the organisation decides. There can be blanket rules allowing teams to decide which technologies to use and patterns to implement or they can be process bound for example preventing access and requiring sign-off from designated roles for any financial or public facing decisions or tasks.

The organisational leadership aligns teams, or circles, to the desired outcomes, these require people to fulfil their role’s responsibilities and tasks efficiently together; it places trust in individuals to get things done the best way they see fit. There is a bias for action which leans towards the philosophy of “ask for forgiveness, not permission”; if people act with sincerity within the guard rails, they have freedom to create and innovate. The governance should prevent unwanted or detrimental consequences but as we can’t foresee or plan for everything, we must evolve the guard rails to prevent repetition of unwanted outcomes without hindering individuals autonomy to deliver.

Learnings

Holacracy fits well with agile ways of working and cross functional teams as it promotes autonomy within small teams, aligned and focused to deliver outcomes and pivot as new information and requirements are discovered. Subscribing to roles not descriptions allows people to focus on the activities at hand that traverse individual functions or domains, and not wait to be told what to do. The level of trust given to individuals promotes a culture of openness, excitement and accountability that is essential for DevOps ways of working - build it, deploy it, run it, own it.

Like any framework, we should take the bits that are useful; Holacracy can be useful even if we take one learning:

Empower and trust people to do the right thing