> ## Content Index > Fetch the complete content index at: https://www.cpj.fyi/llms.txt > Use this file to discover other available public pages before exploring further. # The purpose of hierarchy is autonomy - URL: https://www.cpj.fyi/essays/the-purpose-of-hierarchy-is-autonomy/ - Published: 2026-11-11T16:56:39.000Z - Updated: 2026-11-12T18:49:56.000Z - Description: We're in the middle of a historic opportunity to re-think layers, reporting structures, and working relationships. How should we design them for good? - Author: Clay Parker Jones - Tags: Org Design, Essays How many layers does a large organization actually need? In the abstract, perhaps very few. 1. Imagine a company with an enterprise leadership team at the top… 2. Some meaningful operating units in the middle… 3. And then scores of teams doing the work. So, three layers? It’s an appealing picture, especially if you have spent any time inside an organization where every decision seems to work its way through fifteen people before returning to where it started, almost unchanged.[\[1\]](#fn1) But when you fill those three layers with several thousand people (assuming traditional ways of managing) the spans become ridiculous. Someone will end up with 60 direct reports, those folks lose clarity and connection, and HR will put another layer back. And then another when someone’s valid career ambitions push them toward management. Before long, we’ll be arguing about whether five layers is still “flat,” whether a manager with two direct reports counts as a layer, and how many steps anyone ought to sit from the CEO. A higher-quality debate is “What do we need hierarchy to do?” in which I would argue that **we should design hierarchy to handle shared decisions so teams can get on with their own work.** That requires us to separate things the org chart traditionally bundles together, work out which decisions really need a larger authority, and judge that authority by what it enables people to do below. A target for spans and layers cannot do those jobs for us. ## *Org charts as lossy compression* Conventional org charts are a lossy compression algorithm that smashes at least four structural concepts into one legible image. Imagine for a moment you’re dropped into a technology company, observing two people working on the billing system. One is a senior engineer who knows the billing system inside-out; the other, a junior designer, has spent the last month observing customers struggling with their invoices. They have different knowledge required to solve the problem, and they should work together directly, even if several reporting relationships and job levels separate them. Elsewhere in the organization is a leader with 18 direct reports who is spending every evening on performance conversations, staffing and coaching. Adding a manager between that leader and half the team—a span-breaker—may help. It may also leave the team waiting for exactly the same decisions, now with another person involved. - **Working relationships** describe who needs to do work together. These should follow the work. An engineer should be able to contribute to another team when the work requires it. Someone at the top of an organization should be able to join a working session without days of prep and everyone between them needing to attend. (Practiced corporate operators will note that this is almost never the case, which is a tax on our productivity.) - **Reporting relationships** describe a particular kind of accountability and support, both focused on the performance, staffing, coaching, priority-setting and administrative realities of employment. - **Job levels** describe expectations of scope, complexity, capability and impact. They are also entangled with career progression and compensation[\[2\]](#fn2). - **Organizational layers** describe the scope of decision authority: a product, a business, a network of sites or an entire enterprise.[\[3\]](#fn3) Each should have decisions that belong to that larger whole.[\[4\]](#fn4) --- 1. It’s also an appealing picture if you’re hoping to get rid of a bunch of seemingly low-value-adding managerial bureaucracy, but like, *caveat emptor* [↩︎](#fnref1) 2. A surprising amount of hierarchy exists because companies have never developed a satisfying answer to: "How do we tell someone they are important without giving them more people?" [↩︎](#fnref2) 3. Philippe Aghion and Jean Tirole make an adjacent distinction between formal authority (the right to decide) and real authority (effective control over decisions). [Formal and Real Authority in Organizations](https://doi.org/10.1086/262063?ref=cpj.fyi) [↩︎](#fnref3) 4. This extends Amy Kates and Gregory Kesler’s idea of unique value-adding layers and an anchor layer where consequential trade-offs are made. Rather than starting by asking what unique value a proposed layer adds, start with viable units and ask which recurring decisions cannot remain inside them. [Activating Global Operating Models: The Bridge from Organization Design to Performance](https://doi.org/10.7146/jod.18122?ref=cpj.fyi) [↩︎](#fnref4) VP, Product Eng manager Design manager Senior engineer Engineer Researcher Junior designer **The org chart.** Everything, everywhere, all at once. Bold of me to suggest that Eng and Design report to Product; this is just a sketch. **Working.** Follows the work; the engineer and designer pair directly. **Reporting.** Performance, staffing, coaching. L7L6L5L4L3 **Levels.** Scope and pay. In this example, people in different layers are paid the same. **Decisions.** Who decides what, for which whole. A company might therefore have multiple, varied scales of decision-making, five reporting steps and ten job levels. Counting reporting steps tells us something about how people are managed. *To understand the work, we still need to know who can decide what.* Design separately, connect deliberately. A reporting step can add management capacity without creating a new layer of decision authority; a higher job level can recognize greater scope without adding reports; working relationships can cross both. First, write down the work that is overloading the leader. Coaching, allocating assignments, developing people and making technical decisions *do not all have to belong to one person*. [*Hidden Patterns'* distributed management pattern](https://www.cpj.fyi/14-distributed-management/) separates these responsibilities and gives them explicit owners, with time and resources to do the work. In a team applying this pattern, an experienced colleague might take responsibility for coaching, while another coordinates assignments. The formal manager still handles the employment decisions that belong to that role, like comp, hiring/firing, performance eval, etc.. The team needs to know who owns these responsibilities and how to get help. Distributing the work is a design choice; adding a span breaker is one of many possible responses to an overloaded manager.[\[1\]](#fn1) The same test applies when *removing* managers. Coaching, staffing and exception handling still need owners. If that work moves into recurring meetings or into team members' evenings, the organization has changed who does it without necessarily reducing the burden. Hamel and Zanini's [Bureaucracy Mass Index](https://www.michelezanini.com/speaking/?ref=cpj.fyi) examines costs such as unnecessary paperwork, redundant reviews and slow approvals. After a redesign, the thing to check is whether people need fewer permissions and spend less time servicing internal processes, which a smaller chart can't necessarily tell you. --- 1. An architecture role or a program role can also hold authority over shared decisions. The title does not settle whether it creates a layer of work. Ask what it can decide, for whom, and which decisions remain with the teams. [↩︎](#fnref1) From One hierarchy for work, management, status and authority → To Four overlapping systems, designed separately ## *Find the decision escapes* *Quick aside here: corporate euphemisms are occasionally useful! In manufacturing, a defect that passes the controls intended to catch it is often called a* quality escape*.* *This might seem like a great example of* past exonerative tense*, but IMO there’s a nice distinction being made here. The term separates the existence of a defect from the failure of a system to catch the defect.* The same distinction works well in OD. If we start by defining a unit that can own a meaningful result and make most of the choices required to produce it, and then look for the *decisions* that escape that boundary because they commit another unit's resources, change its constraints or affect a shared outcome, we can design a system of layers that serves the work. To do this, we start our design work with the smallest unit in the organization that can operate as a meaningful whole. Depending on the business, that might be a product, a geography, a customer segment, a site, a service line, a value stream or even a small “business within a business”. Four things tend to be true about these units: 1. They own a real external result. Its success should be expressible in terms of a customer, market, product, mission or operating outcome rather than the completion of an internal activity. 2. They control enough of the inputs that produce that result. Accountability without meaningful control is an **escalation machine**: the unit is held responsible for an outcome while continually asking somebody else for the things required to produce it. 3. They contain most of the tightly coupled work. The people inside the boundary generally need one another more often than they need people outside it. (This also means that they probably describe things in ways that might feel unfamiliar to others in the organization; note that “quality” means something different to someone designing an interface versus someone designing a supply chain.) 4. They are capable of local adaptation. When conditions change, they should be able (and allowed!) to alter their work without renegotiating every important choice somewhere else. We can refer to such a unit as a **smallest viable whole**. They are usually team-shaped and human-scaled. (AI lets us design for more of these and less of our traditional managerial hierarchies, which is why I’m writing this article, but the same ideas apply regardless of the sorts of intelligences involved. Anyway![\[1\]](#fn1)) --- 1. If broadly capable intelligence becomes abundant and cheap, access to intelligence stops being much of a differentiator. But...What problems are worth solving? Which trade-offs should we make? Where does authority belong? What should the organization learn? What should it forget? Building from Rumelt, advantage shifts from generating plausible actions to maintaining coherence among them. Collective memory is the new intellectual property? [↩︎](#fnref1) Most organization design starts at the other end, with the CEO's directs, the executive committee, the available leaders and/or the desired number of layers. Then we cascade downward, dividing and grouping until everyone has somewhere to go. Instead, specify the decisions the unit can make, the resources it controls and the constraints it must respect. The design problem then becomes easier to see: which decisions cannot stay inside that boundary? When an organization is full of these units, it will produce (perhaps a large number of) decisions the units cannot make on their own. These decision escapes happen when one unit tries to commit another unit's resources, or change the conditions under which others operate.[\[1\]](#fn1) ### What cannot stay local? Suppose three teams can each make perfectly good decisions independently, but they depend on the same underlying account system. One wants faster signup. Another needs stronger fraud controls. A third needs administrators to manage hundreds of users. Each can optimize its own product and make the shared system worse for everybody else. --- 1. There are competing accounts of why hierarchy appears. Luis Garicano models hierarchy mainly as a way to route uncommon or difficult knowledge problems to specialists. Eucman Lee, Ekin Ilseven and Phanish Puranam instead model hierarchical growth as a response to conflict within and between groups, showing that more self-contained teams can scale with less hierarchy. The “decision escape” idea here is closer to the second mechanism, and still applies even if expertise itself becomes cheap. Garicano, [Hierarchies and the Organization of Knowledge in Production](https://doi.org/10.1086/317671?ref=cpj.fyi). Lee, Ilseven & Puranam, [Scaling Nonhierarchically](https://doi.org/10.1002/smj.3541?ref=cpj.fyi) [↩︎](#fnref1) n–2 Company / portfolio n–1 Account / identity platform n **Signup**Faster signup*Removes fields and steps* **Fraud**Lower fraud losses*Adds verification* **Enterprise admin**Easier user management*Adds SCIM and admin controls* **Signup × Fraud**One takes a step out; the other puts one back. **Fraud × Admin**Bulk-provisioned users skip the new verification. **Signup × Admin**Self-serve accounts land outside the admin directory. There may be an easy engineering/standards answer here, that starts with seeing whether the teams can agree on a stable interface and clear rules for changes. They might separate the signup flows, agree on a common verification requirement or give one team ownership of the shared service. If that resolves the conflict, they do not need a new authority above all three products.[\[1\]](#fn1) Say Signup wants to remove a verification step. Signup and Fraud agree that Signup can run a limited test and expand it once the fraud data comes in, provided losses per thousand signup attempts stay within 5% of the control group.[\[2\]](#fn2) If losses cross that threshold, Signup pauses the rollout. The teams have settled in advance what happens on either side of the line. If Signup wants to accept higher losses in exchange for more new customers, somebody still has to make that trade-off for the business. But suppose the same teams keep competing for scarce engineering time, and a choice about one product repeatedly changes what the others can deliver. *Someone or something* may need standing authority to set priorities for the shared system and resolve those trade-offs. That person or group needs a defined decision to own, such as making allocation tradeoffs for the account platform's capacity among the products. A permanent layer is justified only after we can explain why a clearer interface, a rule, a peer agreement or a temporary forum will not handle the recurring decisions. --- 1. Phanish Puranam, Harbir Singh and Saikat Chaudhuri show that interdependence creates pressure for structural integration, but shared “common ground” can substitute for formal integration in some cases. [Integrating Acquired Capabilities: When Structural Integration Is (Un)necessary](https://doi.org/10.1287/orsc.1090.0422?ref=cpj.fyi) [↩︎](#fnref1) 2. Shoutout to Patio11's legendary [The optimal amount of fraud is non-zero](https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/?ref=cpj.fyi) [↩︎](#fnref2) 1 A clearer interface A stable, versioned interface and clear rules for changing the account system. 2 A rule One verification requirement every signup flow must meet. 3 A peer agreement One team owns the shared service; the others request changes. 4 A temporary forum A review of platform changes with all three teams, and an end date. 5 Standing authority Someone owns the allocation of shared engineering capacity across the three products. Adds a place information can stop, another set of incentives, another authority relationship, another claim on everyone's time. Permanent organizational layers are expensive coordination mechanisms. They introduce another place where information can stop, another set of (often career-driven) incentives, another authority relationship and another potential claim on everybody's time. So they should be reserved for problems that are consequential, recurring and genuinely require standing authority over a larger whole. From here, we can define a **layer of work** as **standing authority over recurring decisions for a larger whole.** Reporting relationships may support that authority, but the decisions are what distinguish it from another step in people management. "Provide strategic direction" is not enough. "Ensure alignment" is not enough. "Connect strategy to execution" is *definitely* not enough. Identify the recurring decision escapes instead. For the account system, it's how to allocate shared engineering capacity and approve changes that affect all three products. "Ensure alignment" would leave the teams negotiating the same conflict every week. From Layers defined by spans and reporting lines → To Layers that emerge from unresolved interdependence between viable units ## *The purpose of hierarchy is autonomy* Hierarchy and autonomy are usually presented as opposites. And like…*sure*. I get it! Badly designed hierarchies do be that way, piling up approvals, reviews and escalations until our teams can barely do *anything* without asking permission. A good layer does the opposite. It settles a recurring class of problems the units below can't solve on their own, and in doing so gives them a more stable working environment. Autonomy too is an idea so badly implemented that it has come to mean either nothing at all or the opposite of its definition. It *should* mean that a team knows which decisions it can make *without outside approval* and which it cannot.[\[1\]](#fn1) A useful higher authority may restrict some choices while making a much larger set of local choices dependable. Consider three factories sharing a scarce component. Each site manager is accountable for delivery, so each has a reason to reserve more stock; taken together, those local decisions can prevent another site from shipping. A network leader can own one shared decision—how the scarce component is allocated—while sites retain authority over shifts, production sequence and delivery commitments within that allocation. If the network leader starts approving those local operating choices too, the layer has exceeded the decision that justified it. That is the test I would use in place of a generic claim that a layer "needs to add unique value": what can the units below now do without asking? If a layer mainly requests presentations, translates messages from above and adds approvals to decisions teams could make themselves, it's consuming the autonomy it was supposed to create. ### Give a layer a contract Once a layer is separated from reporting and seniority, you can write down what it's for. I'd do that as a short contract, built from decisions people have actually made. Take ten or fifteen consequential choices from the last year, such as a pricing change, a launch, an investment shift or a customer exception. Replay who needed information, who controlled the resources, who was consulted and who could approve or refuse. *Real decisions are harder to bullshit.* For each decision, ask which unit could have owned it and what would have happened if that unit acted independently. If consultation turned into approval, identify why. If a decision skipped a layer, ask what that layer was supposed to contribute. Repeated conflicts between the same teams may reveal a useful larger unit, or an interface that needs repair. Use those cases to write a short contract for each proposed layer. #### 1\. What whole does it integrate? Name the product domain, business, site network or enterprise whose shared decisions it owns. Explain what those units cannot resolve independently. Answers to this question will often average to "the same business with broader oversight." This does not identify additional work; push back. #### 2\. Which decisions live here? List the recurring decisions in concrete terms. "Allocate investment among these four businesses" is clearly a statement of authority. "Own strategy" leaves almost everybody able to claim the same work. If adjacent layers claim the same decision, specify their different rights or remove the duplication. #### 3\. Which interdependencies require it? Describe the consequence of independent action: a competing claim on scarce capacity, a change to shared architecture, a commitment made on behalf of another unit. Record why a rule, interface or peer agreement is insufficient (bonus points if you’ve actually tried one of these ideas and proven that it doesn’t work, rather than simply worrying about it!). If redesigning the units would remove the conflict, consider that *before* adding authority. #### 4\. What autonomy does it create below? This is the most important question. Write down the decisions teams can make without further permission, the resources they can rely on and the conditions that justify escalation. Include a way to check whether repeated negotiations and approvals actually decline. This should all fit tidily onto a single slide (🙄, I know). Review it when the work changes: a platform, a standard or a different team boundary may remove the need for authority that was once necessary. ### Design the work before you staff it However: organizations are made of people, and people are special, unpredictable, human. A leader leaves; somebody needs a promotion; a strong executive has unusual capabilities that are almost impossible to describe, let alone replicate; a successor is apparent, but *not quite* ready; a previously beloved and valuable member of the team has become difficult to place as the org has grown; another person is far too valuable to lose, but our spans and layers guidance says that they should go. These are real design inputs, and pretending otherwise produces its own kind of silliness. (These design inputs are the ones that the top of the house tends to prioritize; pushing for a rigid structural approach kills the credibility of those pushing it.) These inputs are often unspoken and hard to verbalize. Leaders know things about capability, trust and judgment that no abstract design process can capture completely, often simply because it’d be ridiculous to suggest we build a dossier on each of thousands of people before doing the design work. Those same inputs are also how a “clean” design comes apart over time. A structure designed around one unusually capable person can persist for years after that person leaves. A role gets expanded because somebody is senior, then its scope becomes part of the official hierarchy. A temporary landing place acquires staff, a budget and eventually a strategic rationale. A vacancy disappears from the chart even though its work never disappeared. We should stop trying to have clean designs, and accept more model variability throughout the organization. Instead, leaders should use their judgment about capability, trust and development, while making temporary arrangements explicit[\[2\]](#fn2). When somebody says, "I trust this person to run it," *ask* *what that means*. Which decisions do you trust them to make? What whole can they integrate? Which competing interests can they reconcile? What depends on them personally? What would still need to exist if they left? Write down that enduring work, and then staff it. Sometimes the person and the work will not line up neatly. If one person covers two roles, record both roles and review the arrangement later. If a very senior person takes a role with less decision scope, do not enlarge the role simply to match their seniority; handle level or compensation separately. If someone needs a role during a transition, make the assignment explicitly temporary. If a successor is not ready, add temporary support rather than redesigning the role around the capability gap. A staffing problem can justify a staffing exception. It doesn't automatically justify a permanent structural change. So: would we still need these decisions to have an owner if the person currently making them left tomorrow? If yes, design the role around that work. If no, describe the arrangement as an assignment for this person, with a reason and a review date. --- 1. Some teams I’ve worked with have told me that there are literally no decisions they can make without outside approval. Dark! [↩︎](#fnref1) 2. I have become less interested in clean organization designs. Cleanliness is evidence that the model has omitted something important: unusual people, transitional arrangements, overlapping expertise, political constraints, or work that doesn't fit into one box. [↩︎](#fnref2) From Hierarchy as supervision → To Hierarchy as standing authority over shared decisions ## *So how many layers should a company have?* I still don't know, and I don’t even think we should try to solve this problem.[\[1\]](#fn1) A manufacturing network, a bank, a software company and a professional-services firm will have different decisions to coordinate. Even within one company, regulation, shared infrastructure and the completeness of its operating units can create different needs. The number of reporting steps cannot tell us whether those decisions have been placed well. I do know that there are millions of people working in mediocre hierarchies today that get in their way, or in matrices that are specifically designed to produce slow, stable consensus. We could achieve so much more as a working society if we designed in favor of autonomous teams.[\[2\]](#fn2) Further to that point, any answer here ought to be easily changeable if we actually manage to separate it from career trajectories. As teams gain capability or shared services become easier to use, some decisions can move down without that coming at an individual’s loss of power. Growth or new dependencies may move others up. We need to be able to quickly adjust authority when the work changes. Design units that can own an outcome. Give shared decisions a clear owner. Specify what teams can then do for themselves. Once those choices are clear, you’re free to count the layers. --- 1. Two useful counterweights point in opposite directions. Pace Layers is one; layers can be designed to match the pace of the org around it. There's also Michael Ewens and Xavier Giroud’s September 2026 revision of [“Corporate Hierarchy”](https://www.nber.org/papers/w34162?ref=cpj.fyi) finding an average of six layers across 3,454 U.S. public firms; more-layered firms have higher internal promotion, longer tenure, higher operating performance and more patents, while flatter firms did better during the COVID shock. In other words, “fewer layers” is not an empirical law either. [↩︎](#fnref1) 2. A matrix is often described as a sophisticated response to multiple dimensions of interdependence. It was originally designed to diminish the appearance of authority and emphasize consensus as the default way of working. YMMV! [↩︎](#fnref2)