From Reddit: is it normal for software engineering managers to ask for ETAs on research tasks? How the heck can we know the ETA on something so unconstrained?
Let's discuss!
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
hey folks I am just headed home from the office here um it's a long day we're going to go to Reddit um and this question is pretty simple it's pretty short one uh I don't know if I can call it simple it's short um and this is from CS career questions and I would just like to remind people that if you find that my conversations the things I discuss from Reddit are helpful if you'd like to share them back to the subreddit that they're on and specifically the post that would be cool um because I don't want to be self-promoting get banned but if you think it's helpful part of the conversation that's cool this one's titled is it normal If your manager is asking ETA for research tasks as well uh and then the person goes on to say I mean how can you
quote a time if you're learning and implementing that technology for the first time let me know if you've also seen the same in your organization thanks so I think it's a helpful one to talk through um it might not be super common or it might not seem like it is something that you're doing a lot of but I don't know I think that this kind of stuff does come up for arguably like every developer at some point so I think it'd be kind of helpful to to chat through it um maybe give some perspective on why people ask this kind of thing like as from a manager even a a project manager perspective right um uh what's let's address some of the you know kind of defend this person's stance like I based on the way they've written it it kind of seems like hey
this feels uncomfortable to to be proded on this kind of stuff and I think understandably so so let's let's chat through it see what's up um friendly reminder that if you want questions answered leave them in the comments I'll do my best to answer them and or you can message Dev leader on social media it's also my main YouTube channel with more polished edited videos resume reviews which I've been kicking Up A Notch and um yeah if you message me uh directly I will keep you Anonymous so uh that way I don't know you can add a little bit more context for whatever you'd like me to discuss so with that said uh I do have experience with this uh as a manager and kind of like argu like I don't I can say as the engineer as well if I mean it from the
perspective of my own team that I was managing it's a little backwards I guess but uh the context is that before Microsoft I was working at a digital forensics company and um my team did a lot of prototyping and so not only do prototypes kind of put you into a very similar boat because get a prototype and you're like we don't even know what we're building or what this technology is like it's a lot of kind of res research right like uh not not necessarily traditional research uh like you're conducting experiments or something like that but um you know like you're you're playing around with technology trying to sort things out or trying to get business questions answered so that you can make decisions after um so not only do we have that but um my team was also responsible for a mobile acquisition product
and for mobile acquisition in sort of like forensic domain the the ideal goal right is that you and I guess if I back up a notch in digital forensics when we're talking about like hard drives right like um what people would be doing for computer forensics is that ideally you get a bite forbite copy of the hard drive that you're dealing with right if you have a bite forbite copy then it does you could take a hammer to the original hard disk and you're you're good because you have a bite forbite copy um no matter what kind of software tools you're using there's no no risk because you're just no risk to the original evidence because you're dealing literally with a copy um so having a copy bite forbite is like the best spot to be in okay um the challenge is that with uh
mobile forensics compared to like a computer is that with a computer um you can take the hard drive out you don't need to boot off the hard disk uh but with a phone like the drive where the data is is inside the phone so when you need to do mobile forensics the phone is on right there are Technologies called chip off where you can basically um like literally remove the chip from the phone but that's destructive so that's sort of a very last resort but ideally you would love to be able to connect to the phone and get a bite forbite copy of the phone itself this is significantly more difficult than if you were just doing it with the hard drive from a computer and one of the challenges is of course that the phone itself is on it's not at rest um not
making changes or anything you have different manufacturers you have uh different types of Security based on the manufacturer like if we're talking about Android um you deal with phone from different providers who' implemented different things in the operating system like everything just gets really complicated really fast versus you take a hard drive you plug it into a right blocker and you have software that can just copy the bites off the hard disk so my team was responsible for finding ways uh basically our Charter would be regardless of whatever device we're dealing with we want to make make sure that we can get as much as possible off the device as much as possible in a perfect world is a bite forbite copy but that's not always possible so for us it was really about trying to come up with whatever mechanism we could to get
the most and if that meant we could find a way to get a bite forbite copy we would do that oh man there's so much traffic already this is going to be an ABS absolute disaster of a drive um okay so um that meant that we had to do a lot of uh research so um we'd have to go look at a lot of the time to get like root access to be able to get bite for bite copies of things or even just to get onto the device right you have to think about like law enforcement investigators being able to access a device so that they can get uh information off of it there's stories of people who were able to have warrants for phones and they're driving back to their lab trying to keep the phone unlocked right so because once it's locked
they might be screwed uh so trying to keep the phone powered on unlocked that they go get the the information off of it so we're trying to build tools that can help with that and the uh the reality is that we have to explore things like potentially exploits to get Rude access like basically whatever we can try to do that we can explain forensically if we have to modify the phone by the way like the phone is on right so just by nature of the phone being on it's being modified just how it is it's literally running so um a lot of time spent doing research but that meant like how do we know how long it's going to take right so it's the exact situation this person's writing about right you have some research you have no idea how long something's going to take
how are you supposed to tell someone an ETA so I wanted to give you the framing first so that you know where I'm coming from when I go to talk about this uh i' I've spent a large part of my career uh working in situations that have to do with some type of research um okay so at a high level and when I was kind of scrolling through the Reddit thread uh a lot of the suggestions are basically like do your best effort to guess right that's all that anyone can ask for as best effort and then like you know multiply it by some Factor change the time scale whatever basic like pad your estimate and I guess I don't I don't disagree with that conceptually like basically you're doing your best effort to provide some some type of approximation like I don't disagree with
that concept but um I also don't know if it sets people up for success and I mean not not only like the person doing the work but like your manager the product owner your your project manager whoever who cares about the ETA um I think one of the most effective things that you can be doing here is just time box and stuff right and the reason I want to talk about this is like given the fact that have to do research on something right there's something to be proven something we're trying to explore so we haven't figured out yet if there is value that's the point of doing the research right you're trying to make come up with some conclusion so we can have a hypothesis right if we use my forensic example the hypothesis is that we hypothesize given some phone that we can
come up with a way to support getting data off of the phone now in some cases we might have a stronger hypothesis that we could get a bite for by copy of the phone in some cases we would have less confidence and our hypothesis would be like we're hoping we can get anything off of the phone okay but there's a hypothesis and given what the hypothesis is it's a lot of it's very wordy the hypothesis is um there's some value that's associated with that end State now everything we do in software development software engineering is about pros and cons and tradeoffs and a very obvious one in this situation is that there is some perceived value that we could get if the experiment pans out a certain way or the the research pans out a certain way but there's also this tradeoff of time so
to give you an exaggerated example if if we said hey look in the forensic case we want to be able to support getting data off of this phone okay being able to get the data off of the phone would have some value and we're going okay well for this type of phone like what's the market share like how pre how prevalent is this phone actually okay so if it was like an iPhone like that there's a lot of iPhones out there if it's um you know a random Android brand that no one's ever heard of and we've had like you know one law enforcement agency ask us about it might be lower value still some value but it's all going to be something that we want to be able to try and quantify so if I said Hey look it's going to take one engineer
2 years to be able able to even get some data off of here off of the the one device that's like you know one agencies asked for they might be like well no way that's it's such a waste of time and I'm saying I'm giving you an exaggerated example to prove the point be a waste of time because in two years that engineer might be able to deliver so much other work versus just being able to support getting something off of this phone if we use an exagger the other way hey look um this engineer could take one month and we're we have a high degree of confidence that we could get every bite off of this iPhone which is a lot more prevalent someone would say hell yeah like go put that engineer on there for one month if it takes you four months
if it takes you a year it might be worth it because it's going to have such a big impact because that device is so prevalent and we're hypothesizing in that you would have all of the bites off of the device so when I'm thinking about this kind of thing it's really about like what is our hypothesis on this but the reality is we don't actually know how long it's going to take but in our minds we might be able to come up with a I just spat everywhere don't do that um we might be able to come up with a an approximation for how much time we would be willing to spend on this and that's where the time boxing comes into play so for us this worked really really well because you know I'm going to use air quotes here we were agile um
on our team like when I say we're agile I mean like uh not specifically like the methodology kind of thing not necessarily can ban or scrum or anything but we literally just operated with a lot of agility um very Nimble if you will and for us that meant that we would revisit priorities very frequently so if we were to time box something and say hey look we're going to we're going to let someone focus on on this for the next the next uh two months okay that's going to be our time box we understand that there's going to be a bunch of uncertainty we don't know here but we think that if we could do this and it was going to take us 2 months like we would feel like that's a that's a good trade and then what might happen is that a couple
weeks into it we might have a different data point in that work to be able to say one way or another a month in we get two months in sometimes there would be situations where we're like hey look we've made a lot of advancements here but like it's not done and then because we have been evaluating our priorities as we go as as a small team it's like well if there isn't another priority that's come up and we feel like we're still making advancements here like we're not done but we also have a few more things to explore we might say well hell yeah keep going right we'll we'll add a new time box we'll give it another another two weeks to see if we can kind of get that through that next Plateau but all of this is a conversation like with me as
the engineering manager with the Engineers on the team that are working on whatever the the thing is and with the product owner so everyone has alignment on that it's not just the engineer going I don't know it's going to take me however long it's not just me as the engineering manager being like I think that Bobby should work on this for another however long it's not the product owner just dictating it's all of us coming to an agreement and just having an open conversation about this stuff so I think you know some of the bias here is one of the reason this one of the reasons I feel like this worked really well for us is because we were constantly communicating and trying to get alignment I feel like without that some of these decisions would not be as easy to to have but time
boxing for us was really really valuable and that way we didn't have to like force people to come up with an ETA now now to kind of circle back on why people ask for this stuff or or even I'm talking about time boxing I'm not saying that people never you know therefore no one ever asked for an ETA for status updates we still did we saw conversations about this stuff but it was to assess if we were making forward progress and if we needed to rep prioritize right so yeah it might be let's again contrived example we're on a two Monon time box and we're we're two weeks into it and the product product owner might be having a conversation with us in the standup talking one of the engineers and being like hey well based on where you're at so far like well what
are you thinking like it's a two-month time box like how are you feeling about that like do you feel like you're making progress on that or do you feel like basically based on what you've seen haven't even started right like there's been zero progress cuz everything that we could have been exploring is just like roadblock instantly so that conversation would happen maybe another two weeks go by another conversation happens but we're just using it as a checkpoint right so one of the one of the reasons that we use things like etas at least from my experience is less about trying to there's literally nothing in front of me this car needs to get the sensors changed um one of the reasons we ask for etas is not to like enforce like or um not to enforce not to make people like fearful of deadlines and
stuff like that it's to get conversations going I'm not saying this is the same everywhere so if you're like Nick that's not how we work and you're lying like I'm not I have no idea how you guys work I'm just telling you what worked for us and why we did it um and I still do this today right I when I ask for etas and I'm talking through stuff with Engineers I'm just trying to assess if people feel like they are on track for what we've discussed and if not for any reason it could be because you're going faster if you're on track or not because I want to understand if we need to make adjust that's all so in these situations like the way that I I kind of think through this if uh if I'm having ETA conversations with people on my team
I'm just using it to be able to to figure out like you know uh let's pick another example so I guess everything's about research in this context from the Reddit post so um we've made a claim about some ETA right and I don't even know if this example is going to make sense um coming up with stuff on the Flies hard because everything I've been talking about is like I've been saying I time box things that's I'm kind of like avoiding the ETA conversation uh that's set outright from the the Reddit post okay let's let's forget the time boxing for this example we haven't time Bo anything someone said you want me to go do this work and I have to research it it's going to take me it's going to take me 2 months so when we want to talk about etas of things
right like the first part is like that first ETA of two months so I would go back to what they were saying uh some points on the thread is like if you just have to throw up a an estimate like I would say it's a best effort kind of thing and I guess I've had conversations like this with Engineers right um the way that I frame this kind of thing this is going to be even outside of research by the way just like for more open-ended tasks I would say like hey like what's Your Gut feel for this right like I don't I'm not going to carve it in stone and I will tell people like I want to talk about this not to make you feel like what you say like I'm going to be chasing you down and make sure you deliver on
that day I want to hear what you have to say because I want to see how you're thinking through what work might have to be done right to give you an example I've had conversations with Engineers where um we're specking out some work for them to do and say like you know from from your perspective you know what's your ETA on being able to work through this I've had someone coming come back to me and tell me like multiple months for something and I'm going hold on like I'm not the one implementing it I don't know the code but based on what's being discussed like I cannot I cannot comprehend a way that something would take multiple months here there's I can't I can't rationalize it so that's not for for me to go tell them nope sorry wrong answer you're wrong all right I
asked them for an ETA because I want to understand how they're approaching it so then we get into a conversation and say like okay well in my head maybe I was thinking it was a week a week of work two weeks of work they're saying months so okay like walk me through like walk me through what you're thinking and I've uncovered things where it's like uh either testing validation spec whatever U where people are allocating significant amount of time and I'm going nope like we actually already have the answer to that or or no we don't have to dedicate time to coming up with that because in parallel someone else like we can have uh you know kind of pull that data and get you what you need right we don't have to like serialize that work and it's certainly not going to take that
long either because we have a dedicated re that can do it so you know it's not that that person was wrong in their estimate it's like it's just what they were factoring into that so A my my meta Point here is that like when I'm talking to Engineers about etas for things it's to really try and pick apart what's going on and I'm not I'm not saying it's it has to end up being done by that date or else because I also recognize that with software development things change all of the time so yeah if you want to bake in some buffer for some uncertainty like do that for sure but call it out say yeah and I think like you know I might need a couple of extra days here uh for some uncertainty that might come up based on these things that we
haven't seen yet cool and even if you like didn't account for something and it's taking longer than expected I'm having checkpoints with you along the way right we're talking with the stakeholders to make sure that we're going yep we feel like we're on track and if not that's okay like let's talk about it because if we don't know that you're off track we can't make adjustments so again I like etas for just like getting that that common shared understanding I think this person beside me is trying to like match my speed awkwardly I don't have the 360 camera on super awkward though especially because it's a Tesla anyway um but yeah I I guess if I'm starting things out with engineers and asking for etas it's uh so kind of get a gut feel right let's talk about what you think is involved here are
we on the same page are we even talking about the same thing and then go from there right we use you know if the ETA is changing along the way let's talk about why there's going to be situations where like if there's a deadline where we have to get something in place then we're talking about scope right so if we need if we had a a deadline that was 1 month out and we're 3 weeks into the thing and you're telling me like man I'm not even halfway done obviously by that point hopefully we have a better idea but it's like okay well what can we do like what scope do we have to cut back like what's our damage control here what's our mitigation strategy right because if if the deadline's fixed then the scope has to be adjusted and if the scope is
fixed sorry this Tesla is just like the absolute worst now this other car um if the scope is fixed and like we can't we can't ship until we have all those pieces then it's like then we have have to move the deadline so like having the ETA and being able to revisit it I think is actually very helpful but I think there is this I don't know like people people use etas in different ways and I've just seen it be very like I've seen it be very ineffective and people get fearful of it because then it's like this you don't want to say a number that's used against you which I totally get someone says what's the e ta and you say something and then it's not that now you're in deep like that's not like that's not how I want to operate I don't
want people to to be fearful of that because then they're never going to tell me uh they're never going to tell me what they're thinking right oh it's yeah that's going to take six months yep it's a oneline change it's going to take six months why oh just it's a it's a number that I know for sure I can't can't possibly screw that up right it's it's Suddenly It's not a helpful conversation anymore so I don't know like that's why how I use etas but um in particular around the the research stuff I can absolutely understand why people would be like I just don't know and that's why I think time boxing is actually very helpful like let's let's go back and say how much would we be willing how much time will we be willing to allocate to this before it starts not being
valuable another thing that I'd mention here too is like I find that the more this is generalization but you know if you're in a space for or like a domain for a longer period of time and you've seen enough stuff that's similar you might start to have an idea right it's kind of like forecasting based on prior experiences you know I don't know the answer to this but we've seen work that's kind of like this before seen a couple of examples here they are and they took you know this one was 3 months this was 4 months uh that other one was like super super challenging that was like nine months of work we had one that we thought was super tricky but it was actually like the easiest one it was only like two weeks so overall like we have a two outliers on
either side H you know maybe 3 months maybe 3 months is what I feel here right and like I've just tried to rationalize to you how I came up with that and then we can have a conversation like if you're like well that seems outrageous these aren't these aren't even comparable okay well let's talk about things that are right we don't have anything comparable okay then we can't forecast that way let's time box it so I I don't know it's uh I realize I'm like probably making it sound like it's oversimplified I don't I don't mean to trivialize it but um an ETA in my opinion is a tool and when you start using this tool in a really weird well I shouldn't say a weird way probably the way that most people expect it to work I just don't think it's an effective tool
it's an estimate right and like things change so I think that's my thoughts on etas um especially around research tasks you know the big uh Big Challenge there is it's it's unbounded so scope it that's the time box um I've said this in other just I'll wrap up this thought but I said this in other videos when I talked with that team that I was on there'd be times where we would do an experiment or research on something and it would be time box and we would reach the end of that and we'd say well we don't have an answer so like but we've reached the end of the time box other priorities have come up okay we'll park it right record what we learned and uh I wanted to share too that like in situations like this sometimes people feel like they failed and
I think that's an maybe like an important thing to bring up too is like when we're talking about research tasks um it's research right like you might it's there's a lot of uncertainty it's unbounded I think that people have to be prepared in these situations that there could be an outcome where there isn't success at least not traditionally right you might not arrive at a solution where you're like hell yeah that's the thing we did it or we know conclusively you might arrive at a solution that's like we don't have an option here we don't have an option we feel good about based on the data and what I wanted to kind of share here is that I know that from having teams that operate this way that can become very demoralizing when you have PE sorry I have to yawn I was holding it
in that can become very demoralizing when you have someone that's been doing a research task for a while and then doesn't have success uh and then they're on another research task and it doesn't have success uh and then they feel like they don't have momentum but something that's important to realize is that when you're doing research tasks you don't necessarily control what the outcome's going to be right if I said you know your task with finding an you know a library that does X Y and Z and it needs to have these performance characteristics like that's your research test you might go do research and say like I've scoured the internet I can't find anything that does that here's the test that prove it like I've done run the benchmarks I've you know tried to evaluate different criteria that we looking for there's simply nothing
out there that does it like I may have given you constraints on something that the reality is there isn't something but guess what it's not doesn't mean that the overall effort was a failure maybe if we didn't time box it and you spent two years on it maybe we could consider that a failure not a good use of time but if we've time boxed it and you don't come up with you know the answer we've at least collected data we've learned something and I think a lot of the time people forget that when you're doing research like the the shared learning that you can bring back to the team can be very helpful back to the forensic examples um like plenty of situations on my team from before where um we'd go back and revisit something after gaining other knowledge and then we would have
unblocked ourselves right so we didn't have all the knowledge we needed at one point but by doing other things and revisiting we break through barriers and then we end up you know Landing things that are very impactful so um you know just just an example of like the the success can come in the learning it doesn't have to be you know absolutely attached to coming to A a successful conclusion in the research right so uh I think it's important to remind people of that because it can be very demotivating we always want to come up with that you know that awesome result at the end but sometimes it's just not there and I think that's it as I pull into the driveway we'll get parked here yeah no 360 cam because it's been raining and crappy but that's uh part of living out here I
guess okay thanks folks I will see you next time and just a reminder if you want questions answered leave them in the comments or message Dev leader on social media and I'll keep you Anonymous I'll see you next time 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.
- Is it normal for engineering managers to ask for ETAs on research tasks?
- I think it's understandable that managers ask for ETAs even on research tasks, though it can feel uncomfortable because research involves uncertainty. From my experience, asking for ETAs helps start conversations about progress and alignment, not to enforce strict deadlines. It's a way to assess if we're on track or need to adjust priorities or scope.
- How do you handle providing ETAs for research tasks when the timeline is uncertain?
- I recommend providing a best-effort estimate based on your gut feeling and prior experience, but also being clear about uncertainties. Time boxing is very helpful—setting a fixed amount of time to explore the research before reassessing. This approach allows us to manage expectations and adjust based on what we learn during the research.
- What should engineers and managers keep in mind about the outcomes of research tasks?
- It's important to remember that research tasks may not always lead to a successful solution, and that's okay. The value often comes from the learning and data collected, even if the hypothesis isn't proven. Time boxing research helps prevent wasted effort, and sharing what was learned can unblock future work and lead to impactful results later.