The Top Mistakes Of New Team Leads and Managers

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving CrossFit, heading home here and uh going to go to experienced dev subreddit for a topic. This one uh the subject was essentially team leads and new managers like what's the you know mistake you made when getting started out. I thought it was kind of an interesting one to go over. They listed a couple things from their own experience and I thought that was great to like you know I think it's always awesome when people can share learnings especially when it's like mistakes right because we don't get perfect um like ever and so expecting that it's going to be perfect when you start and then being disappointed if you mess up or whatever make a mistake um it's just normal right so we got to learn from this stuff but thought it'd be fun to talk through um so I'll go

first I suppose but like I think early on for me my my very biggest mistake with uh being a new manager like so new to management as well as uh for me that was a sort of transition from being an IC on the team to to managing the team and um I think biggest mistake for me um well there's a handful but uh I think one of the biggest ones that I reflect on is uh like not not giving even the people that are uh like clearly excelling uh not giving them focus time for like coaching and guidance and stuff like that. Um like to me that's one of the biggest uh misses. And I think like I'm not trying to make an excuse for like not doing it because I I think that it is important. I think that is one of my biggest mistakes.

But I think I understand kind of why it happened, especially early on. So, I wanted to to talk a little bit about that so that there's extra context, especially for people that are new team leads or becoming engineering managers. And maybe there's some some similarities here. But, um, for me, it was like uh probably stems from a time commitment like you only have so much time. And uh for me, I was still contributing to the codebase and and now managing individuals and being new to it, right? So like I don't even know what I'm doing. Um sorry there's this lights out so I got to make sure people are paying attention before I drive through. Um you know there's there's only so much time but now I've added like a new thing which is managing people that I have no idea how to do. So, like when it comes to like, okay, well, what makes sense for me to spend my time on my brain?

Oh, yeah. Don't. You got to look both ways, pal. Holy crap. This person pulled out halfway from a side street and just like stopped. Not good. Um, there's only so much time. So, like if if I have to not spend time on something, I'm like, well, these some of these people are doing awesome. So, like clearly they don't need my help, right? That's the kind of the mindset was like, if they're already doing great, what am I going to do that's going to help them? I should focus on the people that um are underperforming, I should focus on the people that seem like they're not engaged. And I don't know, like in hindsight, sure, I I can still rationalize that being like not a terrible thing, but at the same time, I think that set me off on a path where I just like made the assumption that, hey, like because these people are awesome, they don't like what am I going to do to help them?

They don't need me, right? But um it's um it's kind of it's a different framing. It's not like they need me, but like they would also benefit from guidance. They would also benefit from being able to align what their strengths are with career progression or opportunities for projects and other things like that. So like I was not doing a good job facilitating that for the people that are awesome. Now, in also in hindsight, like a lot of those people um went on to do very very awesome things, right? Like there's two individuals I can think of that used to report to me and uh like they're directors at the company that I used to work at. Like they are doing great. Um and early on when I was managing them, I think that I was probably pretty handsoff with them.

So, you know, part of me is like, yeah, they were they were really good and they um you know, they could kind of carve their own path, but at the same time, uh I don't want that to be part of my management uh style where I just like ignore the high performers. I want to make sure that I can channel them um so then they get the most out of it. So, I think that was one thing. Um I Oh my god. What is going on here? This person I got to get out of this lane very badly. Person got in front of me and was going like below the speed limit. So um I think the most common mistake that I see with new engineering managers is like and it becomes a problem if it doesn't get addressed. Uh it's like you you need to realize that your role is is different when you become an engineering manager.

Um, it's great if you were an awesome software developer. Like, hell yeah, that's awesome for you. But if your way to solve all your problems going forward is like, well, let me just jump in and code it. No, that's not like that is not what scales. And you are now in a position where you need to really be thinking about scalability. So, don't get me wrong. If there is a critical issue and that you know that you can help with the team by contributing, like I'm not saying don't do something that's going to help the team, but that shouldn't be your go-to move. Like, you should use that as a signal if every time there's a an issue or a challenge or something and you're like, "Well, I have to go do it. I have to go write the code. It's me." Um, use that as a warning sign like there is a problem with how your team is skilled or focused or whatever knowledge.

There's a gap and you're currently filling it and that's not a scalable solution. uh truly like I think it becomes a huge limiting factor for people because they're not thinking about how their team operates. And I I often go back to this mental model of like uh and this sounds funny but like I feel like the people that become the most successful at what they do, they make themselves obsolete. And that I realize that sounds funny because if you think about like a job security perspective, you're like, "Hey, like hold on. Like I don't want to make myself obsolete. I want to be needed." Right? If you make yourself obsolete, why do they need you? The point is, if you've done your job really well, they shouldn't need you for that anymore.

And instead of being stuck in a spot where you're permanently paying a tax to keep something going, I think that it is much better to be able to try and find a way to make that possible where you don't need to be paying the tax so you can go on to the next more impactful thing. Right? If you do something that is great and it's accomplished and for the rest of the time that you're working somewhere, you constantly pay the tax, now you're unable to go have as big of an impact in new areas because you are constantly paying a tax, right? So I say this for software engineers like, hey, you built this system and you're responsible for it. Awesome. Like huge contribution, you should be proud.

But if going forward anytime there's like hey we need to enhance this or hey there's an issue with it or hey I have a question if from then until the end of time you are the single person that people have to go to you're paying a tax that will permanently take away from the remaining time you have sorry I have hiccups or something um so like use that as a signal okay people keep coming to me for What can I do? Is it documented better? Is it have videos on it? Is it that something's not clear? Is it that the system's brittle and needs to be fixed? Can I get other people to become, you know, uh, subject matter experts on it? Like, what do you need to do to make that so you are not constantly paying the tax? And I think this is one of the biggest issues I see with engineering managers is that they don't realize that them still operating as an individual contributor is not a scalable solution.

It is 100% okay to jump in in critical scenarios and help. Like that's awesome. The more people that can do that the better. Like of course that's when all hands are on deck and we need to be thinking about how do we get out of this storm. So that's great. But if you need to do that every time, what does that mean? When there's an incident and you're not present, your team falls apart because you're the only one that can save it. Like that means there's a gap. So how are you going to go address that? I always like it again it sounds funny but I I have the mindset that if I'm doing my job as effectively as I can I should be able to walk not that it not that it would be like a good long-term solution by any means but I

should be able to like not be present for my team and when it comes to like scheduling work understanding priorities that kind of thing they should know or be able to ask the right questions right they should say hey look we know that we set off in this ction. This is the focus areas we have. And as they're making progress through that, they would say, "Okay, this is what our team values are. This is our team's mission statement. This is what we should be driving towards. Cool." Like, let's go look at what work is available and prioritize that. And like they should have autonomy. If they feel like, well, we we we have to get sign off from Nick to do this, then like again, I don't feel like I've done my job properly. I think it's great if they want to like we're all getting aligned on what to do next.

Like I think that makes sense. But if I was on vacation for 2 weeks and something critical came up, are they going to be like, "Well, I guess we can't guess we can't do anything because Nick's gone." I would surely want them to be able to go, wait, we know how to prioritize this, right? So I think again I think that's one of the biggest mistakes I see engineering managers make is like not understand that um they should not be the bottleneck and I don't know maybe some of them don't know how to identify that maybe some don't realize it's happening um maybe some of them it's like hey if people don't see me coding then they're not going to respect me whatever um like and on the coding front I always tell people right like I've been at Microsoft for 5 years. I don't code at work, but like I can demonstrate to my team that I understand what's going on in code many other ways.

Like literally yesterday, one of my principal engineers put me on a review because I've been participating with him on his design doc as he uh goes through architecture and presents it in different forums. And uh it's a great opportunity for me because I've seen the design come together on paper and in discussions and now I'm seeing the code come together to support it and it's in a language I'm familiar with right so I can go reading the car code. I can go understand the design and architectural document and I can participate. So, you know, like I I don't have to be the one writing code to be able to work with my team members and uh and demonstrate to them that like on a technical level I understand what's going on. There's always going to be parts of the domain that we operate in that I absolutely expect that the engineers on my team will be able to go much deeper than me.

That's part of it. right? They're in the weeds. They're the ones working on it. I fully expect that they will be able to go much deeper than me. But that's okay cuz we work together on a team. But yeah, I think that's one thing. Um maybe one more comment on that is sometimes I think that uh new engineering managers get caught up in that because they are not sure how to um how to think about their accomplishments. That's weird that tractor trailer is open. I don't feel good about that. But there's just like boxes of booze and this whole tractor trailer is open. Anyway, whatever. Um I I think that they don't yet understand how to talk about their uh their impact, right? when you transition from an individual contributor role to like more of a management role, they're used to their impact being like, I built this thing.

I I did it, you know, I led the architecture. I wrote the code. I flighted the changes out. I tested them. Like, I I'm the one who had to go get buyin from partner teams on my design. Like, I did these things because I'm an individual contributor. And when you transition to management and you're like, well, how am I going to get this list of things that I did, uh, the if the only way you know how to do that is from the fact that you were landing code, it's going to feel weird. And, uh, I think a lot of the time people anchor to that and then they they can't let go because they don't want their performance review to come around and they're like, uh, like I didn't code anything or like, you know, I didn't code as much and now it's terrible. Like, no.

like your impact is in very different ways, right? You are often enabling your team to go do work effectively. You're working with them, but the role that you play is not coding the stuff alongside them. Generally, this absolutely still happens in smaller teams, uh, smaller, scrappier companies in general. So, I'm not saying there's no place for it. If you have a small team, it probably makes sense for you to also be writing code with them because the amount of time you spend on the people stuff does actually facilitate other room for for things like coding and whatnot. Uh maybe take more of an architect role or something. Depends. But you can usually do a little bit of something else. Um, but yeah, I think that's probably one of the reasons that people get kind of stuck or anchored to like I still must be contributing code.

But yeah, so I think for me, like I said, my big um mistake was not really um not really thinking about coaching the people that were doing well. And I think the the biggest sort of misstep that I see other engineering managers make like the common one is uh is not realizing like they are the bottleneck and that needs to be prioritized. So I hope that is helpful framing. I'll wrap this video up here. If you have questions that you want answered, leave them below in the comments. And of course, if you want them to be answered anonymously, you can go to codemute.com. You can submit your question there totally anonymously. I just get an email for it. And a reminder that I have other YouTube channels if you're interested in different content. So, you can check out Devleader for C.NET and AI programming tutorials. There's Dev Leader Path to Tech, which is the channel where I do resume reviews.

So, you can submit your resume and I will check that out for you. I anonymize it. I review it on the channel. It's not a roast. It's uh very much a like here's what I think you're doing well, here's opportunities. And uh the other channel I have is the Dev Leader podcast. And that's the channel where I interview other software engineers. We talk about their career journeys. And then I do a live stream every Monday at 700 p.m. Pacific on the Dev Leader podcast. That is an AMA format. And we generally take topics from code commute which you're listening to right now and then we kind of go through that plus an AMA. So would love to see you there and I will see you in the next episode. See you.