Estimating Projects In Software Engineering

Transcript is auto-generated and may contain errors.

all right I am just leaving the office here heavier than usual traffic perfect that's what we want to hear um question from the comments this is from the coding lifestyle there's left a few questions and stuff before which is great so thanks for the uh repeat questions this is great um how do you how to gauge the timeline for a project or how long a project should take some projects can be six months to a year or more depends so I understand we can break projects down but how do you gauge uh the time and assess such a large timeline so far in advance how much room for adaptability do you give for example what if you overestimate the timeline and then your team has done the task but sitting idle and not communicating that they are done because of the timeline thoughts so I

got a bunch of thoughts on this um again thanks for asking I think it's uh an interesting one so let me get started here um we're plugged in we're beeping that's what we do um so yeah if you have questions that you want answered please leave them in the comments um I do read them and then I try to make videos out of them and then if uh if you don't want to leave a question in the comments because you want it to be anonymous or you want to provide more details please feel free to stop beeping at me um and send a message to Dev leader on social media that is my main YouTube channel and it's also um the uh Alias or like personal branding I use um and if you want to message me on LinkedIn it's just nick centino uh profile

should be open for messages so please feel free and with that said let's dive into it so um I'm going to I'll talk about a bunch of different things when it comes to like estimation and stuff like that uh context here and like disclaimer this is all my lived experiences and how I like to approach things I am not going to sit here and offer advice like it's uh like it should be the law or there's no other way to approach things there's a million ways to do things um so please keep that in mind you know if I'm saying things and you disagree with them or have different thoughts like that's great I'm not telling you you're wrong uh so just want to I like to throw that disclaimer out there because uh it's pretty common as a content creator when you say things

even if someone's like hey but you left this part out they basically disregard everything you said you might make nine out of 10 points that they're happy about and then you left that 10 point out and they're like so it's wrong so I'm just I know this is like a a highly debated Topic in terms of like how to estimate things or plan for stuff but I'll go through from my perspective so first thing um that I want to kind of talk through is that uh time Horizons make a huge difference right when we're talking about things the the bigger the project the bigger the scope and the longer the time Horizon the more uncertainty there is um so for example and I don't I don't know where the um the magic Line in the Sand actually is but if you are in a position

where you're like hey something is going to take 6 months like the amount of uh accuracy you have on that is going to be you know uh way off compared to some like statistically would be way P off like compared to something that's like it's a week's worth of work um compared to something that's like a Year's worth of work right if it's a Year's worth of work you might be off by a whole year like maybe it's two years of work um so you know I I think that we have to keep that in mind and the reason I say that is because if you're in situations where just to give you an example uh you're doing planning uh with your team or with your organization or whatever it happens to be and you're talking about time Horizons that are on the order of

months um sorry I just saw a message from my my manager we were working on a document and the the tables in the word document keep losing format um added and them back um okay so if you're planning with your team and people are talking about like hey like the next six months I would say like again I don't know what the right time Horizon is I honestly like doing uh every quarter even quarter to me the the shorter the time Horizon the better but you need to be planning more frequently and um when you're looking at something that's like a quarter okay so every three months um I I think even at three months you should um you're already kind of like you should be agreeing with the themes and like not the implementation the at that point when you're trying to talk about

like the implementation is going to take whatever and fit into three months I'm like you're you're not that you're going to fail at it but like get ready to adjust um and if you're going like six months out even uh even even less likely that you're going to have it uh close on implementation and I say this because uh of the framing that I I'm trying to suggest you have or at least point you in the direction when you're talking about plans that are three months like a quarter or six months like a half for the year um those conversations in my opinion you should not be going into implementation details like talk about what the the goal that you're trying to achieve is because the reality is and I'm going to talk about this a little bit more later um the scope of the

work that you have in terms of how you're implementing it you got options right you're going to be limited by time quality uh or scope and that's like you could probably argue a couple of different things there but I think that if you make a triangle out of those things you're you're pulling in the directions so when you're talking about what you want and a plan that's like 3 months out 6 months out you shouldn't be focused on the the detail of like how you're going to implement it it should be what do we want to achieve because what you're saying is the time is fixed the time is fixed to be three or six months in this conversation the quality ideally is something you're not moving on right you want to have good quality always so the only thing that has movement is is

the scope and that's going to be how you're implementing things that's my take on it at least so um I just wanted to start this conversation by kind of framing it up that way um as a heads up now the other part to this question and I'm going to I'll spend additional time talking about like how I've approach approached either planning for Sprints or for um like semester planning whether that's quarterly or by halfs I'll talk about that more in detail because it looks like it's going to be a pretty long drive um so we might get through this question specifically a little bit quicker and then I'll spend more time on on planning stuff in general and maybe some story time I think there's a good story um the the question was like so say you overestimate right so you you pick a timeline

we could talk over or under um you pick a timeline and you're saying hey it's going to be it's we're planning for the the quarter it's going to be three months or the work and your team finishes faster the the question was like how do you like what happens if your team's just sitting idle because there's no more work to do um I would it sounds I don't mean to be factious when I say this so I apologize but there is always work to do so basically if you're finding yourself in a position where there is a team of people that finishes up early because they predicted something and it's not what it is they're just done wake sooner and then they just sit silently and wait uh something is broken in how the in my opinion something's broken and how software development's being done

because either people aren't getting updates along the way or people are getting updates along the way and then not recognizing that there are people freed up to do more work so in my opinion when you're doing long running projects you want to make sure that there are at least some there's some Cadence for you know updating progress right this is a part of trying to help make sure that things don't go completely over which most of the time you know we underestimate things most of the time I don't have a stat on that but I would wager it's almost all the time and uh it's pretty rare I think that we finish things up like super quick so Not only would it it suggest to me that like this is a bit of a broken process but also that it's pretty rare that this actually

happens but let's assume it does because it's totally possible so if it wraps up early I would be saying that like you should be having these regular updates communicating status whoever the stakeholders are the frequency and the format of that could change dramatically depending on what the project is the scope of it the stakeholders the company whatever so I'm not prescribing anything here but some type of cadence and basically it should it should start to be pretty apparent I would think that if you're saying it's going to be three months or 6 months or a year that if you're going to be way faster than that it starts to become noticeable in those updates so you should have an early sign of that that's part one number two is that there should probably be an update that says hey we've finished right like to telling

the stakeholders we have finished the work we are good to deliver at which point whoever is responsible for helping coordinate the efforts of these Engineers they could make a conscious decision to say okay everyone gets a break which um I don't think ever happens maybe unless there's contract work or something I don't know like if you've been paid upfront or the it's been agreed upon for the scope of time frame of the work maybe that's a situation for this I don't do contract work so it's not really fair for me to comment um certainly anywhere I've worked people are free there's a backlog of work that doesn't stop growing so uh you know it would be a matter of hey look okay this group is freed up because they've successfully delivered and ahead of schedule amazing right but there's other work to do so it's

not just sitting around so I would you know just to to wrap this part up I feel like if there's a situation where you know people are done early um it it should be pretty apparent through some type of process you have uh even if that process is like essentially nothing and just hey we've stakeholder update like you were interested in this we're done it should happen um I feel like if there's literally no updates to any stakeholders that care uh that's not a good spot like something's broken and now that I'm saying all of this and I cuz I realize it sounds like I'm being a little fous and I don't I genuinely don't mean to do that uh I wonder if what this person is asking is actually like say you're you're running a team like let's change the framing a little bit

so you have a team and you're on the other end of this and they're the ones kind of keeping it from you or or whatever maybe it's a partner team and they've wrapped up and they're kind of waiting on the work um I would say you need to find the balance between like micromanaging so you're not like you know asking them every every minute to be like hey what's the status what's the status when's it going to be landed um but you're also not um like so disconnected that you have this opportunity for a ridiculous Gap um if a team is like being like malicious or just like outright hiding stuff uh like you know they give you the status update they're like oh we're still working on it but you they've been done for two months I would say like that's just a a

like a company culture thing that has to be you know addressed immediately because that's a wild um but certainly if you're on the outside of the team that is doing the immediate work this is something that you should think about if you're a stakeholder in this how are you getting updates what does that look like to you um brief you know quick example uh I was telling an employee I have today that there's a piece of work that I've been kind of overseeing and I said by the way there's a new uh you know one of the the product managers is actually going to be taking ownership over this part and I said so just a heads up like as they get on board into this area they'll probably be asking you questions that are like you know complete overlap with stuff we've been talking

about so I said I just want to give you a heads up because I don't want you to think that like there's additional pressure and you have more people chasing you for updates and stuff I said they're just getting onboarded and ramped up in this space and they're you know very engaged very curious so like it's mostly them exploring things and just trying to get figured out um and you know with that I will be kind of uh a little bit more removed so there's going to be this weird period where you're like okay like why do I have all these people asking me things but you know here's the heads up that like that's not not intentional to be microman managing you so you know let me know if you feel that way and number two uh it's temporary because it's a transition uh

and I think they appreciated that from my understanding uh let's get up here I got to merge lanes but there's a bunch of trucks I hate this part of the highway if you're a a frequent Watcher of these videos you'll know that I'm trying to get over to the fast lane which is like many lanes and it sucks to get into um especially when people are not moving come on okay one more lane and then we're cruising it's still light out so I don't have to yell at people for not having their lights on like this idiot coming up lights already should be on but okay one more sorry I know it's mid conversation but if I don't get in this fastly and I'm going to be stuck in traffic for the rest of my life and if you can't tell I don't like traffic

I don't know would this be would merging in traffic be an interesting 360 cam footage we made it okay okay so yeah so that was just a a quick note on like you know trying to give someone context like I'm I'm coming for updates I will be coming less to you uh less frequently for updates bit of a transition phase but I need to make sure as a stakeholder that I am getting the updates I need without overloading uh the people I'm trying to get updates from and that could be very situational right um You you in my opinion I don't know why people don't do this more like just have conversations if someone's like hey man I'm feeling microm manage because you're asking me for status updates all the time like have that conversation like someone's and usually when that when you feel that

way it's like someone's just trying to get information because they need it to do their job so it's like they're not just trying to be an to you so if you have a conversation and you're like hey you know it's feeling like this is a little bit too frequent it's a little bit distracting like is there some other way that I can help support you more effectively great conversation to have you can you can make that a very positive healthy thing and not telling someone that you like hate them or resenting them because they're micromanaging you like you can just try to have a conversation about it honestly uh in many cases this is one of those things I recognize as I say it someone's like no not not my experience I'm like I get it I hear you but you know we should also

acknowledge that you can absolutely have conversations and you should okay so I I hope that addresses the the second part of that question that was asked which is like how do you how do you deal with situations where the estimates weigh off if it's the other way and say you're way under I think some of these things still apply and what I mean by that is like if you're a stakeholder are you having conversations with the people that are responsible for delivering to be like hey look like this feels off track I'll give you a great example from literally a meeting I had today where the some of the communication we were having with um participants of a project as a stakeholder um there was a few of us where we said hey look like we're basically we're under the impression right now that that

you guys actually don't have confidence in in the the time estimates that we've been talking about and so we just had a conversation about it and they were like no no no like we actually like we have absolute confidence in this part when we say we don't have confidence about this other part here's what we mean but like just literally through a conversation we were able to get on the exact same page make sure we were aligned and came up with a strategy for making sure that we were clear about like if this if we start to feel differently about this and like you know we're losing confidence in the deadline how do we make that apparent how do we have a signal for that um so it was a you know super healthy conversation in my opinion um I left that feeling like everyone

was on the same page and before that it's not like it was a problem but it was like Hey like the signal we're getting from you seems to be that that you are losing confidence in delivery and they clarified it and it was great so again like if you're a stakeholder um have the conversations um if you're on the other end so if you're someone who's responsible for delivering things to stakeholders um then like if my opinion raising awareness sooner is better I have never found in so in my career 12 plus years uh my professional career like I've never been in a situation where it's like ah like maybe we shouldn't say anything about this and just wait like it's a I think people get afraid right it's like we don't want to say that things are off because someone's going to come get

us like we're we're going to get fired we're going to we're not going to get promotions we're like it's something bad will happen but the reality is that like in every situation I've been in people will be disappointed gen like most of the time not at you just disappointed in the situation but they're just like okay now that I have been disappointed what's the ne like how do we get to the next step it's very much not about like hey you suck you're failing it's like cool thank you for raising awareness obviously this is unfortunate what do we do like let's come to Solutions right so again example from today it was good we clarified like hey there's still confidence but we said how do we continue to basically um I don't know a good way to phrase this like we we have alignment on

it cool what is our strategy what does that look like and um like like I said like what's the signal how do we raise awareness if we're feeling like that's shifting apparently we're coming to a stop this is the best part about the fast lane that you pay to be in when you end up being slower than the people in the not fast lane oh I hate traffic man but anyway point of that was like getting on the same page and raising awareness Ness is huge um one of the challenging things that uh I've been talking about this project that I've been uh leading uh this initiative right and um a lot of different St uh participants a lot of stakeholders as well the reality is when I am trying to get updates from people they know like we communicated this early look we're trying

to get updates to make sure that people can be unblocked right like our entire person purpose of doing these sinks please bus don't go in front oh yeah they're going behind me nice this the Fast Lanes go down to one and if you're stuck behind a bus then you're just going under the speed limit in the fast lane and they were about to zipper merge and they went behind me nice okay um sorry I got distracted and now I don't know what I was talking about I hate buses the um my goodness it's a long day talking about getting on the same page stakehold oh uh project I'm working on okay it's coming back you can tell buses really get me derailed so in terms of letting people know the updates we're looking for are to keep you from being blocked so when we're asking

you for updates the goal is not to like pressure you into like you better have it done by this day or else I told people like just let me know if the deadline's changing like if you if you need more time for something tell me it's not like no one's going to punish you for that we just need to know if you're like stuck so for example if you put up a poll request we were telling people this work is the highest priority work so you should be able to talk to your teammates and say hey pull request is ready please you know please focus on this and that means you shouldn't have poll requests open for like two weeks or something like that so if you're coming to these sync meetings and saying hey like I haven't made any progress because no one's done

the poll request that's where we need to be like okay like this shouldn't be happening how do we make sure people are getting on top of this stuff right uh or like design documents no one's reviewed this in in 3 weeks it's like we shouldn't be getting to that point so we're just trying to stay on top of making sure that people can get the support they need and it's very difficult to communicate that in my opinion like in an effective way because you can't just keep asking people for updates because they feel micromanaged and I don't have capacity to you know every 10 minutes ask people for updates but people would hate that so we need to be very transparent like you like we're seeking information if you have ways to provide that effectively please do because otherwise I need to get the information

somehow it will mean that I have to come to you and ask for it if there's no other way that I can find it so just striking a balance um and like I said it's challenging but um I I do my Canadian thing and I just apologize a lot um and hopefully people realize that I'm not trying to be a jerk I'm just just trying to get get people unblocked so okay we got about 30 minutes left according to Google and at this rate it's probably right um okay so I wanted to talk about how I approach like estimating planning things like that so uh I'll start with Story Time H and then going back to what the uh question asker was asking was really around this idea of like some projects can take a long time right maybe they're a month maybe they're six

months maybe they're a year like how do you how do you navigate that so the story time that I have is and I've talked about uh a couple of teams that I used to run at Magnet forensics um we had I'll start with the one team so one of the teams I managed was for uh making mobile digital forensic software when I say that I mean like doing mobile acquis positions so taking data off of cell phones and other devices that was our team's Charter uh being able to get as much data off of as many devices as we could support so the challenge with that is like at some point you reach this you reach a bit of a wall where it's like okay like you can't just like go on the internet and search like how do you get all of the btes

off of this phone because no one's done it yet so it's like it's truly like unchartered Waters and um as a result it's not just a matter of like oh let's um I don't know like it's just like we'll come to an agreement like the biggest challenge is like we'll agree on a strategy and then then we just need time to implement it's like we need to literally spend time to go investigate if this is even physically possible right we have devices that are encrypted there's different uh mechanisms for trying to get rout access there's there's whatever constraints that we have to deal with you know we can't run certain commands on these devices a million things so for us it was like there's absolutely going to be streams of work that feel like they're completely unbounded so to address work like this specifically I

think a couple of things worked really well for us and the first one and I think the most important and I would just it's kind of like a foundational thing like if uh I should stop saying if because I I would like to be more I don't know um assertive of this I want to say when I go to run a software company at some point in the future one of the things that I will really try to instill in the culture is like is really communication right like I think it needs to be foundational and when I think about the role of product owners or like product managers and uh Engineers like that needs to be like very tight-knit so again one of the things that worked really well for us was this idea that we are like completely in sync between engineering and

product on what we're doing so the way it would look is product would say look we want to priori being able to uh acquire data off of these types of devices oh boy that came out of nowhere um so we'd say okay by the way you recognize like um there's no known support for this right yes okay by the way uh we have speculation that like these other things that we've tried in the past may or may not work we'll have to go check that out you okay with that yep okay and by the way if that doesn't work do you want us to dedicate time to just like starting to explore yeah okay good news we'll start know how long do you think it's going to take and we would say we don't know we don't know but we only have like five people

on the team we can dedicate one person to looking at this and then they go okay well uh and then like what are we going to be able to get done otherwise so then we would have the this conversation okay if there's five people on the team one of them is dedicated full time to looking at this there's four of us left here's the stuff that we can go get accomplished because the the four other people can work on stuff that is uh more I don't know um more scoped I guess right like someone's doing some bug fixes someone's doing some enhancements whatever like so it's it's kind of understood that we have these other work streams that people can progress on so then the product owner say great okay that that feels like a good balance to me and we would start and what

happens though I'm kind of giving you like a snap shop but this is always ongoing meeting regularly it's like the product owner is essentially embedded in the team in our case they weren't necessarily but we worked so close they might as well have been they might as well been sitting right with us they might as well been coding with us so we had really good communication and then we would give them updates like Hey look it's been a week and like we haven't made any progress on this do you want us to keep going here's the progress we made on the other stuff do you still feel good about it yeah okay well we'll keep looking and sometimes it would get to a point where either product would say hey look we have these other priorities that have come up and we value them as

a higher priority than this other thing that we wanted to explore we would like you to wrap that up you know we can come back to it later or cancel it so that would happen or the engineer that was doing the work would basically say I'm hitting a wall I don't have any other paths that I know to how to go down right now so one of these two things or we would get it um one of these two things would happen and the work would get deferred now in our case sometimes this could feel like a failure like hey we couldn't get it done but in our line of work and you could probably apply this type of thinking to other domains is that we always had learnings always so we would say it's not a failure we didn't get there but we learned

a lot make sure that we document the learnings then we would have these times in the future where similar projects would come up some of the learnings from the first project sorry this person's merging in um some of the learnings from the first project that didn't finish enabled us to do this other one and then sometimes we'd learn more stuff about that and we'd go back to the first one and we could finish it so these things were always like stepping stones we might not get it the first time but we come back to it but the point is that we were always talking with our product owner and constantly making tradeoffs so I think personally that works super well because instead of saying like what happens if if we don't reach the target like oh no how do we plan for that we just

assume it's built into how we operate we are constantly adapting so like I guess what I'm saying is like instead of looking for how to avoid it or how to plan for uh a failure it's like just assume that this is ongoing and we will keep adjusting regularly that worked for us in this particular space the other way that we could address add it is we would say time box it right we think for the foreseeable future you could probably spend 3 weeks on this so if you if you come up with some good learnings awesome if you get stuck that's okay but after 3 weeks we've dedicated enough time to this particular area and if we can't progress on it we'll wrap it up and move on to something else so these two things for that team I had worked extremely well for unbounded

or long running projects so that's one thing um the other sort of uh let me talk about the other team first and then I'll kind of go back to uh adjusting things the other team I had was very much like uh similar uh repetitive work when I say repetitive I mean in terms of the the style of the work so we could we actually we tried can ban uh and tried to optimize the process and like make it basically like data driven and it was I thought it was awesome I think it was a really cool experiment that I believe I ended up leaving right so uh I don't know if they continue to do it but it was trending really well um we were proving a lot of really uh sort of effective ways to get done this type of work backed by data

which is awesome and um for us that again in terms of planning it it worked very well because the work was very similar in terms of the style of work so what it meant like what what happened is if something did go off track we would say look like I'm just making up numbers because I don't have stats from five plus years ago I guess it's four and a half years ago not five plus um but it's like hey like 95% of the time we have similar comparable work that we can work through and 5% of the time we have one of these outliers but also in that 5% of the time you could probably factor in some of them are way faster so overall kind of balanced out but we would try to learn from those things right like why was this one different

like what caught us off guard try to learn from it and then kind of you know factor that in so we had comparable things so when people talk about estimating and putting story points on things uh one of the uh I I don't know if he's a he's probably a director there now um one of the engineers that used to report to to me that became an em uh he was always saying like you know instead of trying to do estimates in the traditional air quotes traditional sense with your story points and stuff he's like you forecast right like you use historical data and forecast and you just keep reusing the historical data to to be able to project and if it's off like it as you go forward the the forecast will kind of uh adapt um I'm not doing that Justice I don't

think anyway the point is that like we basically leveraged that and it worked very well but it worked well because the work was similar so two very different teams in terms of how I approach like uh different shapes of work um okay I wanted to talk but and I only got a few minutes left I guess but I wanted to talk about like planning for stuff right so at the beginning of this talk I didn't want to forget this I talked about like you can have quality you can have time and you can have like your scope of work and basically um I'm going to I'll make the quality part very short quality is not really um something that we budge on um it's not like you're going to ship code that's like buggy now where we might draw the line on quality is like

hey you had um you know uh it's all like we're not not going to test the features or something but maybe we wanted to go build like a more robust test framework for this for Automation and we couldn't get to that but we did test things and we did learn how we would want to set up our automation okay um it's covered and then you know we'll ship it to meet the timeline because that's fixed and then we will Fast follow with the infrastructure um so it will push the next deliverable out further so we could make tradeoffs like that but it's not like you're just going to say ah like Co Works half the time like ship it um the other thing would be and I know this irks some people but like we're going to take on some tech de consciously for this

so we know to meet the deadline we're not going to go refactor and spend 3 months rewriting stuff we're consciously saying no we want to meet this deadline and uh we're prioritizing shipping something in a timely manner versus going to clean the stuff up some people hate that but I mean that that startup was very successful so it's kind of hard to argue that it's uh that it like doesn't work um but we would have those conversations right with the product owners hey look we deferred this Tech debt it's coming back to bite us now so we're you know we're going very slowly through this if you want us to be able to move fast in these types of areas we have to go address this and at least there I never had product owners that were like absolutely no Tech debt screw you that's

dumb they just said like give me a business case for it if you can explain to me why that's valuable then we can absolutely prioritize it the biggest challenge was that a lot of the software Engineers struggled with that they didn't understand how to put Priority on things sorry and they didn't understand how to put business value on to the the tech net so that it could get prioritized had a brain fart there and so that was like an education thing like hey like if you want if you're if you're frustrated the tech that's never getting prioritized it's because the people that you're talking to don't understand the value of it how do you communicate that to them hey look that feature that you want done we can't get features in this spot done at the pace you want we need more time to clean

it up so that we can move faster obviously it's a very highle example but hope you get the idea okay so if those are the three things you can play with and I just talked about quality we're not really budging on that I hope I hope that made sense the idea would be that and for most of the things I saw where I used to work it was like we have regular releases So This Is The Stuff the timeline's fixed here's the scope then inevitably What would happen so we would agree to it we're like this feels like a plan team's like we think that we can get this work done product's happy with it great we have aign because we're talking we're coming to an agreement about what we want to accomplish people feel confident let's go now what happens inevitably very next day

prog like ah we really got to do this other thing we really just got to add that in okay you want to add that in what comes out right and in the beginning sometimes it's like oh yeah we could probably fit one more thing but what happens over time and I worked at a startup so this kind of thing happened very very regularly there's always something new to add some new priority the closer we got to the deadline the more it was like very adamant about nope like what do you what's coming out you want this thing what's coming out so we had to be very um you know as the engineering side very clear with product like if you want to add more something has to come out and uh by the end so as you're approaching the deadline it was like look if

you are unable to make those decisions about what's coming out and you need it all do we move the deadline because you're either taking something out or the deadline's moving now there were situations where and I've talked about this like in terms of getting like a team to Rally there were situations where the team would go like okay we are going to push hard um we'll make it happen like you you'll get more productivity but like you can't rely on a team to do that continuously like uh the video I filmed this morning was about burnout that is a perfect way to get a team to burnout it's also a way to get a team to like lose uh lose trust in you so as an engineering manager uh I don't want to have release cycles for something and every release cycle it's like hey

team like I know last month we said this is the last time uh but we really need you to go work weekends or we really need you to stay late like you can't do that you can't um but in my opinion if you don't rely on that and you build uh you know relationships with the team members in a way where they really trust you really respect you and they know that you're there to support them then when you have situations where you're like this is really important we need extra help um you know I can I can say pretty confidently that I know team members that would step up and be like okay like I know this isn't all the time but we'll make it happen uh in fact I would say I can say with 100% certainty that I could call up anyone

on the team where I used to work just because we we had a longer period of time working together and you know they they would agree to that right like it's not always oh man I'm I'm waiting in construction at a intersection and this tractor is budding in front of me so the point is for this part of the conversation is that the the scope has to change or the time has to change that might sound obvious but my point that maybe isn't obvious that people don't do is to have a conversation about it um and now I have to stop for the tractor this sucks man so that that strategy worked really well for me which was essentially like kind of forcing these conversations to happen um I recognize that people l this might say well doesn't work here um to me that that

tells me something's broken in the um in the organization right and it it very well might be it might be that like hey like management doesn't care management just says do more do more um that's I mean different conversation about advice for this kind of stuff but um to me that's that's broken it's not sustainable can it happen sure is it okay if it happens every now and then sure but like it can't be a a regular thing this is a absolute cluster sorry the lights out so okay um so some some meta points from this conversation are that when it comes to planning work the the longer out you're planning for the less accuracy you're going to have I would spend less time on any type of implementation detail the further out you're going and also just assume the further out you're going the

the less or the further from the details you want to be focusing talk about strategy if you're talking far out and that way you can navigate the strategy through different implementation details so becomes more ambiguous in terms of how it's going to happen the further out you go so that's one part second part that I wanted to kind of extract from this is like um you know conversations and communication all your soft skills are critical um there are so many things that you can improve or solve just by having more frequent conversations or more uh like targeted conversations about different things so whether that's updates from stakeholders updates to stakeholders um and then I kind of transition that part of the conversation over to like if you're an engineering team like work with your product owner this should be in my opinion you have such

a good working relationship when you can get on the same page regularly and then you can literally plan for these adjustments like it's baked into how you operate that you need to adapt from my experience it's worked really well it becomes more challenging when you have uh accountability or deliverables to other teams so that does become more challenging but you can you can work through the same type of process by by having those conversations with the other stakeholders this person literally has a tinfoil hat I I don't know what to say um 360 cam right that's I'll keep saying 360 cam every time there's weird stuff going on and then maybe for folks that are watching these regularly you can help uh remind me how important having a 360 camel beat uh for showing you guys the ridiculous I see um metap points uh the

three things that you can move right your quality your time and your scope um I I kind of feel like your quality is uh when I say quality it can be interpreted different ways uh I would say quality of what your customer sees should not be compromised I think there's absolutely conversations to have about the quality of uh what your code looks like or the quality of your architecture and people can get mad about it um I get it but the reality is that you can make temporary uh sacrifices there I absolutely understand that you cannot prolong that it's not sustainable either um so if you want to make sure Tech de's getting addressed make sure that you're having conversations in a way with product owners that can understand the business value But ultimately the other two things that you're moving around are time and

scope and um those uh those are things that you have to get product owners and and such to basically have uh like tough conversations about yes it can mean there are situations where Engineers push a little harder but that's not sustainable and the other last part that I mentioned was that if you're in a situation where this is always happening I think they call it like a like death march right I think I've heard I've never worked in the video game industry but I've heard that's very very common but like I don't know if you uh if you can't be part of fixing the culture around that I would say either either you want to be proactively part of fixing that culture trying to find ways to address it or do something different because uh it's not going to change on its own right so

if you're unhappy with it either proactively try to change it or uh find something different I I when I say find something different I realize it's not like oh let me snap my fingers and I'll get employed my point is that if you're going to be unhappy then you should start considering how you're looking for other options that's my point um so anyway I hope hope that was kind of helpful maybe different ways to look at some things in terms of planning out work that's a little ambiguous status reporting that kind of stuff and uh yeah if you have other questions that you want answered please leave them in the comments I will try my best send a message look for Dev leader on social media and I'll see you next time take care