I am noticing a trend: many companies are discussing "excessive layers of management." Normally, this would excite me, as I'm a fan of flatter (but not overly flat) organizations.
But I worry that companies aren't learning from past mistakes. They tend to focus on a narrow/biased set of explanations for why the organization got too tall and now needs to be "flatter" instead of taking a holistic view.
So how/why do companies get "too tall"? At a high level, it is either:
The team is too big. An organization might become too tall simply because it got too big. Its height is largely a function of team size. If the company can't sustain such a large team—especially when facing market challenges, competition, or budget constraints—it may need to reduce layers to become less tall. Because of the sensitivity of discussing market challenges, I sense that companies discuss this less often.
Or…
It was difficult to get wider. As the organization grew, it couldn't figure out how to get "wide" (i.e., absorb more people without adding layers).
Narrow Spans of Control. The organization struggled to increase spans of control and team-to-manager ratios, leading to more layers instead of a broader structure. In the next section, we will explore this further.
Dependency Management and Oversight Needs. Coordinating complex dependencies required more layers for oversight, making the structure taller. This challenge could stem from the complexity of the product offering, domain, business model, or team organization (see below).
Model Limitations. Perhaps they adopted a business unit model, but the units were not independent enough to function autonomously. Or they used a functional model, and functions struggled to coordinate and collaborate effectively, leading to additional layers to bridge gaps. Or they tried to have their cake and eat it to by having some parts of the org be BU focused, and others be functional, and that didn’t work. In theory, the BU and functional models let you get wide, but that relies on a couple of core assumptions around coordination costs holding true.
That's a high-level view. #1 and #2 have a multitude of contributors.
Below, I dig deep into the full range of reasons why either 1) a company adds layers or 2) struggles to increase spans of control.
The Reasons
Knowledge, skill, and experience. Less experienced managers are typically more effective with smaller teams. Less self-sufficient teams require more guidance and oversight. Insufficient time (or tools available) for training, coaching, and knowledge-sharing tends to put more burden on managers. I recently met with a manager who paid out of pocket for training and became one of the few people I've ever met to escape a PIP when their span of control was doubled, and they got overwhelmed. They were up for the challenge—they just needed some support. Even experienced managers can struggle when thrown into the fray without sufficient knowledge sharing and onboarding, especially when the organization is difficult to navigate.
Board and investor optics. External stakeholders may push for certain roles (e.g., CPO instead of a VP of Product) because they signal organizational maturity, stability, etc. These roles insert layers where they might not be currently necessary.
New teams and anticipated growth. A team starts small with the intent of growing the team. At a larger scale—especially given the time it takes to get a growing org humming—you might see an effort to get the org chart "right" but with fewer team members. The idea was to "grow into" the org chart. If growth stalls or doesn't materialize, and the budget is cut, you might be left with fewer team members per manager than planned. New efforts also tend to be more dynamic, uncertain, and fast-moving, sometimes necessitating smaller teams in general.
Career growth opportunities. To give people growth opportunities, companies sometimes promote individuals into hybrid, pseudo-manager roles involving managing a small group alongside being an individual contributor.
Beliefs around ideal team size and manager ratios. A company strongly prefers teams with fewer than six members (for example). Given the significant jump from managing six direct reports to twelve (or twelve to eighteen, etc.), managers might be biased toward keeping the lower ratio, leading them to cap at around six, even if they could theoretically support an eight, or ten-person team, or two five-person teams. This preference creates a natural tendency for lower ratios.
The culture around team vs. individual projects. Some cultures rely on managers to essentially "farm out" individual projects to keep individual team members engaged, appropriately challenged, and busy. Other cultures take a more collectivist, team-oriented approach, whereby the manager spends more time managing the team and less time coaxing projects from individual team members. This has a big impact on the manager's day-to-day focus (a lot of context switching between team member efforts) and also ends up encouraging higher levels of work in progress.
Team members with dissimilar projects and varied focus areas/collaborators. When individual team members are working on diverse problems or collaborating with people outside the team, it adds significant complexity to the manager's role. This variety requires the manager to stay current on multiple domains, coordinate with different external partners, etc. (vs. managing a set of related projects where goals and processes might be similar).
Between team coordination efforts and administrative overhead. If a manager spends a significant amount of time coordinating with their peers on other teams (dependencies, specs, scope, etc.), they will have less time available to manage their team and can, therefore, effectively manage fewer people. Similarly, if they spend a day a week filling out status updates, making ad-hoc decks, navigating onerous performance management processes, etc., they will also lose bandwidth.
There is a high work-in-progress (WIP). This impacts everyone in the organization, but when teams do a lot more starting than finishing and juggling a lot of work at once, everyone is paying a tax. In many cases, the burden falls on managers to play the Tetris game, which causes a big drain on capacity.
Reactive work, interrupts, etc. When managers have to jump into the fire of the day—outages, last-minute requests, troubleshooting, playing team defense, etc.—it eats into their time to be a great manager. What tends to happen is that they are scattered and unable to manage up properly. In addition to simply having less bandwidth available to manage more people, there's also a tendency to start layer buffering.
Frequent realignment and re-prioritization. When team objectives are in flux, managers must frequently communicate new priorities, clarify goals, and realign team efforts. This constant recalibration demands time and attention, as managers help their team members understand the evolving mission, adjust their work, and set new short-term objectives. In this environment, managers cannot oversee additional team members effectively. The issue bubbles up to their manager as well.
Tenure and turnover. When tenures are short and turnover is high, managers must spend a lot of time rebuilding their team, onboarding new team members, handling departures, working to rebuild the team's morale, etc. This makes it difficult to manage more people effectively.
Role ambiguity. When job design isn't well thought out, team members may struggle to understand their responsibilities, goals, and priorities. This ambiguity leads to a higher need for oversight, guidance, and regular check-ins as managers help employees clarify their roles, prioritize work, and interpret expectations. This drains the manager's capacity.
Like the newsletter? Support TBM by upgrading your subscription. Get an invite to a Slack group where I answer questions.
Buffering between layers. It doesn't take a lot to go wrong for someone to rationalize adding a layer of more ostensibly mature and seasoned managers/leaders. This could be to "defend" front-line teams from imposing leaders or to provide a layer of more experienced filtering between front-line teams and leaders and vice versa. In my experience, often, the catalyst is a "big meeting" that feels unwieldy and goes a bit off the rails.
Symmetry with other departments. When other departments across an organization start adding layers due to their size, you sometimes find an effort to keep some sort of symmetry between groups. For example, if Sales suddenly has SVPs, that sets the precedent that SVPs are a thing, and you see them cropping up in other departments (whether needed or not).
Symmetry within a department. Imagine a large R&D org. Some efforts are 0/1 efforts with small, nimble teams. Other efforts have huge (and tall) teams. This might create pressure to normalize hierarchy levels between the teams—with a default to mimicking the larger teams—even when they aren't needed.
Domain breadth and specialization. Say a manager has extensive domain specialization in one area of the product. They don't manage many people because the domain itself doesn't require many people. It is less likely that they will be invited to manage a sufficiently different domain even if they could effectively manage more people. This dynamic might be exacerbated if the organization is structured around very narrowly defined domains rather than more broad domains like customer personas, goals, workflows, etc.
Overall structural fluidity. Some companies continuously restructure and reshape the organization (without reducing staff size), and role fluidity is encouraged. Other companies almost never restructure, and when they do, it is pretty violent. I think it might have been Pinterest, but at one point, an executive there said something: "We try to make restructuring a positive thing instead of a negative thing."
Remote and hybrid. I sincerely believe you can remain relatively "flat" while working remotely. Some companies pull it off. But it requires a whole new set of habits and behaviors to make it work (e.g., a writing culture, working async, etc.). Many companies tried to graft how they worked before the pandemic to a remote setting without adapting. In some cases, this made for taller organizations and made it challenging for managers to manage more people effectively.
Executive span of control as a model for the organization. Sometimes, the span of control at the executive level sets an implicit model for the rest of the organization. If the CEO or executive team has a broad span, this can influence the rest of the organization to keep flatter structures. Conversely, if executives operate with narrower spans, that preference for closer oversight might ripple downward, affecting the overall structure.
Trust and delegation culture. An organization's culture around trust and delegation influences structure. Companies that emphasize trust and decentralized decision-making can often operate with flatter hierarchies, while cultures requiring more oversight and control might favor narrower spans, leading to taller structures. In high-trust environments, managers may delegate more and effectively support larger teams.
I hope this overview was interesting. If your company has recently discussed getting "flatter," hopefully, the list here provides a comprehensive summary of the reasons for extra layers and reduced spans of control.
Like the newsletter? Support TBM by upgrading your subscription. Get an invite to a Slack group where I answer questions.
@John Cutler an interesting follow-on post would be about why organizations get “too short”. To your point, that there is such a thing as over-flattening.
Its a topic I talks and deal with a lot.
I'm interested to see how you think about the reason for scaling. To be precise I don't believe or want to talk about a degrowth angle. For me its just that I Don't always understand why a company wants to hire more people. More people is automatically more complexity, which you want to avoid or only add if it brings more value. A multi feature product for example can service more different customers and so your business grows. But like I point out, I can only justify that in my mind in a multi product/service setup. If I hear stories that 100+ people are working on the spotify music player or there is a team that works on the like button at facebook. I'm really baffled: Why?