SEND HELP! My Previous Dev Team Won't Leave Me Alone!!

SEND HELP! My Previous Dev Team Won't Leave Me Alone!!

• 542 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware developerssoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinovlogging lifeengineering managermanagerleadershipmsftcareer coachingcareer coachpersonal developmentteam switchswitching teamsdevelopment teams

Jumping over to Reddit for this one! How can we navigate situations where we switch teams and the previous team keeps hounding us?

Is this preventable? Let's see!

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

what is up it is Friday December 13th I got a silly Christmas hat for a Christmas thing at work um driving into work pretty late um I've done a bunch of meetings already today uh but I'm just waiting for this little holiday get together thing so we got a topic my voice is still kind of crap so I apologize um we're going to be looking at Reddit again so topic for today is handling constant requests for help from previous team and this is something I have a ton of experience in especially early in my career uh less so at Microsoft in the past few years but something that I had to navigate a lot so the person goes on to say I recently transferred internally to another team and in the past few weeks I've been pinged nearly a dozen times by my old team

for helping fix issues with the old system do not mind helping out a little but the volume of SOS messages I'm getting is unsustainable is now I'm in a roll with more work uh there's a little bit more in the post we're going to leave it there because I think there's enough to talk about already um I got to get gas so this one I will have to trim very briefly I don't really edit these at all except if I just have to cut out me getting gas so that you're not sitting here waiting for nothing um I'm still way too awkward to like take the camera out and like pump gas and film myself like an absolute idiot so um we'll skip that I'll trim it out for you and a quick reminder before I get into the content if you want stuff answered

specifically uh go ahead and leave a comment below I'm happy to answer things and um if you want something answered anonymously and you want to provide more detail just look for Dev leader on social media any platform you want whether that's Facebook Instagram X LinkedIn uh between I would say like between Twitter X whatever and linkedin's probably the best I have a premium account on LinkedIn so you should be able to just send me messages if you look for for me um you look for Nick centino on LinkedIn um yeah totally Anonymous if you want me to talk about stuff uh I've had a couple people send stuff in offer a lot of detail which is great um I have no reason to like expose your name and the stuff you want to talk about it doesn't matter to me um I'd rather just help

you if I can so the more context the better I can answer things but let's dive into this so definitely a tricky situation um and sorry if I'm going to be coughing a little bit um but it's a tricky situation because usually when you're experiencing this kind of thing like you're trying to move on to something else right like uh hopefully for this individual and if you're experiencing this for you it's like you have this nice opportunity that's come up you're like okay like let me move on from this thing that I've been doing not to say that it's been bad or whatever else but you have a new hopefully better opportunity which is great but then as this you know individual is expressing in their in their post like it's not just uh not just Sunshine because it's like I got a lot of

lot of work to do people are trying to cross the road but they're they don't realize they have the right of way and they're just waiting kind of weird um like you have a lot of work to do in your new role ramping up and stuff and it's not like like it's seemingly not like the old work stopped right so couple things that we can look at here one I want to talk about um if you're ahead of this right so if you're already in the situation we'll talk about that I'd like to talk about some preventative things before this happens either early on uh sort of just in time or right before it happens and then we'll talk about sort of the uh after part so you have trans like you're in this person's situation you have transition what could we start to do

um okay so let's start from the beginning right and this is something that it's easier said than done it's way easier to talk about with hindsight um because when you're in the flow of things and everything's moving fast and you got a ton of to do I get it um we're focused on building stuff we're trying to ship the best software we can this person doesn't realize I have an advanced screen very very silly there you go good job wake up and um we're in this mode where we're just non-stop going usually right so it's very easy to to neglect some of these other things that we're going to be talking about and the first is like this idea that like the stuff that we're building stuff that we're working on and building like we have to understand that the the people working on things

do not have the same lifetime that the the project or the product or the service like these things have different lifetimes so you might have a team that stays together on a product project whatever it happens to be and they stay together long enough where that project ends up getting Sunset and they're already working together on something else right their lifetime together as a team has exceeded that of the product you could have the opposite where the product lives on for a long time and the team is changing right you might have none of the original members after you know a year two years three years whatever it happens to be um you know things are constantly evolving with the team and the product is growing but it's still staying around um and then obviously you could have like a combination of all the above

I'm getting out of the way of that jeez big truck um where you know the the product is going to be around for a long time and the team is changing and eventually it gets Sunset and like maybe one person's been around since the beginning of it and they're kind of sticking around for the next wave of things to be built like these things have different lifetimes and I think something that's easy to forget is that because it's like it's just not top of mind for anyone right it feels like rightfully so is how is it going to be possible that any person can come on and be as effective as possible in this space ideally my opinion is like I've talked about this before documentation for me is like a it's definitely hit and miss with a lot more Miss I love the idea

but in practice it just feels like a huge pain in the ass and it feels like a pain in the ass because we want it it seems like the thing that's going to solve the problem but it's always out of date and it seems like to keep it up to date is a ton of work especially if things are moving fast okay so I'm not don't take this the wrong way I'm not saying documentation is bad never do it it's useless I want to love it I want to do it but in practice I find it's very challenging to get very useful documentation that is up to date with low effort to maintain it um something I really like is when the documentation is almost like sort of like living with the experts on the team and I think there's a really good hybrid approach

here um I don't think like nearly it's really rare that I take a stance where like I would say like is an extreme thing in software engineering or anything because I generally find that there's value if you have a spectrum of things there's value on both sides so if you're going to the extreme of one and you're missing out on value of some other part of the other side um so I like the idea of having everyone on the team have uh you know subject matter expertise maybe in a deeper area of the product or the service and and enough understanding that they should be able to ramp up anyone on the team to be effective and the reason I like I don't know I like this because to me it seems like there's I've had a lot of success with teams where people can

sit down together whether that's on a call or in person get people up to speed right pair up with them for a bit maybe it takes a week or something to kind of go through stuff uh maybe it's a day depending on what it is right and people can get up to speed and they're good to go but don't get me wrong there's going to be like tons of little details and stuff or like really nuanced things where people are like ah man I remember getting stuck on this but I don't remember what we did like there's a good example of where documentation is valuable so my point with mentioning all this kind of stuff is like if we're if we can if you can press pause right now and you can think about the team you're working on what types of things are being

done to make sure that if you needed to swap half your team out I'm just making up an example you got to swap half your team out and you're going to replace them with that half with new people how are you going like how would you do it effectively and I realize it's a very contrived situation but like what do what does your documentation look like what does your onboarding look like um is your codebase so convoluted that like it's going to be ridiculous effort is your the way that you guys have plan stuff in terms of like your Milestones coming up is that all over the place is anyone even talking about that you know just the the team processes if there are any is any of this mature I think these are things to to evaluate periodically and if you're a software engineer

I'm not necessarily saying like this responsibility falls directly on you specifically and only you but I am saying that I think it's healthy for teams to be able to reflect on this and it's very easy for us to not like to ignore it to forget about it it because like I said we got to do we're busy making those changes driving those improvements so I get why that's easy to put aside but I do think there's value in um in making sure some of those things can be in place so when you think through that like again I'm not going to sit here and prescribe go document this or change your onboarding process to that but I think that there's a takeaway here where you can take a step back and say like what do these things look like if we had to tomorrow go

swap out half the team and bring on new people like how painful would that be and don't get me wrong it's probably never going to feel good ese I mean the people part aside because you don't just want to miss half your team but I just mean like in terms of onboarding and getting people familiar that's probably never going to feel totally awesome that would be a very difficult thing to do but what could you do to improve it right so I when I talk about this kind of stuff in general and like Team Dynamics I like thinking about continuous Improvement so if we were to take a step back and reflect on how the team works together currently whether that's the product itself our processes our codebase whatever like do we have things set up if we were to reflect on this do we

have things set up in a way that enables new individuals to come on okay so that's something that I would like you to think about the flip side to this that ties in a little bit more specifically with this person's situation is single points of failure I think they're very much related because if you're talking about onboarding sorry and making that smooth for people it would not be a smooth process if you if you're on boarding meant that every person that was on boarding had to go talk to Jim on the team and Jim likes to also take his vacation days that he's earned so people can't on board at all if Jim's out like that would be not a good experience and something that you'd want to optimize for what is going on at this turn okay I'm getting gas here um so I'm

going to say it out loud again before I stop so I don't forget and there's no bloody spots here U let me turn around I I don't know why I go to this gas station too I hate it cool okay but what we are talking about is single points of failure so BRB all right so single points of failure in the team if you are I already turned this thing off man why is it beeping at me um if you're finding that you have individuals that are single points of failure for anything on the team this is something that's really important to address and it's funny I think some people are like oh like job security right like if I know this thing and no one else knows it isn't that job security like that's what I want like sure um I've talked about this

before too like yeah you could look at it that way it also means that you're also um kind of stuck doing exactly that until the end of time so if you found that thing you love to do and you don't want to grow anymore in your career and you want to have that job security there you go hoard it to yourself you're good to go uh I just think that's a pretty terrible way to approach your career but that's just me um so especially from a team perspective though we don't want single points of failure that doesn't mean that they're you know can't be experts like I've worked in tons of teams where one person is like definitely the expert on something but that doesn't mean that like other people just don't know anything about it and that's important like other people should know stuff

about it they don't all have to be experts so I think there's going back to what I said a little bit earlier when you can have sort of expertise split out across the team I think that's very valuable um you might have pockets of deeper expertise in different areas um but you know everyone should at least be a generalist across the board so identifying single points of failure how do you go fix that well you would go try and make sure that if someone is such an expert in an area and there isn't even basic knowledge uh across the rest of the team in that spot that you start carving that out right maybe you know if it's not even something that's being actively developed anymore but it's still Mission critical so say it's a legacy system and only one person has that that knowledge

like you could basically try getting them to to document some of it do presentations on some of it so there's like um almost like video documentation of what's going on uh I think there's there's a lot of things you can do if you're actively developing in those areas you might say look we're going to take someone else and get them to do the work this time we realize it's going to mean things are going slower we understand that tradeoff um but it's worth it in this case I really want to get in front of this bus in the fast lane but this guy in front of me is not quite going fast enough to make it happen please stop no don't break oh you're ruining everything oh man this is the worst cuz the bus doesn't go faster than the rest of traffic they go

they are like slower than the rest of traffic in the fast lane and it's really stupid like if you're already going slower than the rest of traffic just stay in the rest of traffic going slower just do that don't ruin it for everyone else like me you're ruining my day so single points of failure address those find ways to get other people ramped up in those spaces but this is all stuff that we want to do well ahead of time this is stuff if you're not you don't have people leaving the team right now everything's good everyone's happy you know teams growing you got good product and service getting off the ground awesome don't neglect this stuff like do it while it's early make a habit of it because if you're trying to implement this stuff later it's more challenging right there's a lot more

knowledge to get uh your hands on get understanding of like it's just it's just more challenging so start early I'm hoping if you're listening to this and you're like yeah we don't really have that problem like today you don't and if you try thinking through some of these things you can help prevent those types of problems and I'm sure you can come up with your own solutions for this right I'm just trying to get this idea seated for you to think about okay so this is like some of the the early pre-work there's two buses oh my goodness so for context I'm going under the speed limit if I look in front of the two buses I can't see the next vehicle in front of them okay the lane to my right is slowing down and the lane beside that slowing down cuz there's cars

that are coming on but there's two buses in front of me bus directly in front of me has his brakes on there aren't cars in this Lane that I can see ahead of them we're going 10 m hour below the speed limit for no reason it's very frustrating okay next phase we're talking about is there is a planned transition so you haven't done the transition but now we know what coming okay how do we prep for this this is where we take some of those ideas that we just talked about and actually cue them up sort of tactically now because we're going hey look maybe we didn't plan for some of this really well maybe you have done a pretty good job of this and there's only a couple of gaps great right but let's go review what's going on and come up with a

tactical plan for making sure that this can happen so something that's important you try to do is look at the areas that you have some of the deepest subject matter expertise Andor history on right and if you're being honest and working with your team on this like is there another person on the team or multiple people that that have some of that knowledge right it's not a it's not a matter of like oh I know more than you or you know obviously nothing like that it's like do we legitimately have people that feel comfortable in this space have I been taking all of the work items to do in this in this space for the last four years and now no one else knows a thing about it or am I the only one that was around for8 years ago when we had this Legacy

system I've been the one kind of keeping it going but now I'm leaving and it's not going to be my responsibility anymore but no one knows it right so I think it's important you go through this little exercise of like what things am I potentially the single point of failure on could be a bunch of things so areas of code um could be you know just Knowledge from different things trying to think like different processes maybe I just I'm going to make up something off the top of my head right maybe uh maybe you have someone who's been do leading the the scrum for the last six years and no one else has ever tried it no one else actually knows how to do it this one's probably an easier one to solve but you know if there's if there's processes in place try to

think about like what what that might look like as a Handover but that's sort of the next phase is like kind of Designing this like this Handover portion now depending on how much time you have in your transition this is dramatically going to affect what you're able to do right so if you're like hey like next week I'm switching teams you only got a week to go try to put something in place and I think you need to be realistic that if you've been a single point of failure for a long time on important areas it's probably going to take longer than a week before one random person on your team happens to build up not even to the same amount of experience as you oh my God I need throat losses that's all I keep getting like as I'm talking I'm getting a tickle

in my throat it's like I don't even have a sore throat my nose is clear very odd um so yeah it's not about having the same level of depth and expertise as you right it's just like someone's got to be comfortable in that space so what is that plan going to look like to transition stuff over especially if it's not going to fit into the time and I think that this is important to um to have like clear boundaries and it's hard because like it's hard for two reasons and so let's talk about one which is like you you you have new priorities coming up you're going to be on a new team there's going to be new responsibilities for you you need to make sure that you can commit your your all to this new stuff understandable the other side is like we can't

just drop the ball right we can't just have one team completely fall apart because someone left especially if they're like in the same type of proximity right it's not like they they won the lottery and left the company it's like you know they're on a partner team now and it's like ah like John you're still sitting right here like could you just help with this so we need to be able to respect people's boundaries for the new stuff they're doing but we also can't just drop the ball completely but that's exactly why I think it's important when you're coming up with like a transition plan to talk about actual boundaries right so I want to give you a concrete example because I lived through this at Microsoft um this was a bit of a a surprise for me a couple years ago I I was

managing uh I've talked about this concept of like feature Crews which are smaller teams within teams so I was managing a feature crew and then there was a manager who was so on a different team there's a manager who is transitioning to another entirely different team and um my skip level manager cuz my manager had actually left my skip level manager so I mean technically my direct manager at that point had said hey by the way this guy's leaving so we're going to be giving this team to you I mean that's exciting that's a really cool opportunity for me right it's a little scary but these are types of things where I'm like hey like someone trusted me with this it's not like he was like oh man like I don't trust Nick with this I better like I'm the skip level I should take

this team on and because I don't trust Nick so it's a good feeling where it's like hey like you know I believe that you can handle this I got to pass this bus now this is nuts crazy um why am I living like that um so when that happened though what was really interesting is like I had a conversation with that manager because it's like what had happened was that a lot of the a lot of the people that were on that team were also going with that manager to another team so that's a that's the little little trick that was put into here it's not hey you're getting this team cuz the manager left it's hey you're getting this team the manager left and there's a lot of people that are leaving with him and it's really another layer to this is like there

were there were some really awesome Engineers on that team I don't I don't think they give themselves enough credit and I mean it genuinely really really smart effective engineers and I remember talking to their Tech lead and and this is like not in a private chat either but like their Tech lead was saying like yeah like basically he said and this could have been a little bit of a language uh difference barrier thing going up he basically said like all the smart people left uh and I think you know I think he's trying to say all the subject matter experts left so when I was working with this team I felt like they had lots of very smart people they navigated things very well but this is a a signal from the team where they're like hey like we have a lot of really good

people that are gone so I remember talking with the manager who had shifted out and we came up with the plan because the re like he understood we can't just have no support for our team um so we came up with a plan over a couple of months basically the people that transitioned would still be trying to help now it meant that we would try first pass right like we need to start practicing it's going to be hard but we'll try first pass and then we can engage them so that was an agreement we came up with the second part to this though was that we have on call rotations and this made it really challenging because without getting into too much detail so uh I was left with one part of the team and one geography where given the number of people they would

be permanently on call which I can't do so this is a really difficult thing because we're talking about transitioning the responsibilities and looking through this stuff but it's like hey look like we can talk about what that looks like but I don't have a solution for on Call rotation there are physically not enough human beings to make that work in a particular geography so this is one of those things that I had to go solve uh in not a very easy way but um like we had really good support from their team in terms of the transition but we had and and not I'm not blaming anyone right we had no support on the on call stuff afterwards because the people that left had their own on call rotation to go on to they can't do both so very challenging but the point is that

we had to come up with the strategy and that involved sort of like a Time boxing thing setting boundaries to say after this point in time like we're basically we're hands off at that point um so I would recommend some type of approach like this where you're uh coming up with a strategy to do that the right timelines or how much handson and stuff that's going to vary from you know team to team place to place so something to think about I got to switch lanes here and it's kind of foggy and I'm just watching for brake lights I got to get this highway um given where I am on the highway let's kind of shift gears now to um specific this individual's situation right so seems like the transition has happened and it seems like things are pretty painful um it's hard to go

look at some of the examples I gave and say oh we'll just we'll beef up the documentation like oh we'll come up with an action plan because it's already happened right this person now feels like oh man now I'm drowning like I'm kind of doing work on two teams um but I do still think a lot of the same Concepts apply okay so one of the things when I talked about this for helping Junior engineers and I think the same idea works here it's not about junior or senior it's about who has experience in a particular area so in this case we have an individual who's saying he's getting like SOS messages right previous team's messaging me I got to help with an emergency it's taking up a ton of my time what I have to say is like if you want to make this

situation get better it probably gets a little bit worse first so when you're helping out in those emergencies instead of just solving the problem instead of just saying no problem I know to do this I'll get it done take a little bit longer and teach someone if it's already been documented point that person to the documentation say you try it let me know when you get stuck in the documentation uh I will guide you through at that point and then you can go update the documentation right if there is none you're sitting down with them you're going to show them how to do it and then as you're showing them you could be asking them to create the dog documentation and I think that it's important that you don't just go create the documentation off on your own because if you've read if you have

experience like with documentation on teams when you have an expert writing documentation and then the next person goes to use it a lot of the time it feels like people are like I see there's documentation but like what the hell am I supposed to do with this and it's because it's written from the perspective of an expert not from the perspective of someone who has no idea what the hell is going on and the people that generally need that documentation are the people that have no idea what the hell is going on so it's really helpful if those people work with the expert to write it you're going to be in the fast lane man you got to be at least going the speed limit so let's make sure that's happening cuz the guy behind me is trying to go faster than me and we're

not even going the speed limit so I think Buddy in front's getting the idea now we're good um so that's the first piece of advice which is like don't just give answers because I I think this kind of thing would get better over time but I I feel like it's going to feel very bad for a lot longer and if instead you make it a little bit worse in the short term you will find that you get out of the situation faster you need to start helping the other team your previous team build that expertise so teach them so take a little bit longer teach them and get them to document it I think that can help a ton um I think something that's really important here too is like setting expectations with managers and I'm going to make an assumption here that if you

switch teams you also switched managers I can't necessarily assume that but I'm going to if that's incorrect sorry this might not feel applicable but let's assume it is and um so now you have your previous manager and you have your new one this guy was still trying to fly up behind me I don't understand sometimes people try to race me so they drive like a little bit erratically so he was like tailgating me for a bit and then backing off and then tailgating again and you can't see but when I'm telling you like people are going slow in front of me I'm not tailgating them so you can hear the car but you can't see how I'm driving so I understand you might be wondering about that but tailgating people is a real stupid move um don't want to be in that situation um so

when you have two managers in this situation if your old one and your new one I think that it's important you get both of them on the same page because you might feel like you're getting pulled in different directions your new manager going forward is going to be the one helping you grow in your career ideally but it's not like your previous manager just all of their input is dropped right I know when I transitioned teams onto my new team earlier this year my manager still had lots of input into my progression of my career and that's because I've been working with her for the entire time before so if I want my career to like basically just restart I can't see I was going to turn right on this red but oh it says no turn on red so let's not do that it's

a the no turn on red was like right where the pillar of the car is I had to move my head around it and screen um so yeah your previous manager is still going to have input into your career progression at least for like the next phase of like as you're transitioning so it's not in my opinion it's not wise to be like hey screw you I bought a new team um so don't do that but also you don't want to just like ignore your new manager so I think it's a really good opportunity if these expectations haven't been level set like try to get your new manager and old manager on a call together or if you're in person talk in person say hey look like I understand these were things that like I was responsible for people are coming to me because I

have the expertise here and like here are my new priorities that I've been given so I need both of you to kind of come together and understand that like I don't have infinite time and how can we work together on this to come up with the plan um I want to be very transparent with you that if I had an engineer come to me on my team or that had left my team to go to a different one and talk to me about this I would be happy to have that conversation and why because I understand that they're going to have new priorities I don't want them to go drop everything we're asking for and go work on their new priorities I want to make sure that if we need help we're getting that support but it's also important to understand if they don't have

capacity for it like what is that going to look like what can we do to make that better so personally I would want to be working with this engineer I would want this conversation to happen you might have a different working relationship with your manager new one or previous one and you're like Nick that would never work for me don't take that advice then um but I think that finding some way to level set those expectations however you think that needs to look for you needs to happen um because you're fighting this internal battle already where you're feeling pulled in different directions and you might find that given what's expected of you from the people that are helping you grow in your career or should be they're okay with you being more on one side or the other maybe it's totally acceptable from your new

manager and your old one that you are spending significantly more time transitioning out right maybe that's cool and Maybe not maybe it's the exact opposite and your new manager's like look that's not acceptable and I'm going to make it clear to your old manager okay right but like have the conversation instead of just like feeling like oh I don't know and it it feels bad um I think I think so many more things could be improved if we spent the time there goes my voice if we spent the time having conversations about them I just need a throat loss man I ate the last one we had in the house end of an era cool okay um that's it for this drive I will have another video on the drive home thanks for tuning in it's a bunch of videos this week but um we'll

see take care

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How can I handle constant requests for help from my previous development team after transferring to a new team?
I recommend not just solving the problems for them but taking the time to teach someone on the old team how to fix the issues. This might take longer initially, but it helps build their expertise and reduces future requests. Also, encourage them to document the solutions together with you so the documentation is useful for people unfamiliar with the system.
What should I consider when planning a transition from one development team to another to avoid being a single point of failure?
I think it's important to identify areas where you are the single point of failure and work with your team to share that knowledge. This could involve documenting critical systems, giving presentations, or pairing with others to transfer expertise. Starting this early makes the transition smoother and prevents over-reliance on one person.
How do I manage expectations with my old and new managers when transitioning between teams?
I believe it's crucial to get both your previous and new managers on the same page about your responsibilities and boundaries. Setting clear expectations helps avoid being pulled in different directions and ensures support for your career growth. You might consider arranging a meeting or call with both managers to align on how to handle ongoing support for your old team while focusing on your new role.