Use a Combination of Hierarchy and Holacracy Principles for Product-Mode Organisational Design

Scott Millett
7 min readJul 15, 2024

The organizational structure of a department is the most visible component of its operating model, and the one that is likely to have the biggest impact on the shape of the technical landscape and the execution of work. Therefore, structure should be deliberately designed to support the strategic contribution that IT will make to business success. In other words, as Naomi Stanford, a leading author on organizational design, says, there should be a compelling reason to change the structural design of teams and “Part of a decision to design rests on making a very strong, strategic, widely accepted business case for it — based on the operating context. If there is no business case for design or redesign, it is not going to work.” In addition to the strategic needs, we should also take into consideration social, technical, and business seams when designing team boundaries to ensure alignment and collaboration, team health, and an increase in the flow of value. The organizational design will have a material effect on how people function and their relationships to other areas of the business, but if the other components of the operating model don’t complement the changes, there will be limited positive business impact.

To understand how best to organize teams, I will compare two extreme approaches: hierarchical and holacracy, and show how employing a mixture of both, rather than choosing an either-or approach, will support a structure that can enable business performance in exploring new business models and opportunities as well as exploiting and maximizing the incumbent model.

Hierarchy

At its most extreme, a hierarchy is a system based around the concept of command and control that separates thinking from doing. The world of hierarchy is vertical, with power flowing from the top down. As shown in Figure 1, prescriptive orders are given by leaders, feedback is passed up from the workers via management, and decisions are then made at the top and passed down. The purpose of the hierarchy is to ensure control and predictable operational results. Thinkers at the top, doers at the bottom.

Figure 1: The anatomy of a Hierarchy.

Holacracy

At its extreme, a holacracy is a management strategy and an organizational structure where the power to make important decisions is not held solely by those paid the highest but instead is distributed throughout an organization to people at all levels. The fundamental concept behind holacracy is self-organization. Given a common goal, employees should organize themselves into small teams and determine the best use of their time to achieve that goal. The structure encourages distributed decision-making to those closest to the problem without the need to pass through layers of bureau- cracy to authorize pursuing an idea. Along with empowerment to make decisions, trust, safety, and transparency are core principles of a holacratic way of operating. A loose form of hierarchy exists, as shown in Figure 2, but this light structure is just to ensure boundaries of responsibility are clear and that leaders can articulate the organization’s goals and direction. Contrast this to the traditional hierarchy, where thinking and doing are separated in that those at the top decide what to do and how to do it and hand off to those at the bottom to do it in a very prescriptive manner. In a holacratic organizational design, these roles are merged. Thinkers and doers work as a team guided by the strategic objectives of the business.

Figure 2: The anatomy of a Holacracy.

The Need for a Balanced Design

Hierarchy and holacracy represent two extremes of how an organization’s structure can be designed, but neither of these is ideal. Instead, we should take a balanced approach, opting for a mixture of the two or a “flatter” organizational structure as shown in Figure 3. This structure retains the essence of a hierarchy to give direction, coordi- nate across teams, and provide guardrails while utilizing the benefits of a holacracy by focusing on the team as the primary unit of an organization and distributing decisions, rights, and giving employees autonomy to innovate. This blend of both a hierarchy and a holacracy takes out the unnecessary layers of bureaucracy but still leaves a frame- work in place for coordination, control, and communication. In truth, depending on the problem context you are dealing with, you may favor one structure more than the other. For example, you may favor a more hierarchical structure for simple problem contexts, such as when working with third parties to integrate an off-the-shelf system and a more holacratic team structure for more complex and unknowable problem contexts that require the team to innovate and adapt to feedback quickly.

Figure 3: Flatter organisations balance the strengths of Hierarchy witrh the strengths of Holacray.

Figure 4 gives an example of how a balanced structure may look in reality. There are networked teams of people based around business domains, be they customer journeys, value streams, or business capabilities. There are hierarchies of people for cross-cutting concerns such as enterprise architecture, project management, security, governance, service, and infrastructure.

Figure 4: An example of using both Hierarchy and Holacracy in organisation design.

A hierarchy brings clarity in decision-making, leadership, and accountability and is therefore not inherently bad. However, we need just enough hierarchy for direction setting, coordination, and guidance, while avoiding unnecessary bureaucracy. Too much of a hierarchy or command-and-control structure will stifle innovation and customer-centric approaches, which will prevent an organization from being successful in managing complex problem domains. A hierarchy is critical to effectively deal with communication and coordination as well as size and complexity as the network teams grow and are distilled into coherent smaller teams. The greater the number of teams, the greater the need for a hierarchy to control at a macro level; therefore, hierarchy sits above a holacratic set of networked teams as an organization grows.

There is also nothing wrong with seeking a more holacratic design; however, this doesn’t mean ignoring the advantages of a hierarchy and just letting teams do what they want. Often people need constraints in the form of guardrails or guiding prin- ciples as well as shared outcomes and visions to avoid becoming paralyzed with the endless possibilities of what they could do. There needs to be an underlying vision and purpose and a shared understanding that teams can identify with and use as a North Star to focus efforts. A hierarchy can provide guidance using outcomes that have a clear line of sight to the organization’s goals, which will act as a framework that teams can work autonomously within. This will provide enough control and governance without removing a team’s autonomy for dealing with the problem at hand. Fostering a safe-to- learn environment for those closest to the problem, and to our customers, will enable them to challenge the direction of the hierarchy with feedback, ensuring a consensus is reached on the best outcomes to pursue to achieve the organization’s strategic goal.

Supporting an Ambidextrous Organization

A balance of hierarchy and holacracy can also greatly enable an ambidextrous organization. An ambidextrous organization is one that can quickly adapt to changes and disruption while also driving efficiencies. This comes from a need of a business to exploit the incumbent business model and existing capabilities for profit and focus on exploring new models and new opportunities for growth to ensure they do not become obsolete due to inertia. In a Harvard Business Review (HBR) article entitled “The Ambidextrous Organization(April 2004) by Charles A. O’Reilly III and Michael L. Tushman, they state that “. . . organizations separate their new, exploratory units from their traditional, exploitative ones, allowing them to have different processes, structures, and cultures; at the same time, they maintain tight links across units at the senior executive level.” Such ‘ambidextrous organizations’, as the authors call them, allow executives to “pioneer radical or disruptive innovations while also pursuing incremental gains.”

By using networked teams along with a strong hierarchy, we can more effectively support an ambidextrous organization. As shown in Figure 5, the Wardley Map clearly shows that different teams supporting components in different areas of the business can have different modes of operation and team characteristics as listed in Table 1. The key point to take away is that there is no single mode of operation for teams.

Figure 5: A Wardley map showing different types of teams supporting componegts in various stages of evolution.
Table 1: Different modes of operating to support an ambidextrous organisation

Organizations today must adapt to change and innovate at speed to remain relevant, but they also must balance the need for stability as they scale. As businesses grow, the need for a hierarchy is increased, but one that will ensure communication lines and team setup is effective and supported rather than adding waste and bureaucracy. By blending the strengths of a hierarchy with a holacracy, we can create an organizational structure that enables clear guidance, control, and governance complemented by a set of networked teams, with their own context-specific processes and culture, that are able to adapt quickly in response to feedback and changes. This is how IT can contribute and support an ambidextrous organization.

What to read more?

This article was a summary of product team design from my new book The Accidental CIO: A lean and agile playbook for IT leaders. If you want to read more please follow these links or look for it at your favourite book seller.

Book cover for The Accidental CIO: A lean and agile playbook for IT leaders.

--

--

Scott Millett
Scott Millett

Written by Scott Millett

CIO and the the author of Patterns, Principles, and Practices of Domain-Driven Design,Professional ASP.NET Design Patterns, and Professional Enterprise .NET.

Responses (2)