Check out a free preview of the full Engineering Management Fundamentals 101 course

The "Mistakes to Avoid" Lesson is part of the full, Engineering Management Fundamentals 101 course featured in this preview video. Here's what you'd learn in this lesson:

Jem reflects on their own mistakes as a manager and provides advice on what to avoid. He also discusses the dangers of micromanaging, overpromising, staying too close to the code, overthinking decisions, not letting go of previous work, and putting too much pressure on oneself. The lesson emphasizes the importance of trust, delegation, and self-awareness in effective management.

Preview
Close

Transcript from the "Mistakes to Avoid" Lesson

[00:00:00]
>> And as we close out, I wanna be honest and transparent with you on mistakes to avoid. Don't be like me, I've probably made some of these mistakes, and sometimes multiple times. Mistakes to avoid. Micromanaging, we talked about why that's one of the worst things to do, but it's one of the easiest traps to fall into, cuz you feel like you're doing something.

[00:00:20]
But really, you don't trust your team, you're not delegating effectively, and it's not a good use of your time. I've definitely done this, and I've tried to step back. I've gotten feedback before on how I show up, I'm not telling people what to do, but some feedback I got early in this year, we do 360 feedback once a year at Netflix.

[00:00:39]
Some people are familiar with that process, but just it's time for all the company to give feedback to each other, which I enjoy now more, I didn't used to. But feedback I've gotten was, Jim, you're too technical, you're too in the weeds on technical decisions. And I was like, and I got that from a few people, and I was like, I thought I was being a good engineering manager, but it turns out I was slowing the team down.

[00:01:00]
I was slowing people down by going in the wrong direction, or just getting hung up on the nuances that I didn't even know. And that's a form of micromanagement too. So I've had to step back and ask broader questions. What are the pros and cons? What are the alternatives?

[00:01:17]
Those sort of questions, rather than being in the weeds. Overpromising, a mistake I made early on, too. Everybody's like, Jim, can your team do that? Yeah, totally, no problem. Jim, can your team do that? Yeah, totally. Cuz you wanna show up well and impress your partners. But it turns out taking on all these other requests were slowing down the things that were in flight for my team, and I was just slowing them down by promising.

[00:01:41]
So the better solution is, you don't have to say no immediately, but saying, okay, let me bring that to the team and I'll come back to you on where we can fit this in, rather than just trying to please people right off the bat. Trying to stay too close to the code.

[00:01:56]
I still see this, I see it a lot. Managers in pull requests, commenting on individual lines of code. Again, depending on your role, the size of the team where you need to be, maybe, but generally, if you're at that level, you're probably too close to what's happening. You probably don't need to be that close, or you need to hire and build people up.

[00:02:16]
Who can do that for you? Hire a senior engineer who can do that for you. That's not the best use of your time. Overthinking decisions and second-guessing, this is me, 100%. Second-guessed everything I did. Is this the right format for a team meeting? Is this a good off-site?

[00:02:31]
I put so much pressure on myself and I just stress myself to a bad place. And really, it's just make a decision, make sure it's well reasoned, make sure you get a lot of feedback on it, but just do it. And understand, you're gonna screw it up, don't be too hard on yourself.

[00:02:50]
And not letting go, especially if you're taking on a team that you wrote the service or the code and you're super familiar with the code base. Trying to shepherd it and trying to baby it still, cuz you're like, you wrote it, it's my thing, you gotta let that go.

[00:03:03]
You won't be effective as a leader if you're too close in the code. And this is really hard to do, especially as a software engineer, or former recovering software engineer.
>> [LAUGH]
>> And finally, putting too much pressure on yourself. You're like, people are looking at me now.

[00:03:21]
I don't know if you remember the dark days of puberty, where you're a teenager and you feel like everybody's looking at you all the time. And it turns out nobody cares about you, everybody cares about themselves, and that's just how humans are. When you become an engineering manager, you're like, everybody's looking at me, everybody's expecting these things from me.

[00:03:39]
When really it's not as bad as you think. But when you first take it on, you're like, I gotta do this, the team should be performing. I gotta have answers to all these solutions or problems, and you really don't. Take your time, be curious, be empathetic, and listen, but don't put too much pressure on yourself, that will come over time.

[00:03:59]
The pressure will come, so don't do it to yourself.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now