In Defence of Middle Management (Sort Of)

My take on the value middle management brings to a business and the individuals

So I was recently asked by one of my readers to provide a response about middle management. In summary, the paraphrased ask was as follows:

Can you defend middle management to someone who finds most of it pointless and the language around it unbearable, in a way that actually lands with someone from the working class?

As a middle manager myself, I thought it would be good to provide a no holds barred take on what value I believe my role brings to the table, but also areas where it might actually lack some value.

---

I’ve seen the memes. I’ve sat in the meetings that should have been emails. I’ve rolled my eyes at leadership content that feels like it’s been pulled straight from a management thesaurus (some of which I’ve written myself…cringe).

And I’ve heard the grumbles - the ones that say middle management is bloated, unnecessary, and full of people who don’t do much except pass messages up and down the chain, add a few acronyms, and call it leadership.

And to be fair… sometimes that’s bang on.

But here’s where I want to try and bridge the gap a bit. Not with waffle. Not with buzzwords. Just a bit of straight talk from someone who’s been on both sides.

First off: most management content is, frankly, crap

A lot of it is pretentious. The language is often written for other managers, not for the people doing the actual graft. I’ve read posts that say a lot without saying much at all. So when someone outside of management calls it all fluff? I don’t disagree.

You might often hear terms being thrown around like “servant leadership”, “change management”, or “psychological safety” to name a few. These generally find themselves being wrapped up into some subjectively inspirational quote such as:

Change management doesn’t have to be hard. Become a servant leader to your team, creating an environment of psychological safety and watch your team blossom like a grove of cherry blossom trees at the base of Mount Fuji.

- Michael Banner, April 2025

But there’s a difference between bad management and good management. And it’s the latter that often goes unseen because - well, it’s not flashy. Good management is quiet. It’s boring. It’s invisible. But it changes the way people feel at work.

I like to write about management as it’s my job. I enjoy management and leadership, so much so that I often read about various approaches, experiences and case studies that I’ve come across. I’m not claiming my content is perfect, but I enjoy providing my own perspectives on the various challenges you may face in a management role, or if you’re an engineer reading it, gain some insight into what managers do.

This leads me well into the next section…

So what’s the actual point of middle management?

Let’s just get to the point: the real job of middle management should be to make life easier for the people doing the work. Not harder.

A good manager:

• Shields their team from the political nonsense higher up.

• Gets the resources you need to do your job properly.

• Makes sure you’re paid fairly and recognised for your work.

• Clears roadblocks instead of creating them.

• Has your back when things go sideways.

• Knows when to hold back.

• Knows when to wade in.

That’s pretty much it in a nutshell. As you can see, it’s not empire building. It’s not passing the buck. It’s not throwing around phrases like “synergising core deliverables” while doing bugger all.

Done well, middle management is about translating strategy into reality. It's the layer that can say: “Here's what the company thinks it wants. Let me turn that into something that makes sense for you (as an engineer/team), and make sure you’re not buried under the weight of it.”

Sure, engineers (individual contributors) could get involved in the realms of middle-management-y meetings, embroiling themselves in arguments over priorities, nonsensical tracking metrics, justifying why a team appears to be going slower than expected etc, but why would they?

When I was an IC engineer myself, I didn’t want to spend hours in meetings, more meetings about meetings and then a meeting to reflect on the meetings we had. I wanted to be solving problems, either through writing code or exploring alternative options like viable off-the-shelf solutions. I didn’t want to concern myself with the high-level goals that Janet in accounts had for the financial aspirations of the company - I just wanted/needed to know what that meant for the work I was on. How could I use my skills and knowledge to help take the business and/or product in the right direction, have some clear feedback on how my contributions hold up and feel supported as I do it.

As a manager, I’ve tried my best to find that balance of shielding my teams from things that simply don’t matter. In some companies I’ve acted as a conduit of information, deciding to gate-keep a tonne of unnecessary communication that would have otherwise swamped my engineers. This has given them the space and time to get on with what they would call focused work. I’ve also acted as a listener, understanding the struggles that a team is facing and using my connections to help drive improvements - whether that be access to new tools, changes in how we interface with other teams, identifying knowledge gaps and organising training budgets etc. Again, engineers could do all of the above things themselves, but it would only take away from the little time they find themselves with to do their actual skilled part of the role - the technical delivery of things.

What management isn’t

In my opinion management isn’t, and shouldn’t just be another individual contributor who dabbles in a bit of 1-1 sessions on the side. This just creates a blurred lined in that individual’s ability to focus on something and do it well. Obviously this is very context-dependent, as some companies simply don’t have the budget to split the wearing of hats between several employees. Startups are a great example where you might be an engineer, a tech lead, a line manager, an architect, the CTO and the CEO all rolled into one. Context is key.

Although I do come from a background of software engineering, I don’t think my time is best used in a coding capacity. Sure, I’ve rolled my sleeves up occasionally to help the team out and keep my ear to the ground, but that’s not where my true value is at.

This is where often there is a fork in the road along the career path:

1. Technically focused

2. People/process focused

The left side of the fork (technical) is looking more at roles which remain hands-on, albeit with a slightly increased scope of attention (e.g. standards and practices across a department). This would include roles like principal engineer, staff engineer, distinguished engineer etc.

Whereas the people/process focused roles tend to look more at growing the individuals and the ways of working.

“But couldn’t AI just do that now?”

It’s a great question.

Honestly? AI will replace a lot of what bad managers do. It will even replace a lot of what bad engineers do (or don’t do, rather).

If your manager is just scheduling meetings, writing project plans, or paraphrasing other people’s emails, then yeah - they’re toast. And they probably should be. You don’t need a person for that anymore.

But here’s what AI can’t do (yet):

• Spot when someone’s not okay and pull them aside for a quiet chat.

• Navigate the politics of a messy re-org while keeping their team safe.

• Earn trust slowly, over months and years, by showing up consistently.

• Defuse a heated meeting before it spirals.

• Notice who’s quietly carrying the load and advocate for their promotion.

This isn’t touchy-feely nonsense. It’s the stuff that actually keeps teams together. And when it’s missing? Morale drops, people quit, and the good engineers go elsewhere.

One could argue that AI could even replace the need for such meetings, acting as some kind of co-pilot (oh wait, that’s probably trademarked) to assist with decision making and act as a secondary brain. Why this might be true, I do see the need for certain meetings to happen with real people who hold more context than AI ever could (without some massively substantial prompts to set the greater context).

The other aspect here is that not everybody is cut out for managing people. It simply isn’t the same as being a techie - people aren’t code and consequently they often come with a hugely-dynamic array of challenges. Yes, coding is often challenging but then we have documentation we can read, or in the case of AI, documentation we can talk to. When it comes to people, knowing how to handle a grieving employee who just lost their mother, or helping someone break down their thought process to identify career goals just hits differently. IDEs might throw a few errors back at you, but a person can be a lot more volatile with their mood and it’s hard - I won’t lie to you.

Could working-class leaders replace the lot?

I’d love to see more working-class folks in leadership. People who’ve done the job, know what good looks like, and won’t talk crap just to sound clever.

In fact, I think a lot of management would improve overnight if more people with proper hands-on experience stepped into those roles - especially if they kept their no-nonsense, people-first mindset. Chuck in a bit of AI know-how and you’ve got a modern, efficient, emotionally intelligent leader who doesn’t waste anyone’s time.

To go against the no-jargon idea of this post, I briefly want to mention The Peter Principle again due to its relevance to the topic. Some individuals make their way into management positions as a way of “promotion”. In other words, you were an excellent engineer so congratulations you’re now an engineering manager. Like I mentioned earlier in the post, code and technical systems are not synonymous with the dynamics of people, fact. If you get promoted into a management role with no kind of training, or least a degree of natural empathy and ability to listen and respond with some common sense, you’re likely setting yourself up for failure. With the right support, people can go from being hands-on into a management role and use their existing skills to empathise and understand where their team(s) are coming from. This definitely helps, but I don’t think it’s a strict necessity in all cases.

I have worked with other middle managers who have made their way into the role without having hands-on experience as a software engineer. They have worked in tech as testers, but not in terms of writing the code itself. In this circumstances the standout value I’ve seen from these individuals is their ability to “know enough”. They know enough to hold meaningful conversations. They know enough to challenge ideas. They know enough to make decisions. They know enough to identify when support is or isn’t needed. A lot of their value comes from the things mentioned under ‘So what’s the actual point of middle management?’, and less so about their raw technical abilities.

Final thoughts

If you’re tired of the buzzwords, you’re not alone. Even as a manager I am too. But don’t let the nonsense distract you from the value that good leadership can bring.

We don’t need more managers. We need better ones. Ones who speak like humans, not consultants. And ones who realise that their role exists to make other people shine, not to stand in their light.

That’s the kind of management I believe in.

I don’t even know if I’ve answered the question well enough, and there are certainly other things I could talk and write about for hours. There may be more to come on this topic as it’s certainly not a small one, but I’d be keen to hear your views.