You may be reading about Agile, matrix structures, or even Holacracy. Some argue that hierarchy came out of the need to manage manufacturing in the 19th century. Further, that Agile and other methods eliminate the need for hierarchy. I take the contrary position that hierarchy is necessary – as long as it’s not over-used. Below are reasons why hierarchy is essential in organizations, and how to manage the downsides to get the balance right.
We Need Hierarchy to Set Strategy
For the purpose of this blog post, assume that setting strategy means determining where to compete and how to differentiate.
Why we need hierarchy: To achieve success and differentiation, every organization must understand:
- The marketplace and its adjacencies
- The problems the organization and competitors solve for customers
- Where and in what ways it achieves differentiation, and
- Where and how the organization positions itself to deliver and differentiate.
Making these difficult decisions requires a certain level of knowledge and experience. It can be challenging for even a handful of people to agree and align on these decisions. It’s hard to imagine a democratic decision-making system that can align on this level of specificity for any company. Maybe this could happen in start-ups and first-to-market companies, but that approach has a limited lifespan for successful, growing companies.
How to mitigate the downsides: Making the decisions about where and how to compete shouldn’t be done exclusively with a small group. The leadership team should frame the conversation, seek information from inside and outside the organization, and hear passionate advocacy from their teams. Broad inclusion is your friend in understanding the market, customers, emerging needs and technologies. Inclusion also helps in understanding options for differentiation and what the organization can confidently execute. Get a handle on these, then the leadership team can make the tough calls, align themselves, and communicate broadly about the where and why.
We Need Hierarchy to Allocate Resources
Resource allocation is primarily about how to utilize people, funding, and physical assets. Deciding where to invest more or invest less is crucial to strategy execution.
Why we need hierarchy: Similar to setting strategy, the organization must decide how to allocate finite resources. Even Agile parts of the organization need to decide how many teams to fund for a certain product or functionality set versus another. Agile teams that advocate for more resources are accountable for articulating the case for change for additional resources. They are constrained by their resources – double the resources, and you should be able to accelerate – up to a point.
How to mitigate the downsides: Again, broad inclusion is your friend. This means leadership teams regularly making time to understand the whole picture – where the teams are making progress, how fast, and where faster progress is possible with more resources. Inevitably, there are places the organization could make faster progress, but chooses not to because there is higher priority in other capabilities. That is the role of hierarchy.
We Need Hierarchy to Lay The Foundations of Work
Typically, infrastructure and policy decisions do not contribute to differentiation. However, they help ensure work is done efficiently and in compliance with regulations.
Why we need hierarchy: Even in starting up an Agile project, we need to know:
- That we have servers and their supporting teams
- What products we’re using to do our work in
- Who gets decision rights when we need to make calls between different sets of trade-offs
The Infrastructure Foundation
On the harder infrastructure side of the business, such as building an additional warehouse, we don’t want to start from scratch on sourcing everything we need to build and operate it. For example, there should be authority to pool demand and contract on buying materials to obtain the best price. Not every team will love every choice. But the organization as a whole benefits on costs, allowing for investment elsewhere or reduction in prices.
The Policy Foundation
On the policy side, most teams in one functional area don’t know the boundaries of what is possible, legal, or risky in non-adjacent functions. In my experience at an ambulance company early in my career, many of us on the front lines had great ideas to improve shift scheduling, equipment stocking, and staging (where to put the available ambulances around a city at any given time given the number of available ambulances at that moment). However, we didn’t know the constraints from labor laws, state regulations, and city regulations that would forbid many of these ideas or create and a high level of risk. Experts with authority to lay the infrastructure and boundaries allow the business to start work (infrastructure) and survive by mitigating risky or non-compliant choices.
How to mitigate the downsides: In both the case of infrastructure and policy, downsides include infrastructure not fit for purpose, or policy that is too expensive or risk averse. Benchmarks help determine whether infrastructure costs (e.g., cost per FTE, square foot, or other metric) are within a typical range. Visiting other organizations can be a great aid in assessing both of these. Choose non-competing organizations that are willing to share and have a similar situation. For example, when building a customer-facing application at a retailer, consider a site visit with a different retailer in a different category. You’re there to learn about the infrastructure set-up, where they draw the line between shared vs. unique products, and how they manage risk.
Please share your thoughts. Do you agree that hierarchy is necessary in the ways I’ve noted? Where else is some dimension of hierarchy needed? What are some other ideas for mitigating the downsides?