Onboarding at the Staff+ Level: What You Need to Know

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experience dev subreddit and this one's on boarding as a new sort of like staff plus um role on a team. So context is someone is uh switching teams or switching companies um and they are sort of operating at the staff plus level and when they onboard to this new team they're wondering like what what recommendations do people have in terms of doing this? They listed off a couple things and I think uh they're like their post is pretty short and the couple things they listed I think are already like pretty top of mind for things that I would consider. So um again starting things off here if you're new to my channel I you know talk about things from my perspective. I don't mean to, you know, make them sound like there's only one right or wrong way to do things, but uh this is just from my lived experience.

And I always invite people that, you know, if you have different opinions or if they're the same and you want to add some context or whatever, uh feel free to jump in the comments, let others know. I'm happy to learn from you as well. So, um, one of the first things that they call out that I absolutely agree with is like spending, uh, the first little bit of time listening. Um, I have lived through even like with, uh, you know, leaders coming in, new managers, directors, VPs, they come in and immediately try starting to change things. Um sure like you know people end up following but uh there is often uh you know people trying to fix problems that aren't actually problems and then just creating new problems. And so I think that it's critical that people spend the first um bit of time listening trying to understand what's going on around them.

Um, I think this is important because it gives you an opportunity to to actually learn, um, to be hearing it from people you're working with, to observe it, to get a to actually, I don't know, like truly understand the landscape around you. Um there's this thing we do as software engineers right where we take our lived experiences and we say you know okay well in my previous life at the previous company I was at or you know two companies ago or whatever we did thing uh this way and it worked. So like therefore we have to do that thing here. And in some cases that might make sense and you have evidence that it works, right? And in other cases like it just might not be the right move and until you take the time to actually listen and understand what's going on. Like you may not be making a good decision uh for the the situation.

And I think that sometimes it's easy to rush into, oh, like these people don't do it the way that I've seen, so like I'll show them. Uh, and it's not from a place of uh, you know, ill intent. It's not malicious. People do this to try and help, but uh, a lot of the time it's like you're you're jumping in to fix a problem that is not the right problem to to start with. So, I think listening is key. I think not only is listening key for uh having a better understanding of like what needs to be tackled first and maybe how you approach tackling that, but I think listening is key because um it's going to afford you this opportunity to actually build up relationships. And I think that's really important, too. Especially in like a staff plus position, you're going to have to get people bought into what's going on.

And um I think that if you get in and start taking action before people um have you know built up some trust and respect with you then it makes things more challenging. Like I often say that, you know, just because your your title says one thing, like that might um you know, implicitly get people to to listen to you or to have I don't know. Um, it's almost like trust is the wrong word to use here because I want to say like trust is always something you're going to have to earn regardless of your title because even if implicitly and even if people implicitly want to give you trust because of a title, um, it will erode rapidly if uh, if they learn like that they they feel like they can't trust you or can't rely on you. And I got to plug this thing in cuz it's going to die.

Hopefully that doesn't screw up the audio. Um, I've seen with audio setups in my car, things being miked, if this video goes all screwy with the sound, I'm so sorry. Um, well, let me get this back on. Um, yeah. So, I think like listening is such a critical thing to do in the beginning uh for for those reasons. And I'm sure there's there's more that could be thought of. The thing that can be challenging, right, is like if you're brought in as a, you know, person at this kind of level, the reality might be that sort of the guidance you're given from who is hiring you. Oh, pardon me. So, sorry about that. Um, sneaky sneeze. I felt that coming out of nowhere. Um, but the guidance that you're given from who is hiring you, right, your new manager. Um, I have seen this be a little bit in conflict maybe with what the rest of the team perceives, right?

Like I've lived through this to know that people have been brought in that are skilled and like probably uh would have a really good smooth onboarding. But like it starts off a little rocky because of of what's uh sort of maybe been prescribed to them is like their first tasks or or how they're set up. And to to explain this more, like if you think about what I was just saying and then you imagine a situation where someone hires you and they're saying they're not saying to listen first, they're saying this needs to get fixed, right? If you jump in to start fixing things, man, this guy's got to figure out his life. Sorry, this truck is real stupid. This guy was trying to switch lanes um but slowing down to switch lanes instead of like trying to get into the open spot. So um we'll go around him.

The tricky part in a situation like that is that your sort of your manager is giving you what I would say are probably conflicting priorities, right? Like they're giving you a goal, which is like, hey, the current maybe the current setup of this team like we really have to think our our our tech like our tech stacks really slowing us down or we have a legacy uh platform that has to be modernized or whatever. like you're given some goal and the sort of how you start approaching that goal. Um the way that the manager is like setting you up makes it seem like they're looking for immediate action, right? Set another way, it's like we're hiring you to save this. And so if you're supposed to be saving something and you're not taking immediate action on it, like what are you doing, right? But um but the reality is uh I think that getting in there to to listen first is is critical.

So the lived experience I have is actually at a a startup and uh as we were scaling up um I I feel that our VP at the time was a little bit disconnected on what the teams actually needed. Um, so what he was doing was hiring in uh, you know, people with a lot more industry experience, which I don't think is necessarily a bad thing at all, but he was bringing in people that, um, so I think there were three hires that he made it around one time. And um so people with you know a lot more experience compared to most of the engineers that we had cuz most of us were pretty early in our careers. We had uh you know at least one guy who had been around for for longer than the rest of us and most of us were pretty early in our careers.

few people that were, you know, a handful of years in. Certainly for me, like I was I was very fresh and so VPs hiring in um some people that have uh a lot more years of experience, which again on the surface seems like a it seems great, right? And then furthermore was like, well, we want um like we're exploring architect roles and like we don't have architects. So again, like does that seem like a bad move? like no, not necessarily, but like well what do we what do we need architects for, right? Like what what what are they going to be accomplishing? What is their um the goal of this role that we bring in? And it's like, well, we need like if you were to ask me, especially at that time, it would be, well, okay, well, we want to make sure that we're setting up direction for for the things we're building so that there is alignment because as we're bringing on new people, the reality is like this is a startup.

It's scaling. We're we're turning like a small product into a bigger platform. So I would imagine that having some, you know, technical alignment across these different areas as it grows would be helpful. So I would kind of imagine an architect does some stuff like that. And so basically I think it gets a little bit misconstrued and I think that's again I think it's a just sort of a a lack of understanding of like where the challenges are. So these architects get brought in and they're kind of given a specific task that that isn't yet a real problem and then sort of mandated to go deliver on it. And um I can tell you like super like super smart guys, right? Lots of experience and to me it felt like absolute hell. And I don't mean that from a personal standpoint like they were mean to me or something.

I mean the amount of friction and the amount of that this caused was insane. Was absolutely insane. And like I I mean this respectfully because these guys were good. The problem was that they were given a specific mandate that was just simply like not congruent with the rest of the actual engineering teams. So they were basically forced into a position where there was no choice but to have friction, right? And the reality is the VP who brought them in I don't think fully understood what what like actually needed to be solved. So had given them some type of mandate that was ultimately going to result in friction and I think like set them up for a really rocky start because I would have loved if they were brought in and people were like hell yeah like we want to be you know we want to be aligned with you know having you know common direction across you know product we're building but I I feel like it was just an outrageous amount of friction.

And I think that's because these guys came in and it was like start doing, not listen and understand first, right? One of these guys I haven't talked to in ages just because I think that I don't know it ended up going different kind of career path and stuff. Another guy uh like we worked for for many more years together. Um, and like I I feel comfortable saying these things because like I I could imagine if I were to call him up right now, I don't have his phone number, but I could imagine if I called him up and I said, "Hey, do you remember what that was like?" I feel very confident he would echo a lot of what I'm saying. And so that's not, you know, um, a jab at him or or the other architect. It's really just like I think the setup was like not not done well.

And that's also not a jab at the VP. I think that he was doing the best he could. He was probably given some type of mandate that was like, you know, bring on uh people with more experience and like set them up in a in this direction and maybe just took it a little bit too specifically and I just personally in like in hindsight I'm like I just don't think that was the right move. Um so I think listening in the beginning is critical, right? So, I would recommend someone joining a team like this, take the time to set up uh one-on- ones with people on the team, learn about the areas that they're working in. Um, you know, get to know especially the senior people on the team that have that have more tenure there. Uh, try to understand where like where are the challenges, right?

Like if we're talking about code and architecture, where are the dragons, right? Where is all the listen to what they have to say because they've been around for a while in that code base to be able to tell you like this is the kind of we have to deal with and like we haven't had time to address this tech debt or this is where we're paying lots of maintenance costs like if you listen they will tell you and then you don't have to go invent problems that don't exist to go solve right um so I would highly recommend doing that Um I think that when you can like when you are starting to like lead some initiatives like get them brought on early like partner with them. So not only do you go from a position of like I'm going to come into this team and start with listening actively not not just uh performative but like listening to what people have to say so you can understand build trust and respect as well.

um that when you actually start taking on initiatives to lead uh that this isn't something where you know you're like cool I listened I did what Nick said now I lock myself in a room for a week um write up 10 design documents and then go tell the team like go build this stuff I'm the architect right or I'm the I'm the the highest uh ranking software engineer so do what I say right like you have to you have to listen to my designs uh I would say I obviously I'm exaggerating to to make a point here, but um don't do that. I think that I think that you're going to want to bring other people in. Uh and this is for a couple of reasons, right? One is that I think that this also helps build trust and respect, right? People don't feel like they're being uh sidelined, which I think is important.

Uh you you may not agree with that. you might say like too bad like I was brought in to do this stuff and that's my role. Um but I would say I think that's a big factor personally and I think the other thing is too that like I think that um like put your ego aside for a moment and just because you might be someone who has a higher level role than someone else on the team doesn't mean that you don't have things to learn from them. um if they've been on the team for a little bit and they understand some of the the tech more specifically because they've been on that team doesn't mean that they have more experience in the area generically than you, right? Maybe you've been building software similar to this for a decade or two, right?

Um you might say, "Well, I have way more experience than this person." And I would say, "They probably have way more experience on this specific thing than you do." So, kind of like, "Shut up. listen and uh when it's time partner with them so that you can make sure that your like your design uh your project that you're leading is not just a mess because you you missed on some simple things that they they could have helped you with right so bring people along and I think that will make a tremendous uh impact from the start right so a lot of what I'm saying if it's not obvious is like uh you know listen and partner with people. Uh and I would I would say if like if you're being brought into something and and the the mandate you're given is like drive change immediately. Um one to me that sounds like a recipe for disaster uh for a manager even if shit's on fire.

Like I don't know, man. Like I would say if you're coming in and there's like you know there's an intern or like the dev team is so small that it's like and so new that everyone else is just getting started as well. I would say like my approach I wouldn't change much except maybe a time horizon for it. So like I would follow the same types of things. But um yeah, I I don't know like I just wouldn't go in and start stirring the pot. I would maybe try to to push back a little bit and say, "Hey, like I understand, you know, get clarity on the goal or the task that you're assigned with." And uh and make a point to say like I want to make sure that in my first, you know, x weeks that I am doing more listening and here's why.

Right? Those are my thoughts though primarily. I know a lot of uh focus on listening but uh I hope I hope that makes sense why and I wanted to share that like you know even people with really good intentions I think that you can be set up poorly uh by trying to drive action too soon without collaborating. So yeah, thanks for listening. If you got questions about software engineering career stuff, leave them below in the comments. Otherwise, go to code.com and I'm happy to try and make a video response to help you out with my perspective and hopefully that helps someone else as well. So, take care and I'll see you in the next one.