Engineering Managers Get This Wrong When Growing Their Teams

Transcript is auto-generated and may contain errors.

Hey folks, just driving to CrossFit here. We're going to experience dev subreddit for a question around coaching, mentoring, and helping put together growth paths for engineers. So, um I was just telling my wife on the way out the door, I'm like, I'm actually excited to talk about this one. I feel like feel like I got some stuff that's going to be helpful. Um I hope so. The framing in the rest of this post is like that I thought was like kind of funny uh was that this person's saying I think they're being set up for this kind of role. Um they're moving into an engineering manager position and they're saying I never really had training on how to be a great engineering manager. And uh the spoiler alert is like surprise no one no one does that. um it just doesn't happen. You're just expected to start doing it and be good at it, which makes no sense realistically.

Um considering that we have like, you know, uh secondary education that's multiple years long. Like my university education was 5 years with 2 years of internships baked into it um for software engineering. But like to become an engineering manager, they just change your title on paper and then uh good luck. So it's really unfortunate that it's not more common that there's like more significant training that goes into it because um it is a very very different role and I think that if you don't change how you act as a software engineer uh when you move into such a role then you're going to face a lot of challenges and it's going to be frustrating and you're not going to be effective at it and it's going to be frustrating for the other people that you're managing. So um it's it's definitely tricky and I wish they did more.

So the question is really around how do you structure a growth path for other engineers and uh the first thing that I want to say on this topic specifically is that uh all this kind of stuff is situational. Okay. There's going to be things in your leadership style and like especially from place to place where you work, uh there's there's going to be things that are consistent and you might build up like systems and frameworks over time that give you consistency or else it's just kind of all over the place. Uh these will be a mix of like things you learn about yourself, uh how you like to approach things, blah blah blah. um you know your values, this kind of stuff. But I will say that when it comes to coaching, mentoring others, growth paths, this kind of thing, all of that will be situational.

And it's almost like a bit of a warning. If you're doing this kind of thing and you're noticing that um it's not situational, it's not tailored to the individual, then uh just a heads up, you are probably not doing it effectively. And I don't say that to make it sound like I always do it effectively. Uh but I do recognize that everyone's sort of path is going to look different. Even if you have people that are at the same level in the same role, their specific growth path that they need to focus on can and will look different. Is it possible that you have a scenario where two people have the same things they need to to work and focus on? Sure. But that's like that's a coincidental thing, not the the norm. It's not just because you're at the same role and level, you must have the same strengths and weaknesses and the opportunities we need to look at.

Okay. So, I think understanding that it's situational is a a key thing to kick things off. But from there, if you're like, "Okay, well, you can get behind that. It's going to be situational. How do you learn and understand what the situation is for each person?" And I think this is a a sort of two-way or multi-way um thing that you need to like look at here. Oh, one is like on paper and career trajectory like what what does it look like where you're working for this person to go to the next step in their career? How is that framed up, documented? Is there a rubric? That kind of stuff. If you don't have this right, if you're at a like I've worked before Microsoft at a small company where um we had developer and then senior developer and then like in terms of growth that's not going to carry you your entire career.

So you may be in a situation where you need to kind of look outside of what is written down. But if you're at a you know larger company where there's more structure and things like that um you want to look at like where is this person and you know what is the sort of their next level um to understand again on paper how to move them forward. But then the other side of this is like understanding the person and that means effective one-on-one conversations. That means building up a working relationship with them. This means that you need to understand well if you're talking about one person you need to understand the person but this is why engineering managers need to spend time understanding their teams as individuals and investing time into that because everyone is going to be different. There's going to be people that are motivated in completely different ways.

You might have people that are hellbent on getting to the next level and like that is that is their motivation. And you might have other people that that's a side effect of everything they're doing and they're like, "Man, like if if I don't have like interesting problems to solve at work, then like I can't do anything productive because like I I'm so bored otherwise that it has to be an interesting problem." An interesting problem is a very generic statement. What's interesting to them, right? So, everyone is going to have their different motivations. Everyone's going to have strengths. They're going to have weaknesses. weaknesses don't mean necessarily that someone does something terribly and like that's dangerous. Um, it could just be that they don't get exposed to doing certain types of activities, right? So, let me switch lanes here and then explain my thought.

Um, when I say strength and weakness, I don't mean like, oh, like Jimmy on the team is really good at C sharp, but his weakness is like like some huge net negative effect on the team, right? Like that's not necessarily what it is. It could be. Um, but more often than not when we're talking strengths and weaknesses, it's like someone might have experience or a skill set around something, but they're not getting exposed to doing certain activities. So maybe Jimmy is really good at like at C, understands the language really well, can help on code reviews for like calling out nuance things as part of the language that people might not realize. like you know people can go to him and ask really deep technical questions but Jimmy hasn't really got a lot of opportunity to work on larger scale designs and then as a result Jimmy actually hasn't carried out on his own like leading larger projects.

So like that's a gap doesn't mean that Jimmy automatically sucks at it. It's not what I'm saying and it doesn't mean that if Jimmy were to do it, it would be terrible and be a net negative effect on the team, but it's an opportunity, right? So, when I think strengths and weaknesses, I'm more thinking about what things have people been demonstrating effectively and like where are the opportunities for them to go demonstrate that they can do those things. And so when we're framing all of this up, like I said, it's about understanding where someone's at, where they're trying to go to, and then factoring in their strengths, weaknesses. If you're an engineering manager, the way that I like framing things is like imagine at any point in time you get called in from your boss or your skip level manager and they say, "Hey, we need to talk about rewards and promotions for uh this person on your team.

And for like any engineering manager, if you're caught off guard like that, it doesn't doesn't happen like that of course, but if you were caught off guard like that, and odds are you would be, I certainly would be like most of the time. Um, to me, that's an indicator that like we need to be more in tune with like the next steps of career progression for our people. Okay. So, if that conversation were to be sprung on you, like what what are the the pieces of evidence that you could use to say, "Hey, I think this person is excelling in these areas. They're demonstrating these things we expect at this next level." And the opposite, these are the things I'm working on them with to go build up that experience so that the next time we have this conversation, I can say, "Hell yeah, Jimmy is doing these things.

He did it on X, Y, and Z, right?" And sustained it. It wasn't like a, you know, did it here, but then everything else went to right? Like, we need to be able to see that people are taking on challenges at the next level and sustaining the rest of all the awesome stuff they're doing. So, that's the framing I like to have is like, do I have evidence to showcase this on behalf of my employee? And so, I like that framing because to me that makes it more of a partnership. I am trying to represent my employees as best I can in those conversations, right? Like I don't approach management like hm like how can I like try and you know trick my employees into doing more more work and working harder and then I can like dangle the promotion in front of them. Haha. Like it's it's not like that for me.

I want to make sure that I can structure things so that it feels like we're working on it together, okay? Because I want people on my teams to get promoted. I want to make sure they have those opportunities, but I let them know like I am I need to work with them to get evidence to be able to have those conversations. So, when we do this kind of thing, this is where things get a little bit spicier because we're blending a couple of different activities together. This guy is going way too fast behind me. Let me get out of the way here. One sec. um we end up having to blend things together, right? Because the conversation I'm having right now might feel hopefully that feels relatively straightforward. I'm not saying it's uh you know the easiest thing but like hopefully relatively simple to understand like at least how I try to approach things, right?

I'm not doing anything crazy. It's really just understanding people and then trying to align your understanding with where they're at to where they're they're headed. And so the thing that you have to start blending into that though is like of course you are responsible for engineering deliverables, right? And it's not just one person you're managing, it's a team. So you have to spread this entire conversation that we're having across x number of people that you manage. So, it's just more more of the same thing. And the more people that you manage over time and the experience that you get, the more patterns you see, the more um the more when you're trying things out, maybe some things don't work, maybe you can bring that experience with you to the next person that's kind of showing similar, you know, growth paths and things like that. So, experience helps so that you get more comfortable with this kind of thing.

But the other thing we're layering it against is the engineering deliverables. And you might say, well, okay, if I wanted to get the most effectiveness for delivering against a road map, the most effectiveness. What I would do is I would go, cool, who is the absolute best at all of these things, right? We have to build this feature. Okay. And this feature is really heavy on this part of the app and this technology stack. And you know what? Uh Sally on the team is like the absolute wizard on that. Boom. Right to Sally. Okay, this part we were just talking about Jimmy and C and this is a refactoring thing and like he knows so much about the language and like that'll be perfect for Jimmy. He's also worked in that space. Boom, Jimmy. And if you go hyper optimization on like what is everyone best at and the experience they have and you always repeat this, what happens over time is that you create silos in the team.

Okay. And it's not that it's wrong to assign like work where people are really well suited for it. That's not that's wrong. But you also have to balance that with basically the opposite. Where do people need growth, right? If G if Sally is the only person ever doing X on the team because she is so good at it, it's a really awesome thing to be able to lean into cuz you could say awesome. When we have this kind of work that's coming up, we know that we can get pushed ahead by Sally because she's so good at it. What happens when Sally's on vacation? What happens if Sally leaves the team and you've spent 3 years only giving that kind of work to Sally? Now you're screwed. Not only that, maybe there are other people on the team where this would have been a really good opportunity to help them grow in different ways.

So a lot of the time we're trying to balance like how do we kind of scale up and give those experiences to other people on the team. You don't want a single point of failure from like a team safety kind of perspective, longevity. Um so that's a lot of risk mitigation, but the other part is like these are literally growth opportunities to give to other people. And what's cool about that is it doesn't mean that you say, "Hey Sally, screw off. for putting putting Billy in on this one now. Like your your days are numbered on this feature area. No, it's like if we're going to bring Billy in to also work in the space. Hey Sally, this is such a good opportunity for you to be able to take a different approach here because Billy is going to have lots of questions. You can help coach Billy, right?

You now give different types of opportunities to these individuals where they have lots of strength and experience. The side effect of all this is that you have things that are going to go a little bit slower, right? It's not Sally doing it, it's Billy and he's never done it before or he's very inexperienced at it, which is okay. He's going to get coached by Sally, so that should help. Again, that's more of Sally's time. So maybe that's a hit in some other areas. But now over time, Billy is one more person who's getting better and better and better in this space. So you're building flexibility into the team. You're building maybe in the future there's a lot more work in this space and then both Sally and Billy can go tackle it. Um, and then if we're thinking about we're doing this because this is a growth opportunity for Billy, this might be tons of unique different experience that you can use as evidence in Billy's promotion rewards conversation, right?

So we end up kind of slowing down in the short term to to speed up or be sustainable long term to be more robust as a team long term to give growth opportunities to individuals long term. So, call it like a manager's dilemma, but that's kind of how I see it is that like if you're trying to hyper optimize on pure effectiveness on deliverables, then you're kind of looking at who is the best, the most experience in certain areas. And don't get me wrong, as I say all of this, I'm not trying to make it sound like I never do that. I absolutely do that. There are certainly cases where I'm like, "Hey man, like this is really urgent and something's come up, it's really urgent and um timeline for this, like we need someone who can move fast or there's a lot of risk

because of how how urgent and how quick we need to move." And like this probably isn't a good time to put um Becky into I'm really terrible with coming up with names on this, putting Becky into this spot because she's never done it. She might have just finished up her work, but there could be a lot of risk in trying to put Becky into this at this moment. Okay. So then I might go back to the person might go to Fred and say, "Fred, you are the expert here and like really sorry. Uh I might need you to kind of pivot from some of the work you're doing because this has come up." Right? We try to minimize things like that because randomizing people is huge pain in the ass for everyone. But sometimes these things happen. So the dilemma is really balancing like how do you take the opportunity to slow down and help grow people in areas where they need growth as well as you know uh optimizing for efficiency on deliverables.

So I hope that helps. There is a lot to discuss on this topic as you can start going into more more specifics but I I hope the framing helps. That's how I would generally structure these types of things and how I like to uh like the lens I kind of look through when doing so. So, um just pulling into CrossFit here. Friendly reminder, if you have questions you want answered, leave them below in the comments. Otherwise, go to codecame.com. You can submit questions anonymously that way and I'll make a video for you. So, take care. See you in the next one.