Your Employee Is Smarter Than You, and That's Ok
Your Employee Is Smarter Than You, and That's Ok
If you're in management, you'll eventually manage people who know more than you do about their field. How can you be a useful manager to them?
The topic this week turned out to be complex. The article reflects that complexity a bit. I tried to re-organize it a few times, and then decided it was good enough as-is. It turns out that a lot goes into the job of managing people, and pulling those threads together was a bit hard. Oh well! There's always next week.
As many of you are aware, Elon Musk wrote a post on Twitter about managers needing to be technically "excellent". He essentially said that managers need to be great at doing the individual contributor's role before managing the position.
I strongly believe that all managers in a technical area must be technically excellent.
Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!— Elon Musk (@elonmusk) May 6, 2022
I've already replied on LinkedIn to the claim that software development managers need to be great coders. And I know, there are a few caveats I may as well mention.
Some people interpret his statement as closer to, "You need to generally understand software development to manage software engineers". I don't disagree with that. If you're completely non-technical, managing technical people would be tough.
Others have anecdotal evidence of having micromanaging managers who gave them "dumb" feedback, because they were lacking technical competence. Anecdotes are interesting, but aren't evidence. There will always be anecdotes to back up any argument. Micromanagers are bad in all situations.
Instead of re-discussing Elon's claim, I wanted to address the important assumption behind his claim. Many of those who agree with him say a version of the following:
"If my manager isn't as good as me in my space, how could they possibly know if I'm doing good or not? How can I be coached and get feedback from a manager who knows less than me?"
Great question. When I started my career, I remember being surprised and annoyed that my managers didn't know as much as I did about software development. It confused me, because I had the assumption that my manager was like a teacher. I assumed that their role was to coach and guide me in my software development position. I was wrong.
In many ways, the management job is about delegating and connecting. You're the glue between other employees and your team.
You probably aren't keeping track of all project items yourself, but you're making sure that someone is.
You aren't likely the one designing the product, but you're making sure your team has access to a product design.
You hopefully aren't technically designing everything, but you're making sure that someone is. (I'll come back to this one later).
Finally, you aren't personally evaluating all performance feedback, but you're making sure the employee gets all the necessary feedback.
When might you not personally evaluate performance feedback, but need to communicate it anyway?
Situations where you might not observe the feedback
This is an easy one. As a manager, you can't be everywhere at once. Things will happen which you can't personally observe. You're still responsible for ensuring that the feedback is not ignored.
"Russell seems dismissive of my ideas. I understand he doesn't need to agree with all of my ideas, but he literally scoffs and rolls his eyes. It's rude."
This is the second person you've heard complain about Russell's behavior when you're not there. You suspect that they're not lying, so Russell is starting to burn bridges with his co-workers. You didn't personally observe it. You're not sure it's a fact. It's still your job to communicate the feedback.
"Hey Russell. I've heard from a few of your peers, particularly among the product managers that your response to their opinions is less than ideal. They're getting an impression from you that you don't respect their ideas. What are your thoughts on this?"
Since I've heard the above story dozens of times, I have a guess of what happens next. Russell will not blanket deny the situation, because this type of feedback is generally accurate. But Russell will explain his side of the story. The product manager was suggesting dumb technical ideas. The product manager was asking him to reduce his estimates. The product manager asked him why he was late on a complex task. He did roll his eyes and scoff, but essentially the product team deserved it for being a bunch of clowns.
My responsibility is to then accept Russell's feedback as well, and figure out how to deal with it. Separately, my job is to ensure that Russell understands that there is never a situation at work where the proper response is rolling your eyes or otherwise displaying a lack of respect. I walk through how he could communicate his disagreement or displeasure without resorting to emotional reactions.
This feedback situation was related to something I completely understand (interpersonal communication), but I didn't personally witness. What if the feedback is about something I don't actually understand?
Situations where you might not be the expert
As you begin your management career, you'll often start managing the types of employees who were your peers.
If you were a product manager, you'd move into managing product managers.
If you were a developer, you'd move into managing developers.
However, as you gain experience as a manager, you'll start managing those who have different careers.
This is particularly true at Amazon, where they like to build small complete teams which can deliver on value independently.
This means that a mid-level leader will end up managing the product manager, designer, and engineering team.
How can you possibly give feedback when you're not an expert in their area?
Not being an expert doesn't mean incapable of managing
There is a difference between generally understanding, and being clueless.
As an engineering leader, I had read likely hundreds of documents from product managers. I had sat in design and product discussions.
When my career grew to the point where a product manager reported to me, I was not an expert product manager. You could not possibly say that I was a "great" product manager, or "excellent" at the role. However, I understood the concepts.
I could easily give the product manager feedback on communication, gathering consensus, or hitting their dates.
But what about detailed product management feedback?
Imagine instead that I was a fantastic product leader. My career grew to the point where an engineering team reported to me. Sure, I'd participated in some standups. I'd joined a few Sev-1 calls on my products. I'd joined detailed design discussions. But I had never been a software engineer.
I could give feedback on general behaviors. But what about deep software engineering feedback?
At some point your career will grow to the point where you are not the personal expert at the jobs you'll manage. You'll hire an AI expert for your team. You'll hire a data scientist. We often hire to fill gaps in skills on our teams. This means we'll often hire a person who will be the expert in the room.
There are two major ways of providing feedback in areas we're not familiar with.
Proxy feedback - Utilizing the expertise of others to gather feedback.
Outcome feedback - Observing and providing feedback on the outcome of their activities.
