Middle Management in Tech Consulting: A Veteran Developer's Perspective
· 8m ·
After ten years of traversing the landscape of tech consulting firms, I’ve witnessed the same pattern repeat itself across different companies, countries, and cultures. The names change, but the fundamental issue remains: middle management often stands as a barrier rather than a bridge to effective software development.
What I’ve Seen Across Different Firms
Having worked for over half a dozen major consulting firms, I’ve experienced the full spectrum of middle management – from the exceptionally good to the frustratingly ineffective. The most striking observation? The size of the company often correlates inversely with management effectiveness. As firms grow larger, middle managers tend to become more focused on control than enablement.
The Reality of Daily Developer Life
Let me paint you a picture I’ve lived through multiple times: You’re a senior developer with a decade of experience. Your laptop is struggling with the latest development requirements, but getting an upgrade requires:
- Three levels of management approval
- A detailed justification document
- Multiple follow-up emails
- Weeks or months of waiting
- Countless reminders
Meanwhile, you’re expected to maintain peak productivity with subpar tools. This isn’t a hypothetical – it’s a scenario I’ve encountered at multiple firms, and it’s emblematic of a deeper problem.
The Good, The Bad, and The Bureaucratic
Throughout my career, I’ve noticed three distinct types of middle managers:
The Enablers (Unfortunately Rare)
These managers understand their true role. At one firm, I had a manager who:
- Fought for our right to work remotely before it was common
- Pre-approved equipment upgrades based on team recommendations
- Shielded us from unnecessary meetings
- Trusted our technical decisions
The Passive (Most Common)
These managers simply exist to:
- Forward emails
- Schedule meetings
- Report status updates
- Avoid making waves
The Micromanagers (Too Common)
These actively hinder progress by:
- Requiring daily status reports
- Questioning every technical decision
- Enforcing rigid work hours without reason
- Creating unnecessary processes
What Actually Works: Lessons from the Trenches
The most successful projects I’ve been part of shared one common trait: autonomous teams backed by supportive management. At one firm, we had a manager who:
- Trusted us to manage our own schedules
- Provided equipment without interrogation
- Defended our technical decisions to upper management
- Focused on removing obstacles instead of creating them
The result? We delivered faster, maintained higher quality, and actually enjoyed our work.
The Real Cost of Bad Management
Having jumped between firms, I’ve seen talented developers leave good projects simply because of poor management. The pattern is always the same:
- Excessive control mechanisms are put in place
- Developer autonomy decreases
- Motivation drops
- Top talent leaves
- Project quality suffers
What Middle Managers Should Actually Do
Based on my experience across multiple firms, effective middle managers should:
- Fight Upward, Not Downward
- Challenge unreasonable demands from upper management, both in term of performance, and resource management
- Defend team decisions
- Push for better conditions and tools
- Enable Rather Than Control
- Fast-track resource requests
- Support flexible working arrangements
- Trust team expertise
- Focus on Removal
- Remove bureaucratic obstacles
- Eliminate unnecessary meetings
- Clear path to actual work
A Call for Change
After experiencing both extremes of management styles across different consulting firms, I can confidently say that the traditional command-and-control approach is not just outdated – it’s actively harmful to both companies and developers.
The firms that will thrive in the future are those that understand a simple truth: developers are professionals who need support, not supervision. Middle managers should be enablers of autonomy, not enforcers of control.
To those in middle management positions: your value isn’t in controlling developers – it’s in fighting for them. Every time you trust your team’s judgment, expedite a resource request, or protect them from bureaucratic nonsense, you’re actually doing your job right.
The choice is simple: evolve or watch your best talent leave for companies that understand the value of autonomy. I know – I’ve been part of that exodus more than once.