How to Mentor Mid-Level Engineers: They Don't Even Need My Help!

Transcript is auto-generated and may contain errors.

Hey folks, we're going to Reddit for a topic today. This one is from experienced devs and the topic is around mentoring mid-level engineers. And I thought this would be an interesting one to go through because uh I don't think that this person's an engineering manager. I think they're just uh you know software engineer. When I say just, I just mean from the perspective of responsibilities and stuff like that. So um not like it's a lesser job or anything. It's a different role entirely. So, um, they've been kind of given this opportunity. Uh, this person's going to try to let me in, but that's not going to make any sense. I got to signal them somehow cuz they're going to wait and I have to go across like four lanes of traffic to turn left. Um, but from their set of responsibilities, right, they're tasked with uh mentoring a couple mid-level engineers and they're going like, I don't really know what to do here.

I have to go all the way across. Thanks. Um I don't know how they heard me but that worked. So um I thought this would be good to talk through because even as an engineering manager when I kind of started off in my role, this is something that I I struggled with because it's weird. Um especially because the extra context this person gives is like these guys seem to be or sorry guys or girls I don't know um seem to be like productive like they work pretty independently so like you know what the heck am I supposed to do here right they're already doing their job what am I going to add so it's an interesting thing to to sort through and uh I'm going to try to to share some perspective on this but Um, I don't think like with this kind of stuff, I don't think there's like a single right answer or whatever, and of course what we don't know is like how did this get kicked off, right?

So, I always try to be clear about this kind of thing that um, you know, this is something this person's manager was like, "Hey, I really want you to do this." like if you don't understand why or you don't understand what the the goal was, I would go seek clarification on that, right? Um if like the manager knew something around this and they wanted you to focus on something specific, that would be really good to try and get that kind of detail uh drawn out. Um, it might just be that your manager or this person's manager in this case is trying to give this individual some opportunity to do some mentoring. It could be that the manager knows that for these two individuals there are some challenges or they need to focus on something. Like there could be so many different things that as we chat through this there's we just don't have those details.

And you know what? maybe the person who wrote this on experienced devs, maybe they don't have those details either. Okay, so it's um it's just one of those things that like I would strongly encourage this person or yourself if you're in a similar situation like go ask. Come on, it's a highway. You got to speed up. Let's go. Oh, we have a light to stop us. That's the worst. Come on, let's go. Go. Well, that ended abruptly because no one's actually accelerating. So again, get clarification on this kind of stuff because uh you know, this is done likely for a reason. And if you don't fully understand that, I I don't think there's anything wrong with asking getting clarification. In fact, I only think that can help. Okay. Um Oh, it's a very very tight merge. Okay, I don't think I can get into a fast lane here.

Um, so, okay, so this person says, I am in this position where I have to go mentor these two mid-level engineers. They're doing good, like they're independent, like what should I be focused on? And I think a few different angles that we can take here, right? Um, one is to start things off. Uh, I don't know this person's working relationship with these other engineers. So, I would just make sure that uh you spend some time actually building like the trust and respect up. You might have some of that already. Um, it might be purely just because of your title and seniority and that's kind of maybe a little bit implicit, but I think that that's never a good thing to just purely rely on because you might have people trusting your decisions. Uh, they might respect you for your your title and all of that, but um, in terms of in terms of really getting messages across to other people, I think that you really have to earn that trust and respect.

Right. So, just to give you an example, I have people on my team currently in teams that I've had before where they are junior level and they're working with principal level engineers and sometimes they just take what they're saying at face value. And more often than not, of course, the principal engineers are very experienced. They're very smart. They understand the systems. Um but sometimes what can happen is that it's challenging to work with the principal engineers because they might have diff different ways of communicating that the more junior people don't know. Um that creates a weird friction because now the juniors like don't like working with the principal engineers even though they think that they're always right. I've had people tell me that they've learned to sometimes challenge what like principal engineers are thinking, not in like a, you know, a disrespectful way, but to actually remember they're also human, right?

They're going to make mistakes. They're going to make assumptions about things and you should be asking. There's nothing wrong with that. So, I I say this just because if you're building up this working relationship with other people, put in the time and effort to go build that trust and respect. Um, and I think a way that you do that is by demonstrating to people that a few different angles on this, right? on on the actual I don't know core part. I feel like by demonstrating that you are accountable to the things that you say, you follow through on them, then that helps tremendously. But I think another angle on this, especially from a mentorship perspective, is like show them that you actually care. Uh if you were tasked to go mentor people and you just kind of show up because someone forced you to do it and this person is saying like the they ask their mentees like what would you like to focus on and they don't really know.

If you go okay well I guess we're doing nothing like that actually doesn't help build up that relationship. uh it certainly makes it challenging for you as a mentor because obviously uh and this goes this it's the same kind of thing with uh management right if I have people on my team that tell me I really want to focus on X makes it easy for me to to kind of uh work with them on that um if I have people that are underperforming it makes it easy for me to go say okay like I know what to go focus on but when you have the exact opposite where you have people that are doing well and or you have people that are doing well and they don't know what they want to focus on. Like that doesn't mean that there's no growth opportunities. It means you have to go put in some effort to look at different angles for growth opportunities.

Uh and I always encourage people like and we'll chat about this I guess but the the mentees in this case if they're like oh I don't know. um it shouldn't be all on the mentor or a manager depending on the circumstances. It shouldn't be all on that person to like go figure it out. Like one of the things that people need to learn is that in their careers they need to be accountable. So you can't like I don't think it's a realistic perspective to just like show up and and never have an opinion about how you want to grow and then just expect that other people will do all of that guiding for you. Like I just I don't think that that's fair and I don't think that that's realistic. So you kind of have to you have to learn this for yourself that you need to be able to kind of reflect on what you're doing and have some ideas.

You might not know the steps to take, right? that's totally fine. But it's a really good skill to be able to build up to do this reflection and figure out like where do I want to be going or what challenges am I facing or or whatever it happens to be like identifying these these areas. So yes, a mentor can help you with that. Um and yes, a mentor can help you like navigate and trying to figure some of that stuff out. I think that's totally realistic and feasible. But if you're every time in these like mentorship opportunities like never showing up with with any input to it. Um even if a mentor is trying to help you kind of like dissect it and pull it apart and figure out like what are some areas that could be good. I mean, at some point it's like you can't you can't have the mentor or sometimes a manager putting in more energy than like consistently than the individual who's being mentored.

It just it doesn't scale and it's not really fair or realistic. So um I think for this person given that they have you know some mid-level engineers that they're mentoring that are doing well they are pretty independent and they're not specifically calling out like hey I'd really like to focus on X. I think one thing is that to keep in mind that if the individuals aren't yet selfidentifying don't lose sight of that. doesn't mean that you have to like rely on that from the beginning, but I wouldn't lose sight of it. I would figure out ways to come back to that periodically and it might take some time working together. It might take some time like kind of stretching in different directions first before they start to go, hm, now that I've had a taste for this or now that I've experienced something or now that I've seen X, maybe I do want to like focus on whatever.

So, I would periodically come back to this, right? I'm not saying every week. I'm not saying like on some particular cadence or interval, but don't forget about it because I think you want to get to a point where individuals can self-identify because that is a thing that you're going to want to I don't know like under the the surface try to get them to to realize is like this becomes much more effective if you are selfidentifying uh the areas that you'd like to improve in. That could be by the way uh as a mentor uh these individuals could be working with their own manager about career development. Their manager could be giving them feedback like I'd really like to see you improve with thing X or whatever and then like you could work with them as their mentor to help give them some extra guidance around this.

Right? So don't lose sight of that. Um now until then and how do we like start navigating this and try to make something productive out of it? Uh I would highly recommend thinking about like the idea that they are already productive. If we already have individuals that are doing well, the idea in my opinion is to try and stretch a little bit. Okay? So this doesn't work for every single person. And I say this because at some point some people become comfortable and some people legitimately have no interest in trying to stretch themselves further. There's nothing necessarily wrong with that. I I know that as software engineers, a lot of us are focused on career development, getting to the next level, um taking on more responsibilities, making more money, all this kind of stuff is very common. Um and I don't think there's anything wrong with that necessarily, but some people will reach a point and maybe it changes, you know, throughout their life where they're like, I'm just I'm doing good work.

I'm I'm comfortable where I'm at and I don't want even more responsibilities even if it comes with money. There's nothing necessarily wrong with that. I just think that it's not the thing we talk about a lot. And um I mentioned this in a few other videos, but there is the concept of terminal levels. So if you do have like a junior engineer that's like nah, like I'm just pretty good being junior and I'm going to be junior for like the rest of my career. That's not a terminal level. Like companies don't want someone to stay permanently junior in terms of skill level and responsibilities. Uh and even mid-level I would say is like generally not where companies want like a terminal level at because what they want to be able to do is invest into their employees to get them to be basically like a senior level.

Now I would say I don't have like stats on this but I would believe that many places treat something like a senior engineer as a terminal level um and above right so like at Microsoft my understanding is that something like the senior level could be terminal like not every senior engineer will get to principal engineer and there's nothing wrong with that and not every principal engineer so principal starts at level 65 not every principal engineer will get to 66 they could be at 65 the rest of their career and there's nothing wrong with that. So these are terminal levels in the sense that it is classified as okay to be at that level indefinitely right to have senior engineers that don't get to principal like you know for me as a manager I would love to be able to see that and help people grow

into that um and if people are interested I really want to make sure that I can do that but for some individuals if they're just like I don't want the extra responsibilities of that I would encourage them to, you know, to work towards that still. But at the same time, like I'm certainly not fighting people for it. I just yet have not come across a senior engineer that does not want to pursue that. But I have talked with people online. I've seen people talk about this separately from my direct conversations. I've interviewed people in podcasts for this kind of thing from their experiences. And there's absolutely people out there that are like, "Nope." even if offered a promotion. It's a very rare thing I feel like to hear about this, but people will turn down promotions, especially in different countries. I've heard this more where they're like, I'm just not interested in taking on more responsibility.

And that's how it is even if there's more money. So, um, bit of a tangent, but in this case, right, you have people that are doing well, and I would try to get you to think about how to stretch a little bit beyond their comfort zone. So, they're mid-level, they're pretty independent. Okay. Can we start getting them to maybe lead some projects? Something that maybe a senior engineer is able to do or you might trust a senior engineer to do more. One of the things that we have to consider is when it comes to promotions um we don't want to take chances on people as in we don't want to say hm this person is mid-level but like if we give them a senior title like I I bet right I bet that they could probably demonstrate that they could operate as a senior right

it's not about taking the chance and hoping and gambling that someone's going to do it it's about making sure that we have the data that shows they're already operating at this level. Sorry, I'm on a different highway than normal cuz I had to go to the to FedEx on the way in. Just my phone holder doesn't work. So, if you can help as a mentor providing some of these opportunities or encouraging the the mid-level engineers to try and take on these opportunities, again, work with their manager. Um, this isn't something where you want to have like a manager saying one thing and a mentor saying another and now you have confused employees, but it's like you should be trying to maybe give them a bit of a push in that direction, encouraging them, giving them the confidence they need, giving them the support they need when they go to tackle these projects, but trying to get them to stretch beyond their their current tasks.

And um I believe like personally I think that if you're working closely with them, you might even have a better understanding than their manager in terms of like how some of their technical skills are aligning with some of their domain knowledge and things like that. Um and then giving them a little bit of extra guidance around like, oh my god, that stop sign's not for us. Don't stop. We're on a highway. giving them some uh guidance around like um you know where they could be focusing more attention. So to give you an example, you know, you might have a manager that has a team uh focus on some different product or service areas and maybe the person that you're mentoring happens to have worked in one particular area of that of that project for a while, right? And they're they're mid-level like this person said, they're independent.

So that's all all goodness. And you might realize like, hey, like this person doesn't really seem to know this other area of the product well, but like it's a really important area. Like you might have more intimate knowledge of that because you've worked more closely with them on poll requests or uh side conversations about how different parts of the system work. Like you just might have different insights that their manager may not. And you may be able to kind of work with them to help them understand some of these things. And when I say that, I mean like understanding some of the gaps and saying like, "Hey, like you know, you've been working in area X for a while. Like you seem to be like pretty solid there. Like I think that it would help even more if you could learn area Y like to the same level." Or you might even say like maybe they have good breadth across the whole thing.

And you're like, I really think it would be valuable if you could double down in this like um this area from from our team's perspective needs a lot of improvement. And you are the subject matter expert here. like are there initiatives that you could maybe propose and like we could see if you can lead some of them here. We talked to the manager about that. But like these types of things where you're you're kind of giving them a little bit of guidance and planting some seeds in their mind. Um I personally think that this is like can be a really effective way to uh to start kind of pushing people in that direction. This highway is terrible. Oh, it's because it's taking me to Seattle. That's That's why. Damn it. Oh, I get off very soon at least. Okay, very good. Okay. typical typical Monday morning crappy drive-in.

So, meta point here being if you have people that are already kind of performing at a good level, um I think that it's helpful to work with them to explore different ideas to kind of stretch beyond their comfort zone. The thing about this is that it can be very very situational, right? You could take if we were to sit down, you as the viewer or listener and me, and then we were to say, "Cool, let's try this experiment um with, you know, pick someone on your team." And then I repeat this with someone else uh and someone else from their team, right? This every single time we do this, it could look wildly different. Is this the exit I want? I hope so. Yeah, looks like it. Um, and there like nothing wrong with that. It's just that um, we can't apply like a cookie cutter here.

This is why when I'm giving advice on something like this, it sounds pretty generic. I'm like, hey, you have a mid-level like, yeah, try to stretch them in terms of like the the things that they're focused on. Get them a little bit uncomfortable so that they can, you know, try new things out, prove their capabilities. Um, but like what does that mean in practice? It could could it could be a million things and it's going to be very different for everyone. So, man, this phone needs some brightness. What the hell is going on? Okay, there are cars way ahead of me, so not too concerned. So, You have to like even for for you as the viewer or listener like you need to keep that in mind too that if we take this person's scenario where they have two mid-level engineers and they're trying to

give them some some mentorship and guidance like they may have to treat both of those individuals completely differently even though they were described to be very similar on the surface. Right? two mid-level engineers, both operating pretty independently, like you know, they're doing well as mid-levels, and both don't have areas that they propose that they want to focus and improve on. You you could take your general systematic approach and apply it to both at a high level in the beginning, right? Okay. This guy on the internet said, "I want to see about building trust and respect with them." He also said that maybe I should uh work with them to try and identify areas that can like kind of stretch their abilities. Um that's very generic. You could like cookie cutter that to start with, but once you start getting into it, it's going to be very very different.

Um, being a mentor in this kind of setup can be uh, particularly challenging for a couple reasons because um, I kind of hinted at this earlier, but you don't want to put yourself in a position where you as the mentor are giving conflicting guidance to the person, right? uh you may feel that you're helping and truth be told you might be doing like you know the right things to help guide this person but if that ends up um going up against what their manager is saying ultimately this could could harm them in a sense that they're conflicted right like it unfortunately if you have a situation where you as the mentor are giving like better guidance like that's better fit for this person's career and all these other things better than the manager. It would be unfortunate, of course, because if that's against what the manager is saying, then like this person's ultimately going to feel conflicted and probably feel like they're stuck.

Uh probably not going to get good reviews from their manager because, you know, they're focused on different things. So, this can create a weird dynamic. And I think that it's I don't want to say it's easy to avoid, but I think there's some things that you can consider to try and avoid that. Um, and they're probably going to sound like super obvious. So, I don't know. Like, I don't want to say therefore there's no excuse for this to ever happen cuz I think that it happens a lot. I don't think that people ever intend for this to happen because it's all coming from a good place. But we just want to keep this stuff in mind. So, uh, one thing, it's probably obvious, I'll say it, like make sure that you are in sync with the manager, right? I'm assuming you're probably doing one-on ones with your manager.

I'm assuming it's the same manager in this case. So, when you are doing one-on- ons, like bring it up with your manager and like make that part of your your checking with them like, "Hey, you know, uh, here's stuff for my career development. You're focused on that in your one-on-one." And then I know you told me to to mentor Jimmy and Sally and like here's what this is looking like for Jimmy. We've been having conversations about this and Sally, we finally got to the point where Sally was saying that she really wants to focus on X because now that she's seeing that more, like she really wants to spend more time in uh this area of the product or the service. And so I've been encouraging them like X, Y, and Z. And talk to the manager about that. If they're like, "Oh man, like what the hell are you doing?" that then maybe you want want to have a conversation about that.

Um, but if they're like, "Yep, that totally makes sense. I've actually talked with Sally about this, too. She mentioned that you guys were talking through this and I can see that she's really excited." Like, have conversations about this, okay? Like, there's, in my opinion, there's no excuse to not be doing that, I guess, cuz you should. So, if you're like, I don't know what to talk about my one-on- ons, like this is one of those things, you could be talking about this. Um, and kind of letting the manager know how you are giving mentorship to the people on their team. It's a really good feedback loop when you hear their manager being able to say like, "Yes, like, you know, we've been having conversations about that, too." Um, I I have this kind of interaction with some of the principles on my team. Um I just to give you an example uh about this working in a completely different way but it's all about being in sync.

My my manager um used to manage the people on the on my team before I was brought in, right? So I was brought in to manage a portion of the people that he used to manage. So he still does one-on- ones with them at a less frequent cadence, but he still stays in touch with them and make sure that like things are all in sync. And there's absolutely conversations where I will hear from the employee like they were talking with my manager and like thinking about something and we got on the same page for it. Or the other way around where I'm talking with my employee and then when I'm doing a one-on-one with my manager, we kind of circle back on some of these things and it's like, "Oh yeah, we were talking with Jim Bob. I'm terrible with coming up with names on the spot." And uh they were saying, you know, that they're going to be planning to pick this up.

I think that's a really good fit. Or he might challenge me and say like, you know, what about someone else or is that a priority? Like these types of conversations come up. So the point is I think that you don't want to neglect having conversations with the manager uh for the people that you're mentoring. Not okay. Oh my god. Some people make driving quite dangerous because they uh they kind of didn't invent their own rules. For example, um just arbitrarily slowing down on the highway when there's no one in front of them. They're not signaling or anything, so you can't tell that they're trying to move over or whatever they're trying to do. They just slow down. So, what is there something you can't see? No, it's just that they're going slow, like breaking for nothing in front of them. I think they were trying to switch lanes, but that's why you probably want an indicator to let other people know that's what you're doing.

See, we can also learn about driving on code commute. Um but driving very very slow on a highway with no indicator or anything else is uh is unsafe. So don't do that. Um the other thing I wanted to say in terms of like avoiding like challenges or um conflict in terms of guidance is you can use the mentee also as a feedback channel. I kind of already just hinted at this at the last example I was giving, but not only when you're talking with the manager to to see like is there alignment this kind of thing. When you're talking with the individual, try you can draw out from them like hey like you know they might say my manager was saying I should be focused on this. This is where they really want to see me improving. like use that as feedback and guidance where you're like, "Okay, manager saying X, right?

This is what the manager is trying to get them to drive at. How do I? How do I build on top of that?" Cuz I think there's a huge opportunity that way. Um, you might be able to to help them kind of dig into like what is your manager actually trying to get you to do here? Like just as an example, um you could have someone saying, "Hey, my manager said uh they want me to go try and um you know, we have this feature we need to build out um new functionality in our product and they were saying that I should like that I should take on this ticket." And on the surface you might go, okay, like manager is just saying person has been assigned feature X. Okay, pretty simple, pretty straightforward. But then you might go, hm, feature X is actually like that's a pretty big feature.

That's going to require some architectural changes. That's going to require us going to figure out like A, B, and C because those are things we haven't really come up with answers for. And you might start piecing together like, "Oh manager's trying to get this person to do a little bit more than they're comfortable with, right? Like there's a reason why um it's not not always just because like, you know, next priority or randomly selecting people to go do work. It's like in my opinion, if you have good managers, they're trying to figure out like not only what is a priority, but what's a good alignment for people to be working on. So you might start going, hm, okay, I see a manager is trying to give this person something a little bit more challenging, a little bit more ambiguous, and want them to navigate it. So now, cool, you got to the level that you're at because you've built up these experiences, you've been able to deliver on them repeatedly, consistently.

So what worked well for you? Okay. So, you might say, "Oh, well, we need to do a design dock or like you should be talking with these product managers or actually did you know team X also has something similar to this? Maybe we should get you to talk to team X on this." Like you could be giving them you could start giving them guidance around ways that you've tried to solve these things in the past, right? not telling them exactly what to do necessarily, but giving them a push in the direction so that they're not going, I don't know what to do or based on your interactions with the person, building up the trust and respect and understanding of them, you might have uncovered that like maybe they have discomfort in going out and talking to other teams and you're like, man, this feature that they just got assigned is really going to require them to do that.

Okay. So, how do we start giving them some encouragement? How do we start giving them, you know, guidance around enabling them to do that effectively? Right. So, it's um there's a lot in my opinion, there's a lot of overlap with uh things that I think are my core responsibilities as a manager to be able to to help guide people and mentor them. And the the reality is though that yes, that's a formal part of my job description 100%. But that doesn't mean that like other people can't provide mentorship and guidance and help. In fact, like that's one of the things that I value most about other team members is the fact that they can do that. So I think that's probably all for this one. I hope that was helpful. And a friendly reminder for folks that this channel is driven by your questions that you submit.

So you can submit them below in the comments. They will be public that way. You can go to codecommute.com. You can submit your question via the email submission form there. Uh or you can reach out to devleader on any social media platform that you want. And as always, I do really appreciate if people share out the content on social media. So, if you found this really helpful, if you want to do me a favor, share it back on Experience Dev's subreddit. I think that would be tremendous. Sharing it anywhere is super helpful because um that helps other people discover the channel. And thank you so much for watching. See you next time.