LEAVE ME ALONE! Moving On From A Software Project

Transcript is auto-generated and may contain errors.

all right folks I am headed to CrossFit we're going to Reddit for a topic uh this is from the experienced dev's subreddit and it says how to stop being the go-to firefighter for projects that I've handed off um I'm not going to read out the whole thing cuz I'm going to be late for CrossFit um but uh if you end up enjoying this and you want to consider sharing it back to the thread that would be super cool because I don't want to go posting my stuff on Reddit and then get banned from subreddits for self-promotion and stuff but if you think it's helpful then that'd be great if you want to share it and a friendly reminder that if you want questions answered leave them in the comments or submit them to Dev leader on social media which is my main YouTube channel as

well and then I'll keep uh your information Anonymous and make you a video about it okay so this is a an interesting challenge uh especially if you have found that you're in a situation where um if you're doing prototypes or you got to work on something early and then it got handed off maybe it's even like a team change and so I don't think that it's super rare I think maybe depending on the type of work and the type of projects you've been working on it might be more or less common but uh I can totally understand why this is challenging for people and if you haven't been in a position like this just for a little bit of context like some people might say like hey like isn't that like a good thing right you're you're important right there some people might be thinking

about the job security thing where it's like hey people have to come chase you down because it's you're so important for this project and that means that they need to keep you around kind of thing um but it's it's actually a bit of a pain in the ass and um it's distracting and uh sometimes like because it's no longer your priority especially like given you know if it was a team change and you have like a different manager or anything else like when it's no longer something that's supposed to be your responsibility it can start to feel very frustrating okay so it's uh it's not about just being important or something like that it's like you feel like you want to do the right thing which is help your colleagues right you don't like you're all working at the same place you don't just just

want to be like screw you and um and then everything falls apart so you try to help and then get that out of the way then you get back to your own priorities now the way that I've seen this kind of happen before and like seem like it's not getting better is a similar pattern to what I've talked about in other videos which is um like in order to fix this I feel that or to improve it I feel like you need to like it needs to get a little bit worse before it gets better so what does that mean well if this is already something that's frustrating you right you probably want to spend as little time as possible on it because the more that it frustrates you the more that you're like okay like get it out of my face I'm sick and

tired of working on this sick and tired of this situation like how do I just move on from this as fast as possible but generally what happens with that is that you are kind of uh I don't know a good way to to actually articulate this like instead of instead of you showing other people you're like just doing for them right so hey this doesn't work and this project like uh whatever thing you built like we're confused we don't understand it we don't know how to debug it and you're like okay like I don't have time for this so what I'm going to do is basically tell you to like screw off for a second and like I'm going to go dig into this because I can do it faster than you I know where the things are and then I will you know when

I come back up for air and uh have all the answers and I'll I'll share them with you and then so you do that because it's it's optimal for you right in terms of your time investment it feels like the fastest way to to resolve the problem and you're helping them because you're giving them the answer and then they go great thank you so much you're Lifesaver and then they disappear until the very next thing happens and they're like we don't know and if you're hopefully the pattern's a little bit obvious there uh especially if you've seen me talk about this in other videos when it comes to mentoring and helping others but um this is in my opinion it's very much the same thing there's going to be some nuances to it but um the big challenge is that you're not actually helping other

people understand it and at the end of the day if they're not understanding it then they have to keep coming back to you when they need something done now I guess like part of me wants to say like shouldn't we just assume that like it's their project now and like they should just be spending the time learning and understanding it yeah I like I I don't disagree with a thought like that I think that depend ending on their circumstances they might be getting pressured to keep extending stuff in the project right so they're just building new stuff on top of it and then something else in in whatever you might have been part of building before is having challenges or um they broke it and they don't understand how um so they're getting their own pressure where they're like we have to keep moving fast

to keep adding stuff into here uh so please help or it's a livesite incident depending on what the the product or services and um and they're like we you know we don't have time for this and obviously you don't want to be the person who's responsible for Liv site stuff on something that you don't even have ownership on now um but what ends up happening is that people have to come chase you down right so this uh this type of thing like I said I think is a situation where it gets a little bit worse at first because horse at first nice uh you got Rhymes uh I threw myself off so yeah you end up spending extra time I'm just thinking about someone writing a comment being like dude are you okay um but yeah you have to spend some extra time and that's

why it's going to feel worse right because you're already like get this stuff out of my face um I'm going to Pivot in a moment to talk about some preventative measures for this kind of thing um but I just like I should kind of interject for a moment and say like this is something that was a huge part of my career for for eight years and that's because I like basically built prototypes for like eight years and they either became teams or I ended up having the team that would continue to run it um so like at one point I had a full-fledged prototyping team and then uh before leaving the the last company I was that uh that was actually something where they were spinning up again a dedicated uh dedicated prototyping team and it's because it got to the point where there would

be I I feel like it's a good problem to have right I talked about the the CTO at that company before um and you know I think one of the you know best user proxies uh you could ask for in a company because uh he he was you know the customer so to speak uh when he started this all off he was building software that he would need and then was giving it away but what would end up happening throughout the entire eight years that I was there was he would always have ideas and just enough programming abilities to like go make them himself but it's kind of problematic when you're like uh you know software engineering team that's already feeling like overworked uh deadlines are always like you're always trying to rush to get the value out to customers and um or feels like

you're rushing to get value out to customers but then there's always one more thing and then the CTO has got this idea and you're like okay we got to we got to slow down um so we can breathe and then he would end up you know spinning up his own prototype and then we're like okay well now now we're in in a position where like the code got written anyway and now someone's going to have to inherit it and it's probably in my opinion at that scale like a far worse spot if the CTO of a you know multi hundred person company is is spinning up prototypes that we're going to have to inherit again not not bashing him I think like he is very in tune with what users actually need um so not certainly not a negative comment just more of like an

organizational Challenge and so like getting to a point where we're like okay we're going to actually formalize a prototyping team again that was something that I was going to be uh leading and uh kind of going back to what I was doing uh more actively at one point but because of this I just wanted to mention like this is something that I spent a a large part of my career doing because we would get tasked with prototyping something to prove the viability and then if it was viable and we're like okay like we can get past these technical limitations and the context is for building digital forensic software so um a lot of this stuff it's not like you could just do a quick Google search and then say oh yeah like I found the code that does it it would be a little bit

more digging into understanding like not it's not quite reverse engineering cuz I think that's too loaded of a term but like you kind of have to be a detective and understand like traces of data uh how things get left behind because when it comes to forensics that's really what it's going to be about um so that you know law enforcement investigators like you can help build the tools for them to say hey look like we know that they're uh when you use particular things like this type of TR of data is left therefore we can build you tools that will help you like discover that so we would build these things and then prove if they're viable and if they were this is where it was like okay either my team at that time would just keep running with the Prototype and try to formalize

it more or we would hand it off and like you know there was there was at one point like we built a prototype for something and we were like okay hell yeah this is going to be a big deal um and it got handed off to a a team that was like at our other office even so like it wasn't just like handing it over to your neighbor in the next cubicle it was like no like our our I don't I don't like calling it a satellite office it was satellite to our headquarters but I don't mean to like diminish the the contributions of that that office but uh you know so that other team at a different office took it over and built and an entire product around it which is super cool but you you end up in this situation like okay we

we built all of the original stuff that went into that because it depending on the Prototype sometimes people take prototypes and they go great like you've proven the viability we're going to scrap whatever you built because like you you built it a particular way no one's judging you like you're just proving viability and great like now that that's been proven let's go like design an architect how it has to be integrated into the right solution um but sometimes people will take prototypes and just say like it's working right like it's working we don't have any um you know necessarily concerns with how it was designed it's not like we're looking at it and saying got to start from scratch so they would just take it and continue to build but um yeah there's a lot of these situations where uh especially if you have multiple

prototypes and sit like scenarios like this that you've built up over time where you're constantly being pulled around and and actually like the extension of like what I was doing mostly before leaving that company was that I kind of went back to what it was like in the very beginning when I started there um I was going around helping right like my a lot of my time was spent doing that the difference was that in the beginning when I was at that startup I was going around to different developers desks and like trying to help them code specific things and by the time I left there it was more like I was going around to different teams in different products that I had knowledge on from either building or just historical knowledge and and helping provide like uh historical reasoning for things or like fighting

not quite like a consultant but like kind of like a consultant for some of the product managers as well um so I was spending a lot of time doing that and it's it's a little bit different than what we're talking about here but um I think it's because the the role that I had at that company had evolved into like you know uh I I've even talked about this before that was by that time I was doing a lot more like pure management versus coding so it's because those types of activities started to take up more time okay so I wanted to provide some context in case you're like well you know if you're not new to the channel you might have already known some of that stuff if you are new to the channel it's like who's this guy talking about this stuff why

does it matter which is a totally fair question but I wanted to Pivot because I got about says 6 minutes to cross but we'll see um I wanted to talk about some types of like preventative measures for getting into this kind of situation and one I mean it's not it's not going to be a bulletproof plan but a thing to consider is like if you are building something that you have an understanding uh that there is a possibility say like a pretty good one that it's going to be handed off uh I would say start early on designing uh whatever type of documentation is going to be relevant for that project it doesn't mean that every single line of code needs a comment um but like there's going to be Concepts that need to be documented right there's going to be like uh design decisions

this is where sometimes like as you're putting stuff together you might be like we didn't sit down and do what design dog because it was we're prototyping and it's going to slow us down and like I I think that's fine that's fair whatever you know I'm not here to say right or wrong but if something's in place now and you have to go hand it over to people um if you decided that you know along the way you made some good decisions I think it's very helpful to try and find some way to document what those decisions are and that way it's not like people inherit things and they go start asking all the same questions that you did right they're like I don't know why why Nick built it this way um I can think of 10 other ways to do it like was

it just the first one that Nick and team picked was this something that they evaluated I don't really know I don't I'm nervous to go change it because like I don't want to like undo what they did um or maybe they start undoing and they didn't even ask and then you find out why they're having all these problems so I think if you can uh especially if you have some inclination that things are going to be handed over uh definitely try finding ways to like document uh like retroactively is totally fine document decisions that were made right um at least some type of minimal documentation to get up and running um some minimal documentation around how to diagnose issues um again these might not be things that when you were building a prototype or an initial version of Something these might not be things where

you were like they're at the top of your mind to go to document and to make perfect and that might be just something that you have to close the gap on right is like okay this is about to get handed over to a team oh we didn't go build in uh Telemetry and Diagnostics and and proper logging like you might want to tell that team like immediately right they're about to go inherit something that they need to work on um if there isn't all that stuff it's not necessarily the end of the world but it's like you might want to go prioritize that before before you get too far okay so I think like a a good thought or like a yeah a good thought exercise you can try is like imagine that you were going to be the person inheriting something and what things

would you want to know so that you could be successful and I would say try try formalizing some type of documentation in some way that helps with that um I recognize that that's a like a happy path I guess if you know it's going to be handed over um you have time to prepare that kind of stuff so if uh if that's not the case if for whatever reason it's a team switch like so you're leaving the team or I don't know some some product is reor like I've had literally the team I was on before um at Microsoft we owned a service and at the same time totally unrelated but at the same time that I switch teams to where I am now my current team inherited that service um and when I say my current team I mean my my larger team that

reports up to my manager so like my group um so kind of uh kind of funny very coincidental but like that the ownership of that service got reorg if I can call it that um and you know that type of thing comes with challenges too but at least that was uh mature and there was documentation there was like uh because it's a service there was like battle cards for being able to you know help with lifesite issues and diagnose things so that's probably you know a good spot to be in but there's still going to be people with questions so I would say um what like even if it's a sort of a call it a surprise that something's going to be moving or you're going to be moving uh I would try to come up with a plan where there's alignment on uh the

transition right some time box transition I did this with another team that I had as well uh and the the difference there was like uh there was a there was a reorg essentially and I inherited a team and we came up with a strategy that said for this period of time like this is where we will we will be learning from you and leveraging you for on call and like basically we're a bit of a hybrid on certain things until oh there's no parking okay that sucks there we go um and yeah just coming up with an alignment because the the reality is that you're going to build resentment and friction and have discomfort if like people aren't align on what that is if you have a time boox window like that gives you some guidance around like we should probably figure some out during

this time because if we're not using that time to transition things properly like we should expect that it's going to feel rough after so hope that's helpful like I said if you thought that was interesting and uh and valuable then if you want to consider sharing that back to the experienced Dev subreddit for that uh that topic that was uh regarding uh basically getting pulled back into projects that you handed off uh that would be super cool and I'm at cross with so thanks so much I'll see you next time