Hierarchy is a latency bug: why adding managers destroys velocity

Companies often face two opposite but similar errors when defining their hierarchy. Usually, it is easier to define the organizational design by dividing engineers into specific product areas. It is much harder to correctly define the hierarchy above them.

Startups often begin with no hierarchy at all. Then they move to a flat structure. But as teams grow, especially if you have properly separated their perimeters and objectives, communication and coordination problems emerge.

The Illusion of Specialization

Until recently, the market trend was to solve these problems through heavy role specialization. Companies created Architects, Quality Assurance Engineers, Cloud Managers, and Development Managers.

Today, with Artificial Intelligence driving the cost of code to zero, many of these highly specialized functions have lost their meaning. The concept of a "pure coder" is obsolete. We transitioned from having a single programmer to having five different roles doing the same thing, and now AI is forcing us to iterate back. The principles of good organizational design, however, remain entirely valid.

When a growing company faces internal communication issues, the immediate reflex is to introduce a new manager. Obviously, one manager cannot effectively oversee fifty direct reports. But this logic only applies to the first level of management where a leader handles two or three teams maximum.

When teams multiply, companies start adding Managers of Managers, and then Managers of Managers of Managers. They create functional macro-areas called Domains. They add cross-functional groups like Excellence Teams or Platform Teams, each with their own leadership. All these separate functions are then grouped under an ultimate umbrella manager.

Bureaucratic Garbage and Decision Latency

Having managers is important. But building an articulate structure of excessive coordination figures, or temporary "Champions" for cross-team initiatives, is a toxic symptom. Putting multiple hats on the same people is not a substitute for hiring properly. A complex and heavy managerial structure is a glaring symptom of a failed organizational and software architecture.

Instead of going to the source and fixing the root problem, companies resolve the friction by increasing complexity. This is driven by a culture of control and bureaucracy. If a company wants millimeter-level control over every employee, it needs a massive fleet of managers and controllers to verify expectations.

Communication has a delay. The more managers you add, the more communication bottlenecks you create. Information flows from the top down, then must travel back from the bottom up. You are injecting pure decision latency into the system.

When this latency becomes excessive, people start bypassing the hierarchy. They talk to each other without criteria and the organization falls into chaos. The absolute worst-case scenario occurs when a simple operational decision requires getting a massive group of people to agree. You lose hours and days in useless alignment meetings, recap emails, processes, and "Ways of Working" documents. This bureaucratic garbage completely paralyzes the organization and slows it down until it fails.

Resolving Conflicts at the Lowest Level

The solution is not simply deciding how many direct reports each manager should have. You must go back to the drawing board to understand the correct perimeter for each team and each manager.

You must drop micromanagement entirely. If you need many managers to control the output, it means someone is micromanaging. This is absolutely lethal for the company because your most competent people will switch off their brains and stop producing value.

You must maintain a lean structure where every person is adequately guided, ensuring no one has to wait three weeks for a 1-on-1 meeting. More importantly, any conflict or indecision must be resolved at the lowest possible level of the hierarchy.

It is unacceptable that an indecision requires an escalation across three managerial levels to be resolved. You are forcing a decision onto a person who has absolutely no idea about the context. You have not just created an enormous delay; you have burned money in paralysis, alignment meetings, and email bureaucracy. Fewer actors mean less communication required.

Business Goals and Asynchronous Communication

Every team must be as autonomous as possible. If you have not correctly defined the team's objectives, they cannot be autonomous.

These must be business objectives, not technical ones. You do not tell a team how to do something or what to do technically. You tell them the goal, where we want to go, and the principles to follow.

To enable this, the bulk of your communication must be asynchronous. If you rely on RFCs (Request for Comments), ADRs (Architecture Decision Records), written documentation, and clear contracts between services and team perimeters, the paradigm shifts. Communication moves from "I must come tell you what to do" to "I need information, I will retrieve it". Things instantly become faster.

The Collaboration Red Flag

If multiple teams must constantly collaborate to carry out a single initiative, you have designed your organization wrong. Alternatively, your software architecture is not following the organization.

An even more severe red flag is when the entire organization must execute a single initiative, forcing all managers to talk to each other. A common objection is that the product must evolve in its entirety, so the whole company must be involved. This is completely wrong. If you find yourself with a multitude of Managers of Managers discussing what to do, you will go nowhere.

This happens when goals are vague, like "we want to get rich", or when top management dictates the solution instead of the objective. Goals must be concrete, real, and measurable. One team might have the objective to improve the conversion rate. Another team might focus on improving the time to complete a purchase. Objectives must be specific enough for a team, but generic enough not to dictate a technical solution.

When a company constantly finds itself defining new interaction protocols, manifests, and processes, it is time to stop. Erase everything and restart from the fundamentals: Organization, Architecture, and Objectives.

It Starts with Trust

This might sound abstract. You might be dealing with an organization that has dozens of systems and 30-year-old gigantic monoliths. You might not achieve perfection on day one, but you can still do a lot.

Start trusting the people in your teams. Reduce managerial pressure. Suppress the urge to dictate the solution and let the team find their own way. By lightening the governance load, you remove barriers and allow the organization to breathe. This generates small improvements that cascade into massive wins over time.

I have stepped into situations that seemed completely out of control. In reality, it only took a few minor adjustments to give the team clear awareness of where they needed to go and what was happening. That was enough for them to start moving in the right direction, autonomously, without someone needing to tell them what to do every single time.