ℹ️ Note
This is Part 3 of a three-part series on management overhead in software development teams
Part 1explored the pattern and its costs. Part 2 examined finding the right balance. This post covers practical steps for change.
In the first two parts of this series, we explored how organisations end up with manager-heavy software teams, examined the costs of excessive management overhead, and provided a framework for assessing your organisation’s current state. We looked at what healthy team structures look like, when you genuinely need more management presence, and how to distinguish between necessary oversight and problematic overhead.
Now we turn to the most practical question: if your assessment reveals that your organisation has fallen into the manager-heavy pattern, what can you do about it? Change is challenging, particularly when it involves restructuring teams and potentially reducing management layers, but it’s not impossible. Here are practical steps for addressing excessive management overhead whilst maintaining (or even improving) organisational effectiveness.
Start with Awareness and Conversation
The first step is building awareness of the issue across leadership. Present your assessment findings in a way that focuses on outcomes rather than blame. Frame the conversation around delivery capability, team satisfaction, and organisational effectiveness rather than criticising individuals or past decisions. The goal is to create shared understanding that the current structure isn’t serving the organisation well, not to assign fault.
This conversation needs to include senior leadership, middle management, and representative voices from your technical teams. Each group brings different perspectives: senior leaders care about overall organisational effectiveness and cost; middle managers are often acutely aware of coordination challenges but may also feel defensive about their roles; developers can articulate how the current structure affects their day-to-day work.
Use data to support your case. Show the meeting audit results. Present the decision velocity analysis. Share the team health survey findings. Quantify the financial impact. Make the abstract concrete by showing specific examples of how excessive overhead has delayed decisions or impeded delivery. Data won’t solve everything, but it makes the conversation more objective and harder to dismiss.
ℹ️ Note
We covered how to gather these data points in part two of this series.
It’s crucial to acknowledge the good intentions behind the current structure. Most management layers were added for valid reasons at the time, and most managers are genuinely trying to help their teams succeed. The conversation isn’t about whether people are competent or well-meaning; it’s about whether the structure they’re operating within is serving the organisation’s goals. This distinction helps people engage constructively rather than defensively.
Be prepared for resistance and discomfort. Organisational change is difficult, and conversations about reducing management layers can feel threatening to the people currently in those roles. Some managers will worry about their jobs. Some will question whether the data truly reflects the situation. Some will argue that their specific context requires the current level of oversight. These are natural responses, and they need to be heard and addressed thoughtfully rather than dismissed.
The goal of this initial phase isn’t to immediately implement changes; it’s to build sufficient shared understanding and commitment to change that you can move forward together. This might take several conversations, presentations to different stakeholder groups, and iterations on the data and analysis. Invest the time required to build genuine buy-in rather than trying to force change through without it.
Define Clear Decision Rights and Escalation Paths
One of the most effective changes organisations can make is establishing clear decision-making frameworks. Document what types of decisions can be made at what levels: what developers can decide autonomously, what requires technical lead input, what needs engineering manager approval, and what requires broader stakeholder involvement.
This isn’t about creating more bureaucracy; it’s about creating clarity that reduces bureaucracy. When everyone understands what decisions they can make independently, you eliminate the constant escalation that creates meeting overhead. When escalation paths are clear, decisions that do need broader input can be handled efficiently rather than through ad-hoc meeting scheduling.
Start by categorising the types of decisions your teams make regularly. For technical decisions, this might include: routine implementation choices (which library to use, how to structure a component); significant architectural decisions (choosing between different system designs); technology stack choices (adopting a new framework or language); security and compliance decisions; and decisions with cross-team implications. For each category, define who has the authority to make that decision and what process should be followed.
The framework should be specific enough to be useful but flexible enough to handle the variations that inevitably arise. For example, you might specify that developers can autonomously choose libraries that are already in use within the organisation and align with established architectural patterns, but introducing a new library requires technical lead approval, whilst adopting an entirely new technology stack requires architecture review and engineering manager approval.
Document the escalation paths clearly. If a developer is unsure whether they have authority to make a particular decision, who should they ask? If a technical lead approves a decision that later proves problematic, what’s the process for addressing it? If there’s disagreement about whether a decision fits within the defined boundaries, how is that resolved?
These frameworks should be living documents, reviewed and adjusted based on experience. If you find certain types of decisions are consistently being escalated unnecessarily, adjust the framework to clarify that they can be handled at a lower level. If certain decisions made autonomously are creating problems, adjust to add appropriate oversight. The goal is finding the right balance for your organisation’s specific context.
Importantly, these frameworks need to be communicated clearly and reinforced consistently. It’s not enough to document decision rights; managers need to actively support developers making decisions within their authority, even when they might have made different choices. If managers override or question decisions that fall within developers’ authority, the framework becomes meaningless and the organisation reverts to escalation by default.
Restructure for Autonomy
Consider restructuring teams to maximise autonomy and minimise coordination overhead. This might mean creating clearer boundaries between team responsibilities, ensuring each team has the full range of skills needed to deliver independently, or reducing dependencies that require constant coordination across team boundaries.
The goal is enabling teams to operate with minimal external coordination for most of their work. This doesn’t mean teams never interact or coordinate; it means the default mode is independent operation, with coordination happening at defined integration points rather than requiring constant management oversight.
One effective approach is organising teams around value streams or product areas rather than around technical functions. Instead of having separate frontend, backend, and database teams that need to coordinate on every feature, create cross-functional teams that own specific product areas or user journeys end-to-end. This reduces the coordination overhead because most dependencies are within the team rather than across team boundaries.
Another approach is clarifying ownership and reducing shared responsibilities. When multiple teams share ownership of a component or system, coordination overhead increases because changes require agreement across teams. Where possible, assign clear ownership to specific teams, allowing them to make decisions about their areas without constant coordination. This doesn’t mean teams can’t collaborate or that boundaries are rigid, but it does mean there’s a clear default decision-maker for each area.
This often involves difficult conversations about span of control and management layers. You may need to collapse management layers, expand individual managers’ spans of control, or transition some managers into individual contributor roles. These conversations are sensitive and require care, but they’re often necessary to right-size an organisation that’s become too management-heavy.
When restructuring, be thoughtful about the transition. Don’t simply eliminate roles and expect the organisation to adapt; think carefully about what valuable functions those roles were performing and ensure those functions are handled in the new structure. If a delivery manager was tracking dependencies and coordinating releases, who will do that after the restructuring? If a project manager was removing blockers and facilitating communication, how will that happen going forward?
Consider whether some management roles might be better served as senior individual contributor roles. A programme manager who spends most of their time on technical coordination might be more effective as a principal engineer or technical programme manager. A delivery manager who primarily focuses on process improvement might transition to a senior developer role with specific responsibility for team effectiveness. These transitions preserve valuable expertise whilst reducing management layers.
Be prepared for this phase to take time. Organisational restructuring is complex and can be disruptive if handled poorly. It’s better to move thoughtfully, testing changes with pilot teams and learning from the experience, than to implement sweeping changes that create new problems.
Invest in Technical Leadership
Strengthen your technical leadership track as an alternative to creating more management layers. Invest in principal engineers, technical architects, and senior individual contributors who can provide technical leadership, mentorship, and decision-making without adding management overhead.
This requires conscious effort and organisational design. Many organisations default to creating management roles when they want to provide career progression or recognition for senior people. Creating strong individual contributor tracks that offer equivalent prestige, compensation, and influence to management tracks provides alternatives that can actually serve the organisation better in many cases.
Define clear expectations and responsibilities for technical leadership roles. What does a principal engineer do that a senior engineer doesn’t? What authority do they have? What decisions do they make? How do they interact with engineering managers? Without this clarity, organisations often create senior individual contributor roles that are titles without real authority or responsibility, which satisfies no one.
Technical leaders should have explicit authority and responsibility for technical decisions in their domains. A principal engineer or architect should be able to make architectural decisions, establish technical standards, and guide technical direction without needing managerial approval for every choice. They should be empowered to mentor other developers, review designs and code, and serve as technical decision-makers.
This doesn’t mean technical leaders operate in isolation from management. Engineering managers and technical leaders should work together, with managers providing business context and strategic direction whilst technical leaders make the detailed technical decisions. But the relationship should be collaborative rather than hierarchical; technical leaders aren’t subordinate to managers in their technical decision-making.
Invest in developing technical leaders’ skills in communication, stakeholder management, and strategic thinking. Being an excellent developer doesn’t automatically make someone effective at leading technical initiatives, influencing across teams, or communicating with non-technical stakeholders. Provide training, mentoring, and support to help technical leaders grow these capabilities.
Recognise and reward technical leadership explicitly. This includes compensation parity with management tracks, but also public recognition, inclusion in strategic discussions, and opportunities to shape the organisation’s technical direction. If the organisation’s actions suggest that management is the only path to influence and recognition, talented people will pursue management roles even when they’d be more effective as technical leaders.
Consider creating specific technical leadership roles focused on organisational effectiveness rather than just technical expertise. A “developer experience engineer” or “platform productivity engineer” might focus on improving tooling, processes, and infrastructure to make the entire engineering organisation more effective. These roles provide technical leadership without adding management layers.
Consider Fractional Leadership Support
For smaller organisations or specific situations, consider bringing in fractional leadership rather than hiring full-time management roles. A fractional CTO working 2-4 days per month can provide strategic guidance, mentorship, and decision-making support without the overhead of a full-time executive presence in every meeting.
This approach works particularly well for organisations in transition: growing from startup to scale-up, recovering from technical debt, preparing for significant technical change, or building out capabilities in new areas. The fractional leader provides expertise and perspective without permanently increasing your management overhead.
The key to effective fractional leadership is clarity about scope and engagement model. The fractional leader should be involved in strategic decisions, provide guidance and mentorship, and be available for escalation, but they shouldn’t be involved in day-to-day execution decisions. This creates the right balance of strategic oversight without operational micromanagement.
Define specific objectives for the fractional engagement. What outcomes are you trying to achieve? What gaps are you trying to fill? How will you measure success? This clarity ensures the engagement is focused and productive rather than becoming an undefined advisory relationship that doesn’t drive specific improvements.
Ensure the fractional leader has sufficient context to be effective. They need to understand your business, your technology landscape, your team’s capabilities, and your strategic objectives. This requires investment in onboarding and ongoing communication, but it’s essential for making the relationship valuable.
Consider using fractional engagement as a way to access expertise you need intermittently rather than full-time. A fractional security specialist might review your security practices quarterly. A fractional data architect might guide your data strategy without being involved in every data pipeline decision. This allows you to access specialised expertise without creating permanent overhead.
Be clear with your existing team about the fractional leader’s role and authority. Confusion about who makes what decisions can undermine both the fractional leader and your existing management. The fractional leader should complement your team’s capabilities, not create ambiguity or conflict.
Measure Progress and Iterate
Finally, treat this as an iterative improvement process rather than a one-time fix. Establish metrics for monitoring your progress: meeting time as a percentage of developer time; decision velocity for different categories of decisions; team health and satisfaction scores; and manager-to individual contributor ratios across the organisation.
Review these metrics regularly and adjust your approach based on what you learn. If reducing management layers creates gaps in capability or coordination, address those gaps thoughtfully rather than simply reverting to the previous structure. If certain teams struggle with increased autonomy, provide them with additional support and development rather than adding back management overhead.
Create regular checkpoints to assess how the changes are working. This might be monthly reviews of key metrics, quarterly team health surveys, or periodic retrospectives with different stakeholder groups. The goal is creating feedback loops that allow you to detect problems early and make adjustments before they become serious issues.
Be transparent about what you’re learning and how you’re adjusting. If something isn’t working, acknowledge it and explain what you’re doing differently. This builds trust and reinforces that you’re approaching this as a learning process rather than implementing a fixed plan regardless of outcomes.
Celebrate successes and share positive examples. When teams successfully make decisions autonomously that previously would have required multiple meetings and management approvals, highlight those examples. When decision velocity improves, quantify it and share the impact. When developer satisfaction increases, communicate it broadly. This reinforces the benefits of the changes and builds momentum for further improvement.
Be patient with the timeline for change. Organisational restructuring doesn’t produce immediate results, and some metrics may temporarily worsen during transitions as people adapt to new structures and ways of working. Look for trends over quarters rather than expecting immediate improvement.
Create mechanisms for ongoing input from your teams. Regular retrospectives, anonymous feedback channels, and open forums for discussing what’s working and what isn’t help you stay connected to how the changes are affecting people’s day-to-day work. The people doing the work often have the best insights into what needs to be adjusted.
Don’t stop iterating once you’ve achieved better ratios. Organisational needs change over time. As you grow, launch new products, enter new markets, or face new challenges, your optimal structure may shift. Continue to monitor your metrics, assess your effectiveness, and make adjustments as needed. The goal isn’t finding a perfect static structure; it’s building the organisational capability to continuously adjust your structure to serve your needs effectively.
Conclusion
The pattern of manager-heavy software teams isn’t a failure of the individuals involved; it’s a systemic outcome of reasonable responses to organisational pressures. Risk aversion, compliance requirements, historical growth patterns, stakeholder inclusion, and discomfort with technical decision-making all contribute to creating structures where management overhead grows beyond what’s healthy or effective.
The costs of this pattern are significant and extend far beyond the immediate financial impact. Decision paralysis, coordination overhead, technical debt, and developer retention challenges all stem from excessive management presence. These costs compound over time, creating organisations that feel busy and involved but struggle to actually deliver software effectively.
But whilst the problem is common, it’s not inevitable. Organisations can find healthier balances between management oversight and technical autonomy by understanding appropriate span of control ratios, distinguishing between necessary oversight and excessive overhead, empowering technical decision-making within clear frameworks, and investing in technical leadership as an alternative to management layers.
The key is recognising that management presence should enable work rather than simply oversee it. When managers are genuinely removing blockers, providing context and direction, and making their teams more effective, they’re adding value regardless of ratio considerations. When managers are primarily providing visibility, attending meetings to stay informed, or overseeing decisions that don’t require oversight, they’re creating overhead that impedes rather than enables.
Change is challenging, particularly when it involves restructuring teams and potentially reducing management layers. It requires building awareness across leadership, having honest conversations about what’s working and what isn’t, establishing clear decision-making frameworks, restructuring for team autonomy, investing in technical leadership, and treating the whole process as iterative learning rather than one-time transformation.
But organisations that successfully address excessive management overhead often find their delivery capability improves dramatically. Teams move faster, make better decisions, deliver higher quality work, and experience better morale and retention. The coordination overhead that consumed so much energy diminishes, allowing people to focus on actually building valuable software rather than managing the process of building it.
The restaurant with fifteen waiters and one cook isn’t doomed to fail; it just needs to recognise the inefficiency of its current structure and make deliberate changes to find a healthier balance. The same is true for software organisations. With awareness, intention, and willingness to change, you can move from a structure that impedes delivery to one that genuinely enables your technical teams to do their best work.
ℹ️ Note
If you’ve worked through this series and recognised your organisation in these patterns, remember: this is a common challenge, not a unique failure. Many smart, well-intentioned organisations have ended up with excessive management overhead. The question isn’t whether you’ve made mistakes in the past; it’s what you’re going to do differently moving forward.
🧑💻 Prompt
Take the time to assess your current state honestly, using the framework provided in Part 2. Build awareness across your leadership team about the patterns you’re seeing and their impact. Start the conversations about what needs to change, approaching them with empathy for people’s concerns and clarity about organisational needs.
ℹ️ Warning
Don’t expect change to happen overnight. Organisational restructuring takes time, and you’ll make mistakes along the way. That’s normal and healthy; treat it as learning rather than failure. Focus on continuous improvement rather than perfection, and be willing to adjust your approach as you learn what works for your specific context.
And if you’d like experienced support for this journey, that’s precisely what fractional CTO services are designed to provide: strategic guidance, organisational design expertise, and support for transformation without adding permanent management overhead. Sometimes the right leader for addressing management overhead is one who isn’t adding to it themselves.
The path from manager-heavy to appropriately structured isn’t always comfortable, but it’s navigable. And on the other side is an organisation that delivers better software, more quickly, with higher quality and more satisfied teams. That’s worth the effort.
Use the contact form below to see how I can help companies like yours to get back on track.