The Curse of the Technical Middle Manager
Why you should push back when senior managers spend time coding*
Technical people tend to favour having technical managers.
Heck, they adore them❤️
What creates instant connection, credibility, and legitimacy faster than talking about niche stuff together? When your manager is fluent in [programming language] and/or practicing [scientific field], it makes it easier for you to bond. Let’s look at why these three aspects matter.
First, connection. It makes them approachable. Your manager is likely to be your senior both in age and experience. Add in power dynamics favouring them, it is easy to put them on a pedestal. When you can both laugh about how Python is so slow compared to [everything else] and one of you had to buy a spare laptop because they couldn’t exit Vim—that’s a link. See, they have earthly problems too.
Second, credibility. It greatly boosts the believability factor of a manager. When you have a new manager, barring prior acquaintance, you have little reason to trust them. Them dropping an insightful comment re: the inner workings of a programming language or bringing up edge cases & gotchas that did not occur to you transforms them from someone who can fire you to a fellow enthusiast who can fire you.
Third, legitimacy. Legitimacy is related to credibility, but differs in meaning in a significant way. Credibility is about being trusted. Legitimacy is about conforming to rules, norms, logic, and expectations. All managers have some degree of legitimacy by design—your skip-level manager hired them to manage you; it’s literally their job.
However, as you probably have experienced it yourself soon after your birth, on-paper legitimacy doesn’t always translate to real life—gestures broadly at parents. At work however, technical aptitude can help a lot. If you are a data middle manager reporting to the CFO/COO, reporting to the CTO might open up dialogue options—just like in a video game—that were previously unavailable to you.
Even with a CTO, you run the same risk if you are not a SWE—e.g. if you are data science/engineering manager reporting to a software engineer CTO, you will find that they will (IMO subconsciously) try to extend their legitimacy to your domain:
SWE and DS are the same thing, right?
CTO: I was fooling around in AWS last night, can we…
CTO: Can you just ship incremental work like the engineering teams? You: staring at the SOTA LLM of the day and having MLOps nightmares
Related—CTO: But why can’t we iterate faster? You: staring at a 10GB Docker image
Opportunity Costs of Technical Middle Managers
It sounds like there are a lot of upsides to having technical middle management. What’s the catch?
You may not have an issue if your manager only talks about technical stuff. Think of lunch chats or posts on internal Slack channels on the latest patch, a big release, this model, that benchmark…That’s harmless, and makes everyone feel good and nerdy.
The problem arises when they do spend significant time writing code.
Unless they are:
In a very small startup, so titles don’t matter anyway and everyone does everything, all the time
An unrivalled genius—I’m talking about true outlier status—whose work cannot be replicated by others in the company
they should not spend time coding. Like house prices in London, the opportunity costs are damn too high.
A good technical IC can, amongst other things,
Write good code.
A good middle manager in charge of a technical department can
Locate and identify executive sponsorship
Manage other high-level stakeholders and get buy-in
Align the technical function with overarching business goals
Build bridges with other functions (Product, Design, UXR; RevOps, Sales, Marketing…)
Be a 💩 umbrella and shelter their function from exec noise
Establish and execute vision, strategy, roadmaps
Oversee change management and cultural shifts
Construct career growth frameworks
Translate strategy to tactics
Line manage team leads
…
I guess at some point they can write good code too, but is it worth the trade-off? Good ICs, however senior, simply cannot perform the majority of tasks asked of a middle manager. This is a bit of a tautology, as good senior ICs stay ICs for this very reason—they don’t want middle manager responsibilities.
Continuing the theme of tautologies, someone has to do it, and that’s the middle manager. The point is, once you accept a middle manager posting, you must commit to it not because it is
thankless
transient
a necessary evil
pays well I suppose
but because it is goddamn important. You cannot afford to role-play as a senior IC when you have such responsibilities. Neglecting your primary responsibilities will hurt your function and teams disproportionally compared to the satisfaction you receive by doing things yourself: OK, you will get to write code, but at the cost of:
Your function not being adequately represented at the highest levels
Your function lacking allies b/c you haven’t had time to build bridges
Your people are unhappy b/c other functions got to dictate the overall strategy
Your people are unhappy b/c you are not stopping the interference from execs
If you have a middle manager boss who is too keen on churning out code, raise this as an issue ASAP. It’s tricky of course, telling your boss what not to do. There are several options available to you, in ascending order of audacity:
Identify the root cause—why does your manager feel the need to make PRs? Is it because no one in the team can do the tasks? Or is it because they still think they are ICs?
If former, it is time for self-reflection. Convene with your teams members and raise it with your manager that you want them to chart you a career growth plan that will take you from now to the near-future where they don’t write code. Then commit to the process and strive to improve.
If latter, good news for you (bad news for them).
Raise it in a team meeting that you have seen your manager pushing code, ask if they can delegate them instead.
If your manager try to plays it down or doesn’t keep their word (i.e. they say they’ll delegate but keep coding),
Given your manager’s primary responsibilities (locate their job ad if possible, otherwise use common sense), are you/your team suffering from any negligence on part of them not fulfilling any?
Collect evidence, anecdotes; note the ‘vibe’ of the team
Communicate the above in a 1:1 meeting with your manager
Raise it again in a team meeting why they are still writing code after they said they won’t. At this point, you can raise the matter in ‘public’; especially if you have been having chats with your team members
Make your skip-level manager the only person who can approve your manager’s PRs 🙃
Managing up is never really fun. However, it trumps suffering because your boss is stuck doing their job from n years ago.