ℹ️ Note
This is Part 1 of a three-part series on management overhead in software development teams. In this post, we’ll explore the pattern and its costs.
Part 2 examines finding the right balance, and Part 3 covers practical steps for change.
Picture this scenario: you’re running a restaurant. You’ve hired a single talented cook who can prepare exquisite meals. A customer walks through the door, ready to order. And you’ve staffed your restaurant with fifteen waiters, all eager to take that order, discuss the menu, and coordinate the delivery of the meal. It sounds absurd, doesn’t it? Yet this is precisely the situation I encounter repeatedly when working with software development teams across various industries.
I’ve sat on calls where two developers are joined by five to eight people with “manager” in their title. I’ve reviewed organisational charts where the ratio of decision makers to technical implementers is inverted beyond recognition. And whilst these organisations are staffed with intelligent, well-meaning people, they’ve somehow created a structure that actively works against their ability to deliver software effectively. This isn’t a failure of the individuals involved; it’s a systemic pattern that emerges from understandable pressures and well-intentioned decisions. But understanding why it happens doesn’t make it any less problematic.
The Pattern We’re Seeing
Before we explore the causes and solutions, let’s establish what we’re actually talking about. A manager-heavy software team isn’t simply one that has managers; it’s one where the ratio of technical implementers to managerial oversight has become skewed to the point where it actively impedes progress. Research on span of control in software engineering suggests that engineering managers typically handle between five and ten direct reports effectively, with the optimal range often cited as eight to twelve for experienced managers overseeing skilled teams. When we flip this ratio and have more managers than individual contributors, or when the proportion of managerial roles significantly exceeds these benchmarks, we enter problematic territory.
The restaurant metaphor I opened with isn’t just a rhetorical device; it’s a genuine reflection of what happens in many enterprise software teams. Imagine the inefficiency of fifteen waiters trying to coordinate the work of a single cook. They’d spend their time talking to each other about the order, discussing priorities, debating which dishes should be prepared first, and creating elaborate systems to manage the kitchen’s output. Meanwhile, the cook would be constantly interrupted to explain what they’re doing, justify their technical choices, and attend meetings about how they should be cooking. The customer, of course, would still be waiting for their meal, growing increasingly frustrated as time passes.
In software development, this manifests in various ways. You might see a team of three developers supported by a project manager, a product owner, a delivery manager, a programme manager, and two or three stakeholders with decision-making authority. Or you might encounter a scenario where every technical discussion requires the presence of multiple layers of management, each wanting to understand, approve, or influence the decision. The specific configuration varies, but the underlying pattern remains consistent: too many people trying to manage, coordinate, or oversee the work of too few people actually building the software.
This isn’t limited to large enterprises, though they’re certainly more prone to it. I’ve seen startups with twenty employees where half of them have managerial responsibilities. I’ve worked with mid-sized companies where the ratio of “chiefs” to “Indians” (to use an admittedly dated but widely understood phrase) has become so skewed that the organisation struggles to deliver even straightforward features. The pattern transcends company size, though the mechanisms that create it often differ.
The Hidden Costs of Management Overhead
When teams become manager-heavy, the consequences extend far beyond the immediately obvious. Yes, there’s a financial cost; managers typically command higher salaries than individual contributors, and having an excessive number of them directly impacts the bottom line. But the financial aspect, whilst significant, is actually the least interesting part of the problem. The real costs are more insidious and harder to quantify, but they’re far more damaging to an organisation’s ability to deliver value.
Decision Paralysis and the Context-Switching Tax
The first major cost is the impact on decision-making speed and quality. Software development, particularly modern agile software development, requires rapid decision-making at the technical level. Developers need to make dozens of decisions daily: which library to use, how to structure a particular piece of code, what pattern to apply to a specific problem, how to handle edge cases, and countless other choices that collectively determine the quality and maintainability of the codebase.
When the ratio of managers to developers is healthy, developers can make most of these decisions autonomously, escalating only truly significant architectural or strategic choices. They can discuss options with their immediate manager or technical lead, receive guidance based on the team’s broader context, and move forward. The decision-making process is lightweight and enables progress.
When the ratio becomes unhealthy, something different happens. Developers find themselves needing to explain their technical choices to an audience that may not have the technical background to fully understand the implications. This isn’t a criticism of the managers involved; it’s simply a recognition that as people move into management roles, they naturally become more distant from the day-to-day technical work. They may have been excellent developers in their time, but software development moves quickly, and staying current with technical details whilst also handling managerial responsibilities is extraordinarily difficult.
The result is that technical discussions must be constantly translated into business terms, metaphors, and high-level explanations. Each translation takes time. Each explanation requires the developer to context-switch from thinking about the technical problem to thinking about how to communicate that problem to a non-technical audience. And each manager in the room potentially has questions, concerns, or perspectives that need to be addressed. What should be a fifteen-minute technical discussion between two developers becomes a ninety-minute meeting with six participants, most of whom are there to ensure visibility, maintain governance, or protect their particular area of responsibility.
Even worse, the presence of multiple managers often creates a situation where decision-making authority becomes unclear. Developer A suggests an approach. Manager B thinks it sounds reasonable. Manager C has concerns about how it might affect their team’s work. Manager D needs to check with their stakeholders. Manager E wants to see a more detailed proposal before signing off. Suddenly, what should have been a technical decision made by the people closest to the work becomes a political negotiation requiring consensus across multiple management layers. The decision doesn’t get better; it just takes longer and satisfies more stakeholders, which are not the same thing.
The Opportunity Cost of Expensive Meetings
Let’s talk about the financial aspect, but with more nuance than simply “managers cost more money.” When you have a meeting with two developers and six managers, the direct cost of that meeting is indeed substantial. Using UK market rates as a rough guide, a mid-level developer might cost £50-70 per hour (when you factor in employer costs, benefits, and overheads), whilst managers typically cost £70-120 per hour or more, depending on their level. A ninety-minute meeting with this composition could easily represent £800-1,200 in direct labour costs.
But the real financial impact isn’t the cost of the meeting itself; it’s the opportunity cost of what those people could have been doing instead. The two developers could have been building features, fixing bugs, or improving the codebase. The six managers could have been handling their own responsibilities: supporting their teams, removing blockers, or working on strategic planning. Instead, everyone is sitting in a meeting that probably doesn’t require their presence.
Research on software development effort allocation suggests that project management overhead should typically constitute 10-20% of total project effort. When we examine manager-heavy teams, we often find this ratio inverted, with management and coordination activities consuming 40-50% or more of total effort. This doesn’t represent good governance or thorough oversight; it represents inefficiency at scale.
Moreover, the cost compounds over time. Each meeting spawns follow-up meetings. Each decision delayed creates dependencies that delay other decisions. Each context switch reduces the productivity of the developers who are trying to maintain focus on complex technical problems. Studies in software engineering have long recognised that it can take 15-30 minutes for a developer to regain deep focus after an interruption. When meetings are scattered throughout the day, developers never achieve the sustained concentration required for their best work.
Technical Debt and the Quality Trade-Off
Perhaps the most damaging long-term cost is the impact on software quality. When developers are constantly pulled into meetings, explanations, and justifications, they have less time to focus on the quality of their work. Technical debt accumulates not because developers don’t care about quality, but because they don’t have the time to address it properly.
This creates a vicious cycle. As technical debt accumulates, the codebase becomes harder to work with. Simple changes take longer. Bugs become more frequent. The team’s velocity decreases. Management, seeing reduced output, responds by increasing oversight, adding more reviews, and requiring more documentation and justification for technical decisions. This additional oversight consumes more developer time, further reducing their ability to address the underlying quality issues. The problem perpetuates itself.
I’ve seen teams where developers spend 60-70% of their time in meetings, leaving only a few hours per day for actual development work. These same teams inevitably struggle with technical debt, quality issues, and developer morale. The developers know the codebase needs attention, but they don’t have the time to provide it. They become increasingly frustrated as they’re asked to explain why things are taking longer, knowing that the very meetings where they’re providing these explanations are part of the problem.
The Human Cost: Retention and Morale
Finally, there’s the human cost. Good developers are in high demand, and they have choices about where to work. When they find themselves spending more time in meetings than writing code, more time explaining technical decisions to non-technical audiences than actually making those decisions, and more time navigating organisational politics than solving interesting problems, they start looking for opportunities elsewhere.
Developer retention is expensive. Recruiting, hiring, and onboarding a new developer can easily cost six months of salary or more when you factor in recruiter fees, lost productivity during the hiring process, and the time required for the new developer to become productive. When manager-heavy teams experience high turnover, the organisation pays this cost repeatedly, never building up the stable, experienced team that would actually be more capable of working autonomously with less oversight.
Even developers who don’t leave may become disengaged. They may reduce their effort to match what’s expected in the meeting-heavy environment. They may stop proposing innovative solutions because the overhead of getting buy-in is too high. They may become defensive, focusing on covering themselves rather than taking ownership of outcomes. The organisation ends up with a team that’s going through the motions rather than genuinely invested in the product’s success.
Why Smart Organisations End Up Here
If the costs are so significant, why do organisations end up in this situation? It’s tempting to attribute it to poor leadership or organisational dysfunction, but the reality is more nuanced. Manager-heavy teams usually emerge from a series of individually rational decisions that collectively create an irrational outcome. Understanding these mechanisms is essential to addressing the problem, because if we don’t understand the forces that created the situation, we’re unlikely to successfully change it.
Risk Aversion and the Illusion of Control
One of the primary drivers is organisational risk aversion. As companies grow, they naturally become more cautious. Early-stage startups can afford to move fast and break things because they have little to lose. As companies mature, acquire customers, and build revenue, the consequences of mistakes become more significant. A bug that causes downtime might affect thousands of users. A security vulnerability could lead to a data breach. A poor architectural decision might require months of work to rectify.
Management responds to this increased risk by adding oversight. If one manager provides some protection against poor decisions, surely two managers provide more? If reviewing technical decisions helps catch mistakes, surely reviewing them with more stakeholders ensures better outcomes? This logic seems sound in isolation, but it fails to account for the diminishing returns of additional oversight and the costs of coordination overhead.
The irony is that excessive oversight often creates the illusion of control without providing actual risk reduction. When decisions pass through multiple layers of approval, organisations feel like they’re being thorough and careful. In reality, they may simply be spreading responsibility so thinly that nobody feels genuinely accountable. The decision isn’t necessarily better; it’s just taken longer and involved more people. Meanwhile, the delays and coordination costs may actually increase risk by reducing the team’s ability to respond quickly to issues when they do arise.
Research on software development overhead has shown that as teams grow, coordination costs increase non-linearly. Brooks’ Law famously states that adding people to a late software project makes it later, precisely because of these coordination overheads. Yet organisations often respond to delivery challenges by adding more oversight rather than addressing the structural issues preventing the team from working effectively.
Compliance, Governance, and Regulatory Pressures
For many organisations, particularly those in regulated industries, the manager-heavy structure emerges partly from genuine compliance requirements. Financial services, healthcare, and other regulated sectors face real obligations around documentation, approval processes, and separation of duties. These requirements are not optional, and organisations that ignore them face serious consequences.
The challenge is that organisations often interpret these requirements more broadly than necessary, or they apply regulatory overhead uniformly across all work rather than distinguishing between high-risk activities that genuinely require additional oversight and routine work that doesn’t. A bank might need rigorous approval processes for changes to their payment processing system, but applying the same level of oversight to a minor user interface improvement in an internal tool is probably excessive.
Moreover, organisations sometimes confuse compliance with managerial involvement. Compliance typically requires documentation, review, and approval, but it doesn’t necessarily require those activities to be performed by managers. A senior developer or technical architect can often fulfil these requirements just as effectively as a programme manager, with the added benefit that they have the technical expertise to make the review meaningful rather than performative.
The result is that organisations build management structures designed to satisfy regulatory requirements, but then those structures take on a life of their own, expanding beyond their original purpose. What began as a necessary governance layer becomes an organisational pattern that gets applied broadly, even where it’s not required.
Historical Growth Patterns and Organisational Inertia
Many manager-heavy structures emerge from how organisations grow over time. Companies often start with a flat structure where founders or early employees wear multiple hats. As the company grows, they hire specialists: a project manager to coordinate work, a product manager to define requirements, a delivery manager to track progress. Each hire makes sense in isolation, addressing a genuine gap in capability or capacity.
However, organisations rarely revisit these structures once they’re in place. The project manager who was hired when the company had five developers is still there when it has fifty developers, often with their own team now. The delivery manager who was essential for coordinating a complex project becomes a permanent fixture. Multiple layers accumulate over time, each addressing a specific need at a specific moment, but collectively creating a structure that’s far heavier than necessary.
This is compounded by the fact that reducing management layers is politically and emotionally difficult. Managers are often well-liked, valued members of the team. They have relationships, institutional knowledge, and genuine contributions. Suggesting that the organisation might benefit from fewer managers can feel like a personal criticism of the managers themselves, even when the intention is purely structural. As a result, organisations tend to add management layers more readily than they remove them, creating a ratchet effect where the management-to-IC ratio steadily increases over time.
The Stakeholder Inclusion Trap
Another common cause is the desire to be inclusive with stakeholders. Modern software development emphasises collaboration, transparency, and stakeholder engagement. These are genuinely valuable principles; software that doesn’t meet stakeholder needs is wasted effort, regardless of how well-engineered it is. The challenge comes when organisations interpret stakeholder engagement as requiring stakeholder presence in all technical discussions.
I’ve seen this manifest in various ways. A technical design meeting that should involve three developers becomes a meeting with twelve participants because “sales needs to understand the technical approach” and “we should include customer success so they know what’s coming” and “finance should be there to understand the cost implications” and “someone from legal should review the data handling approach.” Each inclusion seems reasonable, but collectively they transform a focused technical discussion into a large, unfocused meeting where the actual technical decisions get lost in broader organisational concerns.
The root issue is conflating different types of communication needs. Stakeholders genuinely need to understand what’s being built, why it’s being built, and when it will be available. They don’t necessarily need to participate in the technical decision-making process itself. Effective communication can happen through documentation, regular updates, and targeted discussions at appropriate points, rather than requiring universal presence in all meetings.
Fear of Technical Decisions and the Manager as Translator
Finally, there’s a more subtle dynamic at play in many organisations: a fundamental discomfort with allowing technical decisions to be made by technical people without management oversight. This often stems from past experiences where technical decisions had unexpected business consequences, or where technical teams built things that didn’t align with business needs.
The response is to insert managers as intermediaries, translating between technical and business concerns. The manager’s role becomes ensuring that technical decisions align with business objectives, that developers understand the broader context, and that the business understands the technical constraints. This seems sensible, but it can create a dynamic where technical authority becomes diluted and decisions require management approval even when they shouldn’t.
There’s a world of difference between having managers who provide context and guidance to technical teams versus having managers who need to approve or oversee individual technical decisions. The former is valuable leadership; the latter is micromanagement that scales poorly. When organisations don’t trust their technical teams to make good decisions within appropriate boundaries, they often respond by adding more management oversight rather than investing in developing their technical teams’ business acumen and decision-making capabilities.
Coming up in Part 2: We’ll explore what healthy team structures actually look like, when you genuinely need more management presence, and how to find the right balance for your organisation’s specific context.
💭 Are you seeing these patterns in your own organisation? The challenge isn’t recognising the problem; it’s understanding how to address it without creating new issues. In the next post, we’ll move from diagnosis to practical frameworks for finding the right balance.
Use the contact form below to see how I can help companies like yours to get back on track.