ℹ️ Note
This is Part 2 of a three-part series on management overhead in software development teams.
Part 1 explored the pattern and its costs. This post examines finding the right balance. Part 3 will cover practical steps for change.
In the first part of this series, we explored how smart organisations end up with manager-heavy software teams and examined the hidden costs of excessive management overhead. We looked at decision paralysis, opportunity costs, technical debt accumulation, and the human impact on retention and morale. We also explored why this pattern emerges: risk aversion, compliance requirements, historical growth patterns, stakeholder inclusion pressures, and discomfort with technical decision-making.
Now we turn to the more constructive question: what does a healthy balance actually look like, and how can organisations achieve it? The answer isn’t simply “have fewer managers”; it’s more nuanced than that, requiring consideration of context, team maturity, and the nature of the work being done.
Understanding Healthy Ratios and Span of Control
Research on organisational design provides useful guidance on healthy manager-to-individual-contributor ratios, though it’s important to emphasise that these are guidelines rather than rigid rules. For engineering teams specifically, studies consistently suggest that engineering managers should typically have between five and ten direct reports, with the sweet spot often around eight to twelve for experienced managers leading skilled teams. This range allows managers to provide meaningful support, mentorship, and guidance whilst maintaining visibility into their team’s work.
However, these numbers need to be understood in context. The McKinsey research on span of control identifies five managerial archetypes, each with different optimal ratios: Player/Coach roles (3-5 reports), where managers handle complex individual work alongside management; Coach roles (6-7 reports), where managers balance individual tasks with team support; Supervisor roles (8-10 reports), overseeing more standardised work; Facilitator roles (11-15 reports), managing highly standardised tasks; and Coordinator roles (15+ reports), primarily focused on coordination rather than active management.
For software development teams, most engineering managers fall somewhere between the Coach and Supervisor archetypes. They need enough time to provide technical guidance, review code, mentor team members, and handle the strategic aspects of their role, but their direct reports are typically skilled professionals capable of considerable autonomy. This naturally suggests a span of control in the 6-10 range, though it can extend higher for particularly experienced managers leading senior teams.
What’s critical to understand is that these ratios represent the manager-to-direct-report relationship. The problem with manager-heavy teams isn’t that individual managers have too many direct reports; it’s that the organisation has too many managers relative to individual contributors. You might have perfect span of control at each level whilst still having an unhealthy overall ratio of managers to ICs across the organisation.
Industry data on software development effort allocation suggests that project management should typically constitute 10-20% of total project effort. For a team of ten people, this suggests roughly 1-2 full-time equivalents dedicated to project management activities. When teams significantly exceed this ratio, it’s worth questioning whether the additional overhead is providing proportional value.
When You Do Need More Management Presence
It’s important to acknowledge that there are legitimate scenarios where teams need more management involvement than these baseline ratios suggest. Understanding these scenarios helps distinguish between necessary oversight and excessive overhead.
Highly regulated industries often require additional oversight and documentation. A pharmaceutical company developing software for clinical trials needs multiple review stages, approval processes, and audit trails. A financial services firm building trading systems needs careful risk management and regulatory compliance. In these contexts, additional project managers, compliance specialists, and quality assurance managers may be genuinely necessary. The key is ensuring this overhead is targeted at the areas where it’s required rather than applied uniformly across all work.
Complex multi-team coordination presents another legitimate case for additional management. When building a large system that requires coordination across ten development teams, three data teams, and five infrastructure teams, you need programme managers, technical programme managers, and delivery managers to keep everything aligned. The coordination challenge is real, and it requires dedicated resources. However, this coordination overhead should be proportional to the actual complexity rather than simply matching the number of teams.
Teams or organisations undergoing significant change may temporarily need more management support. If you’re migrating from a monolithic architecture to microservices, or shifting from waterfall to agile methodologies, or integrating teams after a merger, additional management attention can help navigate the transition. The critical word here is “temporarily”; this additional overhead should decrease as the team stabilises in their new operating model.
Junior or less experienced teams may benefit from narrower spans of control and more management oversight. A team of recent graduates or developers early in their careers needs more active mentorship, guidance, and oversight than a team of senior engineers. As the team matures, the management overhead should decrease accordingly.
Geographic distribution and remote work can increase coordination costs, potentially justifying additional project management support. However, it’s worth noting that many remote-first organisations operate very effectively with lean management structures by investing in good tooling, documentation, and asynchronous communication practices. Geographic distribution is a factor to consider, but it’s not an automatic justification for heavy management structures.
The Role of Fractional and Strategic Leadership
One effective approach to maintaining appropriate management ratios whilst ensuring adequate oversight is the use of fractional or part-time leadership roles. This is particularly relevant for smaller organisations or teams that need senior leadership guidance but don’t require (or cannot justify) a full-time executive.
A fractional CTO, for instance, might work with an organisation 2-4 days per month, providing strategic guidance, mentoring the technical team, reviewing major architectural decisions, and helping with technology planning. This provides the benefits of senior technical leadership without the overhead of a full-time executive. The fractional leader isn’t involved in day-to-day decisions; they’re providing strategic direction and helping the team develop their own decision-making capabilities.
This model works because much of what senior leaders provide isn’t constant supervision but rather periodic guidance, strategic direction, and organisational design. A team doesn’t need their CTO in every meeting; they need the CTO to set the right direction, put the right structures in place, and be available when significant decisions arise. This can often be accomplished more cost-effectively through fractional engagement than through hiring a full-time executive who then feels pressure to justify their existence through high meeting attendance.
Similarly, fractional or consultant project managers, delivery managers, or technical programme managers can provide oversight and coordination for specific initiatives without becoming permanent overhead. This allows organisations to scale their management capacity up during complex projects and scale it back down when the need passes.
Empowering Technical Decision-Making
Perhaps the most important element of finding the right balance is genuinely empowering technical teams to make decisions within appropriate boundaries. This requires a fundamental shift in thinking for many organisations: moving from “managers make decisions that developers implement” to “developers make decisions within a framework that managers define.”
This starts with clarity about decision rights. What decisions can developers make autonomously? What decisions need technical lead approval? What decisions require managerial sign-off? What decisions need stakeholder consensus? Many organisations lack this clarity, defaulting to escalating everything to managers because there’s no defined alternative. Establishing clear decision-making frameworks reduces uncertainty, speeds up delivery, and reduces the meeting overhead associated with constant escalation.
It also requires investing in developers’ business acumen and strategic thinking. If organisations want developers to make good decisions independently, they need to ensure developers understand the business context, strategic priorities, and constraints within which they’re operating. This is more effective than having managers translate every decision, and it develops developers’ capabilities in ways that benefit their careers and the organisation’s long-term capability.
Technical leads and principal engineers play a crucial role in this model. These are individual contributors with deep technical expertise and business understanding who can provide technical leadership without adding management layers. They can review architectural decisions, mentor less experienced developers, and serve as technical decision-makers for their areas. Organisations that invest in strong technical leadership tracks often find they need fewer people managers because the technical leadership structure handles much of what managers would otherwise need to do.
Finally, this requires managers to embrace a different role: setting context and direction rather than overseeing individual decisions. Good managers in technical organisations define the guardrails within which their teams operate, provide context about business priorities and constraints, remove blockers that prevent the team from working effectively, and intervene when decisions fall outside appropriate boundaries. They don’t need to approve every technical decision; they need to ensure the team has what they need to make good decisions themselves.
A Framework for Self-Assessment
Understanding the problem and the principles of good team structure is one thing; applying that understanding to your specific situation is another. Here’s a practical framework for assessing whether your organisation’s management structure is helping or hindering your software delivery capability.
The Meeting Audit
Start by conducting a meeting audit across your technical teams. For a typical week, track: how many meetings each developer attends; what percentage of their time is spent in meetings versus focused technical work; who attends each meeting and what their role is; how many meetings result in actual decisions versus simply providing status updates or maintaining visibility; and how long it takes on average to make technical decisions that should be straightforward.
Healthy engineering teams typically have developers spending no more than 20-30% of their time in meetings, with senior developers and technical leads potentially spending more due to their coordination and mentorship responsibilities. If your developers are spending 50% or more of their time in meetings, something is wrong. If your technical discussions routinely include six or more participants, question whether everyone needs to be there. If straightforward technical decisions are taking days or weeks to make, examine your decision-making process.
Pay particular attention to the ratio of managers to individual contributors in your technical meetings. If you regularly have meetings where managers outnumber developers, or where the participant list includes multiple layers of management for a single technical discussion, you’ve identified a clear symptom of excessive management overhead.
The Decision Velocity Assessment
Examine how long it takes your team to make and implement decisions across different categories: routine technical decisions (which library to use, how to structure a component); significant architectural decisions (choosing between different system designs); feature prioritisation decisions; and process or methodology changes. Track not just the time from question to decision, but also how many people need to be involved, how many meetings are required, and how much documentation or justification is needed.
Compare this against reasonable benchmarks. Routine technical decisions should typically be made within hours or at most a day or two, often by individual developers or through quick discussion with a technical lead. Significant architectural decisions might take a week or two, involving thoughtful analysis and discussion amongst the technical team with input from relevant stakeholders. Feature prioritisation should happen continuously as part of your product management process, not requiring extensive meetings for each decision.
If your decision-making timelines significantly exceed these benchmarks, it’s worth examining why. Is it because decisions need to pass through multiple approval layers? Is it because the right decision-makers aren’t clear? Is it because gathering input from all stakeholders takes considerable coordination? Each of these points to different potential issues with your organisational structure.
The Organisational Span Analysis
Calculate the actual span of control for your managers across different levels of your organisation. This includes both direct span (how many people directly report to each manager) and organisational span (looking at the overall ratio of managers to individual contributors). Plot this data across your organisation to identify patterns.
Look for anomalies and patterns. Are there managers with only one or two direct reports? This suggests potentially unnecessary management layers. Are there departments where the manager-to-individual-contributor ratio is significantly different from others? This might indicate either a problem or a legitimate difference in needs. Do you have multiple management layers where a single layer might suffice?
Industry benchmarks suggest that engineering managers should typically have 5-10 direct reports, though this can vary based on context. If you have managers consistently below this range, it suggests your organisational structure might be too hierarchical. If you have managers consistently above 15 direct reports, they may be stretched too thin to provide effective leadership.
The Overhead Cost Analysis
Conduct a financial analysis of your management overhead. Calculate what percentage of your engineering budget goes to individual contributors versus various management roles. Include not just salaries but also the opportunity cost of their time spent in meetings and coordination activities.
Whilst exact benchmarks vary by industry and context, research suggests that project management should typically constitute 10-20% of total project effort. If your management and coordination overhead significantly exceeds this, question whether you’re getting proportional value. A team spending 40-50% of its budget on management and coordination activities should be delivering exceptional outcomes to justify that investment.
Also examine the trend over time. Is your management overhead increasing as a percentage of total headcount? If you’ve grown from 20 to 100 engineers, has your management overhead grown proportionally, or has it grown faster than your individual contributor headcount? If management overhead is growing faster than individual contributor headcount, your organisational structure is becoming more management-heavy over time, which likely indicates a structural issue rather than a conscious strategic choice.
The Team Health Check
Perhaps most importantly, assess the health and satisfaction of your technical teams. Conduct anonymous surveys asking developers about: their ability to make technical decisions autonomously; whether they feel they have adequate support from management without being micromanaged; their satisfaction with meeting load and ability to focus on technical work; their sense of making progress and delivering value; and their overall engagement and intention to remain with the organisation.
Poor scores on these dimensions, particularly when combined with high management overhead, strongly suggest that your organisational structure is impeding rather than enabling your technical teams. Developers who feel micromanaged, meeting-heavy, and unable to make progress are unlikely to do their best work, regardless of how many managers are trying to support them.
Also examine retention and recruitment metrics. Are you losing developers at a higher rate than industry norms? When developers leave, what reasons do they cite in exit interviews? How easy is it to recruit strong technical talent, and what concerns do candidates raise during the interview process? These external signals often provide valuable insight into how your organisational structure is perceived.
Red Flags Versus Legitimate Reasons
As you conduct this assessment, distinguish between red flags that indicate problematic overhead and legitimate reasons for management presence. Red flags include: meetings where managers significantly outnumber individual contributors; routine technical decisions requiring multiple layers of approval; developers spending more than 40% of their time in meetings; management layers with very narrow spans of control; increasing management overhead as a percentage of total headcount over time; and high developer turnover with exit feedback citing excessive meetings or bureaucracy.
Legitimate reasons for higher management involvement include: complex regulatory or compliance requirements; genuine multi-team coordination challenges; organisational change or transition periods; deliberately mentoring junior teams; and genuinely distributed teams requiring active coordination.
The distinction often comes down to whether the management presence is actively enabling work or primarily providing oversight and visibility. If removing a manager or reducing meeting frequency would create genuine gaps in capability or coordination, that’s a sign the management presence is justified. If removing a manager would simply mean fewer meetings with no loss in actual capability, that’s a sign of excessive overhead.
Coming up in Part 3: We’ll explore practical steps for addressing excessive management overhead, including how to build awareness across leadership, restructure for autonomy, and implement changes that improve delivery capability without creating new problems.
💭 If your assessment reveals management-heavy patterns in your organisation, don’t despair. Change is possible, but it requires careful thought, honest conversation, and willingness to restructure in ways that might feel uncomfortable. In the next post, we’ll provide a practical roadmap for making these changes effectively.
Use the contact form below to see how I can help companies like yours to get back on track.