What's Expected of a Senior Engineer New to the Team?

Transcript is auto-generated and may contain errors.

Hey folks, I am just leaving the office on Wednesday. Um, we're going to go to our Reddit for a topic from experienced devs and um, this one is about what should be the expectations of a senior engineer that's joining a new team, which I thought would be a fun question to walk through. Um, this person wrote a whole bunch and I I you know, they gave some background and I like some of the things they were talking about. So, I don't know. Sometimes I feel like I read Reddit posts and I just expect to be like, "Oh man, like what is this person talking about?" Um, one of my employees. Um, sorry, one of my employees is walking into the parking lot. Um, yeah. So, that wasn't the case this time. And I don't know, it's kind of funny. I feel like I shouldn't be surprised, but I am surprised.

And I'm like, "Yeah, I kind of agree with this person." But I guess that's Reddit for you. So, um, just a friendly reminder before I get into this one. If you have questions that you want answered, leave them below in the comments. Or, oh, that's not how left turn lanes work, buddy. It's a left turn lane for me, not for you. If you aren't comfortable leaving a public question, you can send a message to dev leader on any social media channel you'd like or Nick Cantino on LinkedIn and I'm happy to try and answer your questions on software engineering and career development. Do my best. So this question is good because this is uh I don't know like probably you know if it's not the case for you yet it probably will be the case for you at some point in your career right odds

are if you're a software developer and you're not a senior software developer yet you will be getting there and odds are you know um I I don't have stats on it but I don't think that people stay in one team for their entire career. um some people me might but I don't think that's the common case. So I think it's good to kind of think about this and what that means and I've talked about this from the perspective of an engineering manager like when I join a team what are things I'm trying to do and I thought that it was pretty cool that this person like kind of talked about some of the same things which is uh which to me was like indicative that it's not like a role specific thing some of the things I like to focus on it's actually more of just like uh like these are the the right things to be thinking about.

And uh from the perspective of being in any type of leadership position, and I I mean that from the perspective of like not necessarily formally, right, as a senior software engineer, you're going to have people that look up to you on the team, right? So like you will be at least informally leading others. So I think these are good things to think about. So, I'm going to kind of go through what they said and see if I have any other thoughts. Uh, I tried to take a mental snapshot of what they said because I'm driving and I'm not going to read out on Reddit. But, one of the first things they said was to ask lots of questions. They said for the first one maybe to like up to 6 months kind of thing. You know, they're just saying no shame in that. And I like totally agree with this.

I think that um people confuse like like asking questions does not make you dumb or make you look dumb. And I think people I don't know like I think a lot of people think this way, right? That they'll be perceived as dumb if they're asking questions. And I think this probably comes from the fact that like, you know, if you're asking questions about things that other people find obvious, it it must like, you know, it must suggest then you you have no idea what you're talking about because you don't even know the the common sense things. But like it's just it's just not the case. Like especially if you're new to a team there, like you are expected to be asking questions. And like I'm trying to give I want to think of a good example here. Like I've been on my current team at Microsoft for just under a year and a half now.

And there's totally areas uh that are in my broader team or even within like my direct reports and stuff like the space that we have. There's stuff that I don't know and I I I need to ask questions and I I'm very transparent when I don't know things. Uh, I think that like you can build a lot of trust with just being transparent about that kind of stuff. And in fact, it's like the exact opposite thing happens when you're not right. Like I'm sure we all I got to get my sunglasses. Ah, I'm sure we all know people that we've encountered where they seem to act like they know lots of things, but they don't actually know lots of things. And That certainly doesn't build trust, right? You you once you kind of discover that about someone, you're like, I don't want to believe anything this person says, right?

Because like there if they come across confident about things and you end up discovering like they don't know the details or understand why or they're just flat out wrong, whatever it is, like the trust goes away. But I don't think I've ever encountered a scenario where someone was like just upfront being like, "Hey, I don't I don't know about this yet. Could you help explain it or tell me where I need to get more details?" Where you're like, "Oh, I trust them less less. Sorry, lest trust them lest uh words." Anyway, like it's, you know, it doesn't make you look dumb and if anything like you're avoiding situations where uh you can erode trust. Uh I think more often than not, it's really interesting when you have someone asking a question like in a chat or something like that or on a meeting. A lot of the time there are other people with the same question, right?

So, if you're like, "Oh, I don't know. Like, I don't want to bother people or whatever," like you're probably helping someone else by like asking that question. Um, I've talked about this before too where um, you know, even coming into something and asking questions like you you're trying to understand it, getting someone to explain it to you can sometimes like get them to think through something that they haven't thought through recently and they might go, "Oh, like what's a good example of this?" um you know asking I've asked people that are more senior on the team like hey like why do we you know do this thing this way can you explain that to me and they'll say like oh like once upon a time we had x y and z and like come to think of it like you know what maybe we should

revisit that now cuz like we don't have to worry about x y and z now we only have to worry about like a and b but those are covered and then it's like hm and you get their gears turning and that can lead to other conversations so there's There's like nothing there's no negatives for asking questions. I think where it becomes a problem is like if you are not learning from things or not trying to learn right it's okay like if you have to ask the same question because you forgot and like you were making an effort but it was complicated and you need a couple more iterations like that's not it's not what I'm saying. What I'm saying is like um if you're routinely like you know the you're asking the same questions over and over and it's like nothing's actually solidifying for you.

I think that's where people start to go you know what like they get kind of frustrated where they're like I don't want to keep answering the same question for someone. It's not hey you have more questions it's a problem. It's hey you have the same question over and over so why do I keep giving you that time? But I don't like statistically I think that's a pretty rare thing from what I've experienced personally. So coming into a team asking questions absolutely I love that. Um I think that's a yes please do it. I don't think that's a a senior engineer thing only. Like I said it applies to engineering managers. It applies to junior people. It applies to all levels. Ask questions. You need to learn about what's going on. Um, you know, with the current state of things, uh, the history behind some of this stuff, whether you need to go through code, the architecture, uh, use cases, right?

Like understanding how stakeholders fit in, ask questions. I I don't know. I've never joined a team where it's like, hey, or had people join the team where we expected you've done all this homework on your own and you must just understand everything now. Like it's just not the case. So do ask questions. I think that's a great one. Um be cur I want as I go through these I'm curious if people have like different experiences like did you have challenges asking questions? I felt that personally people that are remote seem to have more challenges asking questions. They feel like they're bothering other people. I have to yawn. I was holding that one in, man. Um it's free. But yeah, remote people especially I find um you know again anecdotally I don't have like a stats on this but it feels like statistically they do have there are more people that are working remote that I've worked with that have challenges asking questions.

They don't want to bother others. Um that kind of thing. They can't read the body language. So they're like, "Oh, I can't tell if I'm pissing this person off or they hate me because I'm asking questions." So then they start to not ask questions. But yeah, wonder what your experience is like. Would be interested to hear. I think I got another yawn. There it is. My goodness. Um, next thing they talked about, again, this one really lines up with uh my take as an engineering manager, but as a senior software engineer, they're like, I'm not coming in and trying to change things, right? Their goal is not to come in and disrupt. So, they I can't remember the exact wording, but they were talking about like doing more observation, trying to understand things before um, you know, making changes. And I really like this. Um, I've made a few videos recently.

So, if you're new, like maybe go back over the past few videos, uh, or if you've been here for a while watching them if you haven't seen the past few that I put out cuz you skipped ahead or something, which you wouldn't do. You got to watch them all, right? Um, I would go back and maybe check those out because it's been a bit of a theme where when you come into a team and you start disrupting uh without understanding things first, I think that disruption could be uh quite uh negatively impacting and it can come from a good place, right? Like I get it. Just I want to make up like a a contrived example, right? Like you might have a team that's operating. Say there's like five people on a team and like it things are going okay to good, right? Like everything's decent.

And maybe the engineering manager is like, man, like we got to we got to get the team to the next level and I got to bring in a senior software engineer. This is kind of like literally the same type of example that's come up in the past couple videos. So, okay, you want to bring in a senior software engineer as the manager and your goal in your mind is like we're going to, you know, we're going to bring this person in and they're going to they're going to change things and make them even better. And like that person comes in, they are given some type of indication like, hey, you're here to like you're the senior. You're gonna you're going to drive change. So they go, okay, sounds sounds good, I guess. And then they start changing things. And then what happens is everything backfires. Everything that they're trying to change just goes to And it's not because they suck.

It's not because they were being malicious, but what happens is that you're disrupting the flow of things. And likely a lot of the time, it's like people aren't bought into the change. People resist change, especially if they're not part of the change. It doesn't matter if the change is actually supposed to be a positive thing and like technically is supposed to address the root of an issue. Often times it will backfire if you don't have other people part of creating that change. And I'm not saying that like it's a rule, it can never work. I'm just saying like from my experience, this stuff backfires. And then you have a manager that's confused or like why isn't why aren't things improving? You have a team that's pissed off. And then you have someone that you've brought in giving them instruction and they're not being successful in their role because you didn't set them up for success.

You thought you were as a manager and I have seen this happen. I personally have not been brought into a team where the manager was like, "Look, you got to you got to turn this ship around." And then I like I'm like, "Okay." And like try to like go change everything. Um, fortunately that's not happened to me cuz I think I would I would hate that. And if I was brought into that, like let's say let's just make up a scenario. Say my next role, I know I'm an engineering manager, so shifting gears a little bit, but next role I'm brought in and the manager is like, "Look, you got to turn this team around. Like there's a lot of problems." Like if that was the instruction I was given, then the first thing I would be doing is still trying to go work with

people to understand what's up and then working with them to go drive the change because I know if I just sit back and I tell people here's how it's going to be, it's not going to be good. So as a senior software engineer, I do think it's important to not c come in and just like start causing disruption. You need to take some time to understand what's going on, understand how things have been working, and then find the way to get people bought in. And if you have better ideas, if you're like, I want to suggest change, whether that's about the architecture, the software development life cycle, whatever it happens to be, how you guys are testing things, like do you even have automation, um, you know, CI/CD, like whatever you guys have set up, you might start having opinions that you want to propose because you're like, "Oh, I see how things are going now." And like do it at that point.

There's nothing wrong with it. But when you come in and you're like first thing we're doing like we're switching the testing framework and people are like what are you talking about man like we have a testing framework like why what why are we changing it like don't come in to just disrupt you can come in with all the best intentions of that and in my stupid example of a testing framework you might be suggesting the objectively better testing framework and people will still be like wanting to resist. So your goal is that you need to have the team bought into change. It doesn't mean everyone there's like no matter what any decision there's always going to be some people that don't necessarily they aren't fully on board. But when you have people on the team agreeing with you and you've done a good job like demonstrating that value, then at least you're not like, you know, at odds with the whole team and causing chaos, right?

I I think that's a good word to use is like you might be interested in driving positive change, but you don't want it to be chaos for people. This guy's a a low boy. There's also a a police officer behind me. I wonder what they'll say. Maybe nothing. Play it cool. Okay. Live to see another day. But yeah, honestly I think the it sucks because I've seen people come in um where I know the the manager has brought them in with a with a plan to be like we're going to change things and that person or people they're brought in being instructed like this is what you're going to do. So, I would, you know, if you're someone who's being brought in like this, I would recommend that you like number one, you know, clarify this with the hiring manager. Make sure that you're understanding things from their perspective.

I would highly recommend trying to partner with the people on the team. Okay? Try to get their buy in. try to understand their perspective on things. I want to give you another example, but I don't have like a a real life one that's coming to mind, but there's I've seen situations, so I'm going to generalize it. I've seen situations where you might have a team that's been struggling with something maybe um I'm just again making stuff up. They're struggling because they don't have a like build infrastructure. Okay. And you have people on the team that have been trying, they've been trying to put in time and effort into getting that going or you have um you know test infrastructure that's not there and you have people on the team that have been trying. The the example I want to keep iterating on is like is the point that people have been trying.

They've been making an effort and trying but they don't have enough time for it or or something else is keeping them from being successful. Then what happens is someone is brought in. It's you. You're the senior software engineer and now someone is your your hiring manager is tasked you like you're going to be the person who gets that build system up and running. So then you go do it like mostly in isolation because this was your task and then you get people on the team that are like, man, what the hell? Like I was trying so hard to make that happen and then what? Like this person that just joined you in this case just goes and does that like you know what I mean? Like they start they start resenting you from the beginning.

Now that's maybe it sounds like a bit contrived but um I've seen this type of thing happen where people were trying now where just again for context if you're like well what do you mean how does this happen how do you observe it when I was working at a startup before Microsoft I was a engineering manager but I was also writing code and I was there since basically the beginning right so I got to see a lot of situations and be basically on the front line with people building stuff while managing and got to see these situations where people were trying their best to get something done or they really wanted to they wanted that opportunity and it wasn't given to them because like no you have to go focus on some other thing and they're like okay but like you know keep telling my

manager I'd really like to work on X but no then they hire someone else in and you're like you know get I get to see all these people that get demotivated by that and um what I'm trying to say is that if you come in and you're being told like this is your charter um there's an opportunity there where even if you are going to own it and someone else was interested they might have a lot of thoughts on it right you might still be the person that's got to go do it because that was the charter you're given but uh there's this opportunity where you could partner with them, you could hear from them, you could say like, "Hey, I got to carry this workout, but like, you know, let me put you on the design docs. Let me make sure I'm capturing your feedback.

Let me make sure that I'm understanding the different things you've considered. Partner with them." Right? So, this whole point is about um is not coming in to cause chaos. And I realize that's probably not the intention of people is to come in and cause chaos, but I'm trying to give you some different perspectives on like how chaos may result. So something to keep in mind. I think the third person this third thing this person said, gosh, very slow. Um, the third thing this person said was around um, or maybe it was a comment. I I can't necessarily remember what they said, but one of the things I wanted to talk about was like ownership. So, as a senior software engineer, I think there is this expectation like you are going to be taking accountability, you are going to be taking ownership of things.

So what I mean by like or what I would expect is like again you're coming into the team it's not like okay I'm going to stir the pot and like change everything but if you're observing challenges like hey like let's start talking about these things let's raise awareness um let me you know discuss with the team get different perspectives on this I'm trying to think through some concrete examples like I keep going back to like you join the team and there's no tests Okay. Hm. You're observing this. You're going, I think this is maybe a problem. I want to talk with the team about it. Learn. Now, you know, you could take initiative and be like, hey, I've kind of surveyed the team. People agree this is a thing we want to do. It seems like we don't have capacity. Like, hey, this, you know, let me raise awareness.

This could be a thing that I try to I can drive on behalf of the team, right? So, you do start causing change, but you're going to own that. And the difference here is that you didn't just like in isolation go, I don't see any tests like guess I'll do it or I'll show them the best way to do it, right? You partnered with people on the team to get their feedback and stuff, but take ownership. Be proactive on things. You don't join the team as a senior software engineer and just like sit there and like say you're remote, you just kind of like wait for someone to give you work. No, you're a senior. You might need help because you're new to the team and you have to ask questions and stuff, but like you're senior. Like you know that you should have some work on your plate.

So, okay, like what's the first area that you should be prioritizing? Like you should get that sorted out with your your engineering manager. They might say work with the product manager or whatever depending on how the team's all set up, but like you need to be proactive. If you're just sitting there waiting for work to show up, like that's probably not how you got to senior in the first place. So being proactive, I think taking ownership is really important. I think what this person said was not stepping on other people's toes, which is kind of what I was hinting at in the another not stepping on people's toes was kind of related to the last point I made. Um, but I you could say it another way too, which is like yes, it's important to be proactive. Yes, it's important to take ownership. But like if someone else is already owning something like don't like don't take it from them kind of thing.

What is going on up here? This van is off the road. Interesting. Um, so yeah, I think like that's, you know, you're new to the team, but if you reflect on your your career journey, it's very unlikely that you magically got to print or to senior just by being idle and waiting for work to fall in your lap. So, do show some initiative that way. And you might not you might not know the first thing to start on, but like you're not just waiting for it to be handed to you, right? Or you're going to have to learn parts of the system. Cool. Like start asking around who the subject matter expert is, asking if you can get some time for them. Go ask questions to them, right? Be proactive about trying to make sure that you can be effective because it's a weird balance, right?

You're a senior software engineer. You have been senior in not only software development in general but you are likely senior in a domain as well like you had domain experience somewhere maybe multiple times right depending on how many companies and stuff or teams you've been on just you know super quick example what I mean by that is like I I've worked in digital forensics in a particular you know code base and product base and built a lot of it So like if I if I went back to that company obviously it's been years but you know I had built up very senior level experience in that space. I was on a deployment team at Microsoft. So in in a deployment space I I come with domain knowledge. Okay. Now I'm on a routing team. In that space I have some domain knowledge. I'm not starting from zero.

You you have the same thing as a senior software engineer from wherever you were. If you're going into a new domain, even if it's the same domain, you might still have like things to ramp up on, especially if it's like proprietary tech. But the point is that if you're brand new to an area, your software development skills can be at senior, but you're going to be a beginner in the domain, and that's totally cool. So what you need to be able to do is think about those senior level skills that you had and how they helped you. Things like being proactive, things like being able to um break down ambiguous problems to be able to understand them, debugging ambiguous things, right? um you have to lean into those which are general software engineering things and then understand that your domain knowledge is starting from a beginner level.

Now the more domains that you navigate and the more times you do this, the more ways that you find for yourself to be effective at ramping up. So to give you an example, if you you had a career for 20 years and you only ever worked in the same spot for 20 years, you might know that that domain like crazy well, which is great. But if you haven't, it's going to sound weird. If you haven't practiced like ramping up in other domains, that might not be a skill you have, which then means it's really hard because you might just be like expecting that you're going to be good at something or understand it really well and you're not. So, there's this this element of like being comfortable not knowing things and being like, cool, like what's an effective way for me to learn this information? But I think that might be it.

I'm going to get stuck in traffic here even longer. So, um, I'll I'll wrap her up and I'm curious to hear from folks, right? If you are a senior software engineer or if you're not, that's cool, too. you know, how did you like when you switched teams, maybe it was a different company or maybe just a different team, like what did you like what what were your things to follow to be successful? What worked really well for you? Or if you're comfortable sharing, did you have a misstep, right? Like were you given a charter when you joined and you're and it didn't work out or there's a lot of friction, right? Would love to hear either side of this. And again, I like reminding people that sharing your experiences if you're very if you're comfortable doing it's very helpful because I just gave you some different perspectives, but I'm only one person, right?

There's plenty of viewers that watch Code Commute and um they have lots of awesome experiences to share even if you're you're new, right? Like sharing your experience is still helpful. So, want to say thanks for watching and yeah, if you're comfortable sharing, please do so in the comments. I will see you next time. Take care.