Managing engineers more experienced than you
Three mistakes new Engineering Managers make while managing highly experienced engineers.
When I first became a manager, I inherited a few engineers who had more years in the industry than I did. Some were absolute experts in technologies I barely touched.
Inside my head, the voice of my insecurity was buzzing:
“I’m not as experienced as they are. I’m not as knowledgeable. What if they question my authority? How can I manage someone who clearly knows more than me? What could I possibly teach them?”
If you’ve ever felt like that, now you know you’re not alone.
Over time, I learned how to manage (and learn from) these highly experienced engineers by fixing the mistakes I was making.
1. Trying to be the expert
When you’re new to managing senior talent, it’s tempting to think “I need to be an expert myself before I can lead them.”
That’s a trap.
While you were busy reading leadership books and blogs, these engineers were sharpening their technical craft. And you think you can match them? Across every tech stack? While juggling your duties as a manager?
No fucking way! So, stop competing with them.
Instead:
Accept your technical knowledge. It’s fine not to be a pro in every technology. You just need enough to move the discussion forward. Lean in to your team for their knowledge and expertise.
Complement their skills. There is more to software delivery than the technical stuff. You can help them frame the problem better, breaking down projects, estimating, stakeholder communications, etc.
Help them grow by coaching. Highly experienced engineers also have gaps. You just need to spend more time identifying them. And then help them improve those areas, e.g. how to give feedback or how to mentor others. If you can’t teach those skills yourself, recommend a course or a mentor.
2. Getting completely out of their way
There’s a popular saying for managers, “hire smart people and get out of their way.” What you learn in the real world is that there are different degrees of “getting out of their way.” And often it’s not 100%.
You need some sort of involvement for your engineers to be successful. Even if they’re highly experienced.
You may mean well by trying to give them “full freedom”. Or trying to avoid being labeled a micromanager. But the thing is software requirements are often vague and subjective. It’s expensive to redo stuff after it’s derailed.
Certainly you don’t want to waste your most experienced resources.
Instead:
Set them up for success. Make sure they have everything they need to be successful. Set any expectations early, like “document major decisions along the way”. Define when and how you’ll reach out to each other. E.g. when new risks or requirements appear.
Have periodic checkins. Do a quick review of where they’re going and if it’s in line with what you are thinking. Dig deeper only if needed to unblock them. Ask clarifying questions to help them make better decisions or provide any early feedback.
Be present when it matters. Sometimes just being there for your engineers helps even if they know everything. It makes them feel confident and give their best. I realized this after an engineer said, “It was great to have you on the incident call when I ran the disaster recovery. It prevented me from panic executing the commands.”
3. Holding back on the feedback
This one took some work.
It’s easy to think that the experienced engineers don’t need feedback. Or worse, you’re afraid of offending them. After all, they’re already adding tons of value. Why risk rocking the boat?
But withholding feedback doesn’t benefit anyone. It lets small problems fester into the team. Everyone just silently keeps working around it.
Annual performance reviews become awkward bombshells. They walk in expecting their best rating ever, and you’re staring at two pages of unspoken notes.
Instead:
Keep an eye where they could have done better. You may not find it as frequently as your junior engineers, but when you do, take note of it and go deeper. If you don’t see any, raise the bar and be on the lookout again.
Frame feedback around wider impact. “You’re producing great code, but I’d love to see you raise the team’s overall quality through mentorship and reviews.”
Catch opportunities to praise, too. Feedback doesn’t always have to be about improvement. You can use it to acknowledge and reinforce behaviors, when they set the bar high.
Even your most experienced engineers have room to grow. Your job is to help them see where.
Closing Thoughts
Managing engineers more experienced than you can feel intimidating at first. But once you realize that your role is not to compete with them, you end up finding the space to actually help them.
The way to manage them is different from how you manage juniors. Your involvement may be less but not zero. Focus on creating clarity, providing support, and helping them multiply their impact.
That’s how you partner with them and level up the whole team.
Solid post mate! David Ogilvy - "Always hire people better than yourself and let them get on with it." I think there was another one from Charles Schwab of US Steel in terms of surrounding himself with people better than him. I like your stuff. Subscribing now.