Leading Peers as a Senior Engineer? Here's What Works

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the experienced dev subreddit and this one is about leading senior engineers when you are someone who is senior. Uh so the framing was essentially someone was describing that uh they're a senior engineer. here. I can't remember how many years of experience I have. Say it's around eight or so. And they've been the senior engineer on a team and they felt like pretty confident uh helping out the more junior people on the team. But that's been more of a natural thing because they are the more senior person on the team and that's worked pretty well. However, they're being moved onto a new team, which isn't a problem, per se, but that new team that they're going to be on has everyone else who's essentially like a a senior developer. Um, now I I don't think we have the exact breakdown, but their point is kind of like they're not really sure what to do and how to approach this because the reality is there are other senior people, right?

So very um sort of different composition of the team, which I think is a good observation. Um I think it's it's a good thing for someone to maybe pause and go, hey, wait, like this probably is going to be different, right? Uh better I think better than assuming, oh, it's going to be the exact same because I I think it's worth doing a bit of reflection on this kind of stuff. That's exactly why I think it'll be good to talk about today. Okay, so friendly reminder, if you have questions about software engineering, career development, that kind of stuff, leave them below in the comments or you can go to code.com and you can submit stuff anonymously that way and I'll make a video just like this one and then hopefully it's helpful for you and some other folks as well.

So, um I think I think there's maybe uh I want to start with like maybe some assumptions about what people uh think about like you know leading others or helping you know facilitate this kind of role. And I think a lot of the time when there's hesitation like this, it's like I feel like rightfully so, um, you know, if other people are more senior or in this case maybe, uh, it's not just that they're senior, it's literally they've been in this do this other domain for a long time, this person, while they're a senior engineer, they're supposed to become the team lead for them or the tech lead. They're brand new to that domain. So they're like, "Don't matter if I got 10 years of experience or whatever. I'm brand new in this area.

So how on earth am I going to do a good job like, you know, leading these other people?" And I think this assumption is that the expectation on you is almost like you have to you have to teach them or you have to know more than them, right? Like that's how it that's how it seems. And I've had conversations like this. uh maybe not the exact same thing but similar where it's like how how am I expected to do well if I am not um sort of the domain expert right I'm my title says X but in terms of the the area of expertise or the knowledge in this domain like I'm I'm I'm not there compared to other people. So I think uh I think it is an assumption. I think that it is I don't know. I feel like that's a totally fair way to feel about this kind of thing.

And I think a lot of the time that's rooted in the sense that uh if you if you've been if you feel like you've been successful at this in the past, it's probably because you are someone who has built up that subject matter expertise, right? You you're reflecting on times where you're like, when did I feel confident? When was I helping others? When was I teaching people things? like this is this is your lived experience of of doing that type of leadership, right? If we even use this person's example where they're saying, you know, on their team they felt successful doing this, like their previous team. Uh they're the most senior person on the team, everyone else is junior. Like that's gone pretty well. Yeah.

like you know you're again I'm making assumptions about this person's context but let's assume like you know they've been on the team for quite some time uh and they've been a senior on that team for quite some time they probably have a bunch of domain expertise specific to that domain plus like you know they've been a software engineer for a while right so like they're in a good spot where they're like I feel like I know my and not only do I know my but I feel like I know it well enough that I and help others to understand it and clear it up for them. And so if you think about the other people on the team, they are more junior. Um we're making assumptions about their domain expertise. Uh I don't even know what the domain is plus their software engineering expertise, but I would assume both are low.

So not only in this person's position do they have the opportunity to teach them about the domain, show them the ropes, help them learn things, but then they can also kind of help around you know software engineering things in general. So I think there's there's a lot of opportunity to be able to to kind of demonstrate these leadership traits um and facilitate that role really effectively in in their in their first example. Right? Again, I think people lean into this and they think about these lived examples and you know, I'm curious to if you have thoughts on this, if you want to put them in the comments or not, but if you are someone who's more senior, does that kind of line up with your experience where you're like, "Yep, like I've been able to help more junior people.

I've been on this team for a while or at least, you know, in this space for a while." So, not only is it your software engineering experience, but like also probably the domain So, I think a lot of this I'm going to call it insecurity because I can't think of a better word. Hesitation, insecurity, um imposttor syndrome like kicking in. I think a lot of that's rooted in I've been able to lean on these abilities that I'm thinking about in my past experience and I don't see how they're applicable here. So, that's that's the framing I'm coming at this with. Whether or not that's true, I don't know. But that's how I've uh thought about problems like this historically and how I'm applying it here. But this is why I started part of this conversation with saying I think it's good that they're stopping to think is this different?

Because I think it is different. I think that if you're going into a team where there's uh other seniors uh perhaps more senior as software engineers, but minimally they're more senior in the domain, right? I would make the argument even if they're not they have less experience as a software engineer they they definitely in this person's case know more about the domain right again I don't know what it is maybe it's I don't know Android apps iPhone apps maybe it's some stuff with databases maybe they're doing some low-level stuff in Rust I don't know right but odds are people on that team even if they are more junior probably know a lot more about the domain. So this person's like, "Holy how do I be effective at this?" But I think the big difference is that your your ways to be effective in such a role are not based on uh like teaching people like factual knowledge that you have.

And I think a lot of the time in the the former examples, you can lean on that a lot. You're like, I have these lived experiences. They are they are knowledge to you. You can share that knowledge. You can walk people through those experiences. Share that knowledge in a way that educates them and and helps helps them understand things the way that that you did. And like while that's not uh totally off the table here, it probably feels awkward a lot of the time because you're like, "Okay, so there's Bob on the team and Bob, you know, has more years of experience than me or the same plus really knows this domain. What on earth am I going to tell Bob that he probably doesn't already know?" Right? That maybe that domain knowledge I have from the previous team has nothing to do here. So I can't lean on that as a software engineer.

Yeah, sure. Maybe there's some some experiences I can share, but like the reason people often feel hesitant about this. Is there like or I'm again I'm making assumptions. I don't have stats on this, but I I think it's because they're going like like who am I to tell Bob who's also a senior software engineer or more senior like I'm going to you're not going to like lecture him about software engineering practices. like that's going to feel probably a little weird. And there's definitely some people that don't think this way and they're like, "Nope, I have the title. I'm going to I'm going to do it." You'll probably be met with resistance, just a heads up. But I think some people catch on to this and they're like, "That feels like not the right thing." So like, "What am I supposed to do?" So I think it's less about teaching people, right?

you probably been able to lean on that a lot because you have knowledge you can teach. Um, and hopefully you have effective ways at teaching, right? And I think that's less of the case now because you're in a position where there are people who have more expertise than you. You don't know the most in the room. You don't have the most experience in the room. But that's okay, right? because those people are probably probably not looking to you for that kind of thing. In fact, it's probably the opposite, right? It's probably why it feels super weird to some people where they're like, "How am I supposed to like, you know, teach these people stuff?" It's like they're not looking for that. They're smart people. They have experience. They have domain experience. They're they're probably well aware they have more domain experience in that area than you.

And it's not a problem. I mean, for some, you can correct me if I'm wrong here. I think for some people, they might be thrown off by that where they're like, "Oh man, who's this new person coming and they don't know anything about this space? How could they be helpful?" Right? I think some people probably feel that way, but I think it's like, I don't know, a misaligned expectation. I I don't think I don't think anyone in a leadership position that would instruct someone like, "Hey, we're moving you over here." I don't think they're doing that going like you don't know anything about this space, but like that's the message we're telling people is that you're you're about to teach them all. Like that's a that's a super weird expectation. So, it's not about teaching people things. It's not about showing them how it's done, right?

They're probably pretty effective. I mean, if they're asking you questions about that, I mean, then great. They're open to it. But uh I don't think that's what they're after. I don't think that's the expectation. So, how do you become helpful? And I think a lot of this has to do with like um like mediating things and unblocking people, right? There are smart people on the team. You you will find your spot because I this person didn't say manager. It sounds like they're still, you know, software engineer. So, still an individual contributor, but there's some some kind of leadership expectation in there. Sorry, I'm just reading the signs. It's saying the toll lanes are closed, which means I'm about to get trapped on this highway. Oh god, I have to drive into work today so I can get my days at the office in. It's a Friday and like there's literally nothing that I'm going to accomplish by going to work.

So now now I'm making this video and I'm going to get stuck in traffic paying money to be in the fast lane and not moving. Um, and it looks like the actual lane is closed. So, I can't see it, but a sign said it. So, yay. Yay for a return to office. So much so much value added. Um, in a role like this, people aren't expecting you to show up the same way. So, um, you're going to have situations where you people aren't agreeing on things, right? there's debates on design or implementation of things. Uh there's going to be people that aren't sure which direction to go forward. So it might not even be a debate with other people on the team. It might be like, "Hey, I'm kind of I'm feeling stuck here. Like I got three different options and like I'm weighing the pros and the cons." And honestly, like yes, there are pros and cons to all of them.

I can't make a a judgment call on this. Um, it's about showing up for those situations where people are uh not able to to progress on their own. I think that's like one of the the major things and that can and will look different ways depending on the scenario. Um, so people aren't looking to you necessarily to be like, you know, this person's the boss, they make all the decisions, but they hopefully can learn to trust you that, you know, when there are difficult decisions to be made, like, hey, like we want your input on it. And I think what's cool about this is that is not, in my opinion, that is not something that's measured by like how much you know. It's not a list of like there's going to be an accident. That's probably why the lane's all messed up. Looks like it's right here cuz this guy's slowing down.

But oh no, there's a construction sign. I don't know what's going on. Something up there, but it's going to wreak some havoc. Um, they're not looking to you for purely like factual knowledge. They're they they're turning to you because you have experience navigating things. And I think what's really cool is that you put this to the test if you don't believe me, but I suspect you probably possess some type, if you're this kind of person, you probably have some kind of ability to navigate challenging scenarios. And it's less about the uh you know, the factual things, you know, and more about your approach to things, right? So, in a situation where someone's I'm going to use the one where someone's like, "I got three different paths. I don't know which to take.

There's pros and cons." You actually don't need to tell the person the answer because you actually might not know the answer and you actually don't need to know all the details about it upfront because you can navigate that kind of conversation with saying, "Cool, like like walk me through the scenario. You have three different paths you can take. Okay, you said there were there are pros and cons to all these. Cool. So, like, let's let's walk through them and let's see why you're getting stuck on these. Like, why, you know, walk me through why this one, you know, this one says it has these three pros and only one con. Um, and this other one has two cons. Like, is that enough that like it should be opted out? And it's like, well, no, the answer is that pros and cons may have different weights to them.

Okay, so like talk like I'm learning this domain. Tell me about like why you weigh this thing more than the other. Right? You're talking about latency versus throughput on something. You're talking about delivery timelines as pros and cons. You're talking about um you know more iterations on the architecture and that's a con and it's like well hold on maybe let's talk about that. So there's more iterations required. Okay. Um so are those iterations actually uh working backwards right? Are are you doing a step to like later have to undo it? It's throwaway work. Oh, it's not. Okay. So there's more iteration. So, like what what's the bad part? It's just that it's more steps. Like could we could we look at turning those more steps into a pro, which is like maybe we can deliver part of this incrementally, get the feedback or the the metrics or whatever on it.

I don't know what we're building. Uh could we do something incrementally? And that's actually a pro now because we have the ability to ship in increments and not wait, you know, 6 months, 12 months to go build out whatever you're talking about. Like did we just transform something that was like, you know, we said said it's a con because there there's more steps, but like is that actually something that's going to help us? I just literally don't have an example. I'm making it off the top of my head. So, I think what's cool about these types of things is that you don't actually have to have all of the information up front. You can ask questions back. you can have the experts provide the information to you as best they can and then you can talk to them about it, right? Like tell me like tell me why this thing is is more important or less important.

Tell me why like we care about this. Tell me why customers care about this. Like teach me. So, as they're teaching you this information, which is completely ass backwards from your expectation, they're teaching you things, you're able to try and navigate the conversation based on the information they're providing. So, you can say like, you know, they're stuck. They're they already can't make a decision between these three paths. So, by them providing you more context, you can hopefully shift their perspective. And it's not about you being right. That's literally not the point at all. It's not about you being right. It's not about you knowing everything. It's actually about you helping unblock them. If you can get them to shift their perspective to understand things better based on I mean a lot of that's based on their own knowledge that they're sharing with you. This person's got to figure how to change lanes.

Come on. There you go. You can do it. Um you know like you're using the data from them, filtering it. And if you can help steer them in a direction like that's that's positive. You're unblocking the team. You're providing value that way. And it's a similar type of approach when you have multiple people that are debating something, right? It's just a matter of like, hey, look, we're talking about pros and cons and like we're not agreeing on the weight of those things, so let's talk about why. And often, like if you haven't been through this kind of thing before, often what happens is it's like if you have thing A and thing B, it's usually not exactly thing A or thing B that's the the best solution. It's somewhere in between. But you can help facilitate conversations like that where people aren't agreeing, right? And even in the worst case, right, like something that's important to mention is that that's really a happy path.

There's definitely situations where like people don't come to a final agreement. And like if your your role and expectation is to facilitate like, hey, that's that final agreement's got to come and that has to come from you, you need to be able to own that decision, right? If it's the wrong one and you find out 6 months from now because I don't know, uh there's more bugs or things are slowing like whatever it is, right? You don't go, "Oh yeah, I mean like that was technically Bob's design. Like I don't I didn't have anything to do with that." No. Like you were part of that. you influence the the decision and like take accountability, right? It's like showing up that way I think is going to be very helpful. There's a couple more things that I want to touch on without totally going down the rabbit hole.

I'm just trying to also pay attention to see when I have to move lanes here cuz this looks like a nightmare. I already moved a meeting with an employee by 30 minutes and like it's not even going to be enough because of this. Um, okay. So some other things I wanted to mention before I forget are like uh if you are doing this kind of transition I think one of the worst things that you can do is try to pretend like you know more than you do that will absolutely backfire. I think that one of the best things you can do is be very transparent about things that you don't know. Right? Your goal is to build trust with people because when there are going to be hard decisions to be made or people need to rely on you, they want to trust you.

So the worst thing that you could maybe not the worst, one of the worst things you could be doing is like trying to convince people that you know things are more about some area that you truly don't and coming across that way. Because not only like is that wrong, but the second part is like I guarantee you they can see through that, right? I'm I'm sure probably most people listening to this at some point have had an acquaintance of some sort try to talk to them about something that uh that other person is maybe not really an expert in. Um, and like you happen to be someone who knows a lot about it and you're sitting there going, "Uh-huh." Like I don't know, depending on how you react to it, it's for me a lot of the time it's like, "Oh god, like this is so awkward because I really want to tell this person like you got to stop talking.

Like I know you don't know what you're talking about." Um, you might approach it in different ways, but it's super awkward. And so people can often see right through this. And then how are you ever going to trust someone where you're like, you're literally just, you know, bullshitting me and hoping I believe it. So, don't do that. Um, it's okay to admit things that you don't know. In fact, one of the like I think something that really shows um like a level of maturity that's important here is like admitting you don't know something and then being curious to follow up to get the answer. It's not I don't know it and like I guess that's too bad. Whatever. That's awkward. It's like, oh, I don't know it. Cool. Like, who can I talk to about this or where can I read more about it cuz like I need to learn and understand it.

And what ends up happening over time is people people see from you when you don't know something, you don't know it and you're going to go find the answer. Like you're comfortable. You're not going to people about it. And that way it helps also reinforce that when you do know something, right? They're like, I know this is the kind of person that has to go research and learn about things and understand them before they will say that. So, it automatically helps add more trust and respect. Say automatically. I mean, that takes time, but I think you hopefully get what I mean. I don't know if there was I don't know how long I was planning to be in this car, to be honest. Uh, I wanted to I think if I can find a way to squeeze it in. I wanted to talk about um this kind of thing.

Oh god, how is this going to work? Give me one sec because the the lanes are like not marked anymore. God, what happened here? Oh man, pretty big accident. Oh, sorry to see that. Cool. Okay, I'm at the next exit, so there's still time to make it to my meeting. Just in time. Um, yeah. I think there's like one example I wanted to share. Uh, and I don't think he'll ever watch one of my videos. Not because not because he hates me, but I just don't think it's his thing. But, um, when I joined Microsoft, I I joined a team where like yes, as a manager, but also I think it's very relevant for this kind of conversation. Um, I joined as a principal engineer, engineering manager, sorry. and um in a domain that I know nothing about. So very much kind of like this. The difference is I didn't have a full team of like senior people.

Um that already seems kind of weird to me that I don't know why you don't have a team of a mix. But anyway, um so coming into this I'm like I'm brand new. I don't know anything about the domain. I did have some people like actually a bunch of the people on the team were a lot more junior. Some of them, you know, like first kind of job outside of college. Um, so okay, like to me, cool. There's already stuff I know I can help with like automatically because I've been doing this for a little while and like if you need help on I mean part of my role is career stuff as well. I can help with this. This is good. But I have a senior engineer on my team um who I guess in my mind I'm like obviously the domain stuff like I'm not going to know.

Um but in terms of like we were using C and stuff so I'm like in terms of like programming I'm like hey like at least I'm not going to say I'm better than him or he's better than me. I don't know but at least he he's someone that I could have helpful conversations with if we needed to talk about more technical things. Okay, not feeling so bad, but there's a principal engineer on the team and he's a higher level than me and he's been at Microsoft for a very very very long time. I'm not saying that to age him, that's not fair. Uh he's got a lot of experience at Microsoft. So much so um that he has also been an engineering manager years ago at Microsoft. So much so that he was a manager for some people that are a VP at Microsoft. He's got a lot of experience in the space and he's not only got a lot of experience in the space, he's been an engineer for a long time.

This guy definitely knows more than me. Uh I would assume is, let's just say, he's a better programmer than me. He knows more about the domain. He knows more about the company, everything. So, what the hell am I going to do to be helpful for this guy? Right? That's the feeling that I have going into this. Of course, that's why I was saying I think it's normal for people to kind of feel this way because you're like, man, like what what do I have to offer this person? I am not going to get stuck behind that truck. No thank you. Um, so like it's a it's a normal feeling, right? What what can I possibly offer? But all the things I was talking about are things that, you know, maybe not obviously to me at the time and going through it, but like these are things that I tried to practice, right?

I didn't come into it being like, oh, I know all about deployment in data centers. Like there's absolutely no way that I I can't lie about that stuff. I would feel so uncomfortable. So no, right? So what do I do? Like when I come into new things, I ask questions. I have to ask questions. I have to learn, right? So I need to do that. And so that's part of it. The other thing is like I wasn't going into this being like, "Oh, I'm going to teach this principal engineer like how to program." Like absolutely not. Um, so you do a lot less of like, what's a way to say this? You do a lot less of like the let me proactively do this for you. And a lot more of the like, let me listen to you. Let me understand what's going on for you.

Let me listen to you. Let me like let me create this space so that like when you need support that I can get you to trust me that I will figure out how to support you do the awesome that you're doing. And so I thought this guy did such a good job of this. Um maybe it's because he's been back and forth between like management and IC roles. Maybe it's because he's had a lot of experience in his career. Maybe it's just because he's also an awesome guy. But um he you know he didn't treat me like oh you're the manager e okay like let me make this hell for you. Nope. He like every opportunity he could he was trying to teach me things he was being very patient with me. Um he was someone that would like you know share like when he's working with people on the team he'd be like hey you know so and so is working on this.

I think they're doing a good job or this person might need more support. Like he can see what's going on and he knows that's going to be helpful for me. So he was doing such a good job like teaching me. And I think what I needed to show him is like that I can be accountable, right? So if he's giving me these opportunities and he's teaching me, I'm showing him I can be accountable. I will follow up on stuff. I will get done. And that way I can demonstrate to him like you can trust me. you can come to me with things so that when you are blocked or you do need support like you know that I will find a way to help and it's also uh you know reinforcing for him that like there's obviously tons of that I don't know and there

always will be but I'm demonstrating to him that even when there's that I don't know that you can rely on me to go try and figure it out that I will try to get things done and that you can hold me accountable to delivering on that. And so, um, I wanted to share this because like it, uh, I was very fortunate that I had someone that was, you know, receptive. He could have decided to do whatever he wanted and been like, "No, this guy, you know, I don't give a about this manager coming in." But he was he was awesome. He was very supportive for me and he made that part very easy for me. um as uncomfortable as it is to come into something and be like, "Oh man, like how am I going to be helpful here? How am I going to add value?" At least for you know, for this person.

Um yeah, he he made that a good experience. So just wanted to share that. And I don't know, maybe that's helpful to see that I'm not totally talking out of my ass here. Like these are things that I tried to practice that I put into play and I thought they were successful in the end. So, that's how I think I would approach that. I don't know if I have other thoughts to add on to that without going in more in circles, but yeah, it's not uh it's it's not going to be the same going into a team of seniors. And um and that's okay because you probably have some other superpowers that uh you might not have been aware of. It's not just that you know a bunch of things. It's like how you approach things and uh creating, you know, a space where people can rely and trust uh rely on you and trust you to to be accountable.

Right? So, I hope that helps. I'm going to turn right here and then try to turn off this camera. But a reminder, if you got questions about software engineering, career development, leave them below in the comments. Otherwise, codec.com, you can check the anonymous check box. You can leave it unchecked if you want to put your name. Uh, I will never say anyone's name unless they ask me to. Same with companies. I try to keep the companies out of it because it's not it's not relevant. Um, I might say like big tech or not kind of thing, but doesn't do me any good to to share that kind of stuff. I'd rather just try and be helpful in some way. So, thanks for watching. I hope to see you in the next one. Take care.