When you know more than your manager
It could be ideal, or it could be an issue.
Is it a problem when you know more than your manager? Or, specifically for SWEs, how much technical expertise should your engineering manager (EM) have?
As usual, the answer is It Depends. Here’s the breakdown:
There is an absolute minimum
There is a higher, relative minimum
It is useful for a manager to be above that minimum, with diminishing returns
There is no maximum
Let’s take those one at a time.
There is a minimum
As the folks in my Slack community loudly asserted when I put this question to them, there's definitely a floor. If your EM knows nothing of what you do, it’s too hard for them to represent you to the org or understand your blockers, among other things. A few illustrative examples:
One manager, in high-level meetings, would regularly make assurances to the rest of the C-suite that were flat-out untrue. This wasn't deceit, they just didn't know the specifics of what was technically possible! And worse, they were uninterested in learning those specifics, unwilling to admit “I’m not sure, let me check with my team,” and unable to get the more technical members of their team into that meeting.
Another manager was unable to give even ballpark estimates on behalf of their team. They were asked by some external stakeholder to find someone to do a simple task, and they treated it like a quarterly project. (with awkward outcomes when their team found the ticket in Jira: "Oh, uh, I saw that spike deep in the backlog, so I clicked a button in AWS, which means the ticket is done now. I guess that's… zero story points?"). This is very frustrating for the stakeholder, and erodes their faith in the team.
A major pain point for their reports was ignored for months by the EM. If the manager had been coding, they would have realized quickly that the issue was bad enough to be worth spending multiple sprints to fix.
What can we conclude from all this? You should be able to have a conversation about complex technical hurdles without your EM’s eyes glazing over. They don't need to be good enough to help you fix it, and it's fine if they have to ask a bunch of questions, but they should know what questions to ask in order to understand your blockers.
If they fake expertise, that's a big red flag. But be wary of over-interpreting this, since managers suffer from Imposter Syndrome just like you.
There is a higher, relative minimum
If there are no senior engineers around, your manager needs to be one or hire one.
Even if they hire one, the manager should not be way less technical than their entire team, else they'll be unable to answer any technical questions from leadership in real-time1. To be clear, it's fine if they are less technical than most of their reports, and it's even fine2 if they never code. In a healthy team, when someone gets blocked by something technical, one of their teammates will be able to step up to help.
They should know and account for their weaknesses. It’s fine for a manager to be bad at project management, as long as they can reliably find someone else they trust to manage the team’s projects. Similarly, it’s fine for them to be weak technically, as long as they can reliably find someone else they trust to help with technical design. Maybe that someone can be you!
To an extent, it’s good for them to be above that minimum
An EM is not just a SWE with a fancy title. Their duties vary wildly depending on what their team needs, but it’s a safe bet that they need to be great at giving feedback and communicating across teams3. Obviously, an engineering team has to have engineering talent, and the more such talent the manager has, the less they have to worry about hiring other people with those skills. But those skills can be delegated out more easily than feedback and communication can.
Let me put it another way: A good relationship between a manager and their report is one of partnership, not subservience. When they need a deep technical opinion, they can come to you. When you need to work towards a promotion, you can come to them.
Their job is different, so their skills are different. Technical skills are helpful, but gaining technical skills has sharply diminishing returns compared to gaining other relevant skills.
(Given how many engineers resent managers’ existence4, I should probably write an article about what they do at some point5.)
There is no maximum
What if your manager seems too technical? I’ve certainly felt this sentiment in my career, but it’s ultimately misplaced.
There is a risk that such a manager recognizes and relishes this skill, to the extent that they spend their time writing code that should spend supporting their team. Or worse, they tell their team exactly what to write instead of letting them learn for themselves6.
In the face of that, I’d say the problem here is not that they’re too technical, but rather about lacking something else: maybe delegation skills, maybe mentorship skills, maybe hiring skills. Avoiding a manager just because their technical skills are sky high is a misattribution. In a vacuum, all technical competency is an asset.
Do be wary, though, of how you use your 1:1s with such a manager; there’s a temptation to use all that time getting technical guidance, but it’s important that you leave some time for feedback, career progression, etc.
What do I do if they fail to meet this bar?
If you discover that your manager is below this bar, especially if your teammates agree, you have entered Managing Up territory. Again, this warrants another article, but I’ll give you two tools to start with:
In How to deal with jerks, we talked about giving critical feedback to people we don’t get along with. All the same advice applies to an insufficiently technical manager: build safety, talk about some of the data points that concern you, hear their analysis, and build a consensus. Maybe this is a huge miscommunication, and they have more competency than you think. Maybe they can learn technical skills by tackling some tickets7, or by taking courses. Maybe they can shift to another team. As with a jerk, escalation is always a valid option.
Depending on what skills already exist in your team, you might be able to find someone else to fill this niche. Lara Hogan calls this Building a Manager Voltron: with enough networking, you can find someone else to communicate technical stuff to leadership. If you have the technical and communication skills, that someone can be you!
To assess your manager, look at your team
I think a major source of this anxiety is a bias from early in our career: when we’re new to the job, our manager is surely our technical superior, and probably one of our best mentors. As we gain seniority, that inevitably changes, but our expectations don’t naturally adjust accordingly.
Don’t make the mistake of assuming that change is a problem. If your team has the technical skills it needs and your manager can follow the conversation, you should be fine.
Picture a panicked Slack message to the team at 4:59pm: Does anyone know how to change the color of this button? Please answer in the next 30 seconds.
and sometimes preferable
Unless they’re new to the role. Hey, everyone starts somewhere!
Or try to do without them (see Valve and Old Google (but not New Google))
In the first draft of this article, this sentence started with “As I’ve written about previously” and then I realized I was lying. Another for the list, I suppose; it’d be great if my coaching calls turned into articles automagically.
I’d reluctantly call this micromanaging if pushed, but I generally find that term to be overused to uselessness.
They’ll probably need to delegate some of their duties to make space for this.