Deadlines & estimations: What do I do with them?

Darren: Okay, let's get started. Hello, everybody. Welcome to Codementor events. And thank you so much for joining us. My name is Darren, and I'm going to be your host. Before we start, I just wanted to quickly point out that this time we're using zoom webinars, instead of zoom meetings. So the interface is a little bit different than what you may be used to.

Darren: There is a dedicated Q & A feature, which you can see on the bottom right of the screen. So please put your questions there during the talk and you can also upvote other people's questions. We'll get to them during our Q & A time.

Darren: All right. Our topic today is as you can see, “Deadlines & Estimations: What do I do with them?” We have a real treat for you this time because we have not just one, but two great speakers lined up, Vitaly and Rene, who will each give a talk about this topic. So I'm going to introduce Vitaly now, as he will share with us first.

Darren: Vitaly he is a developer advocate at Qase, and he has over 20 years of experience in the industry doing programming, leading and mentoring teams. I think he's the perfect person to share about the why of deadlines estimations from a manager point of view. So Vitaly, I'm going to turn it over to you now.

Vitaly: Thank you, Darren. Thank you so much for such a kind introduction. So yeah, I'm going to be sharing my screen. Hold on a second with everyone share screen and that's it.

Vitaly: And here are my slides. So yeah, my talk is called the “Rationality of Estimations. Why and why not estimate?” First, something about some info about me. I'm 37 years old and 20 years out of these 37, I've been in the industry. So it's pretty much the whole, whole, my life. And I'm really passionate about doing proper stuff rather than doing some waste or Moodle, how they call it in Japan.

Vitaly: And I've been doing 13 years of JavaScript, then seven years of team leading, mentoring teams and teaching teams and consulting companies. And now I work as a developer advocate at Qase. So my talk is about estimations. We are all used to seeing estimations and forecasts. When we check what to wear, when we decide what to wear tomorrow, we check the forecast, the weather forecast and the weather forecast is actually a prediction of some sort.

Vitaly: And these forecasts takes a huge, huge effort. Here's K. K is one of the top 500 supercomputers and pretty much every single super computer was built first, or maybe one of the reasons why it was built, to serve as a number crunching machine for weather forecasting. Why that? So why is spending so much effort and money and budget and time and everything on actually predicting weather?

Vitaly: Well, actually, because more accuracy saves money. So if you're, if you're seeing, if your data showing that there is a hurricane or tornado or something else coming to the region where your cargo ship is actually in, chances are you won't let it go. You won't let it into the hurricane or tornado. You'll try to optimize the route of the ship. So it doesn't sink. All you're just not going to be flying to a different continent if you see that the weather is bad. Or you won't send your jet or your plane to some area, if you see the weather is bad, the conditions are bad.

Vitaly: I think pretty much everyone experienced a delay in a flight due to weather conditions. So in some applications, forecasting is essential and critical, and there are even programs which are installed in some medical equipment, which are trying to forecast the condition, the medical condition of a client of a sick person. And then you administer some different drugs or whatever. So what about the IT? We're all used to do estimations. I've never seen a team pretty much never seen a team who doesn’t do estimations.

Vitaly: And as I say, estimations is a forecast. We can’t for sure say how much time it will take us to deliver a feature. The only proper data, the only proper information about the time, how much it will take us to do a feature we can collect during the feature building process. So whenever we've done the feature, we know for sure how much it takes, it took us. And so I've actually made a huge poll in Russian IT, asking why managers demanded estimations. Why managers asked for estimations and forecasts from their teams. First reason is to see team load capacity. Second one is that public standard or governmental contract requires estimations.

Vitaly: And then there are three reasons, quite strange, but think they are put like that manager needs to know when a feature is to be done. Manager needs to understand how much a feature will cost and managers need to be able to choose between feature A and feature B depending on the cost. Actually those five reasons they boil down to three, to see team load or team capacity, or when the company operates with governments or some other body, which requires the estimation or just manager wants to know the estimate for pretty much any reason. I'll talk later about it.

Vitaly: So I've marked headers with red, where I see that, where I did, where I, where I think that estimations are not rational. So whenever a manager asks estimation to see team load, he or she thinks that if team finishes tasks on time, maybe we can throw more. So managers tend to overload teams. That's quite quite a usual thing. Managers usually want to get as much return of investment on the team as possible. And I rarely see a manager knowing the philosophy, sorry, the psychology of labor or the ergonomics of labor, how actually our human body and mind operates under stress. So the science says, that overload in labor, in intellectual labor is counter productive. We've all been in situations where we are overloaded with work and we're struggling to pick a task to do. We're burned out. We can't think properly. We can't think rationally, and we're doing some bad coding than bad decisions. It is interesting that load essentially does not equal to result.

Vitaly: So in physical labor, we know if we chop wood, we will have enough wood chopped. In intellectual labor, more we load less we get. So there is a fine line where load, where there's just enough load for us to process. And so if a manager looks at estimations as a measure to see if the team is underperforming or can be loaded with more work than the manager does a bad job for, for them. Because, once again, they are overloaded, the guys are overloaded and they will do less.

Vitaly: So the recipe here is to actually do less, rather than do more, but do less rationally. So if a product manager brings you 10 tasks, it's more optimal to decide a few of them have higher value and focus only on them rather than do 10 of them, all of them. So if you can talk to your manager to actually see what's of higher value for the client, it's better to do that, instead of doing everything, hoping that the client will like everything.

Vitaly: And there is also a recipe of redoing less. So there is this concept that out of testing automated testing takes the time it takes time and it costs a fortune. Well, actually not. We are testing our software in our head. Every time we compile it. And every time we run it. So whenever a regression appears, if you write a test tackling this regression, you are saving yourself a lot of time. So later you will have to redo much.

Vitaly: Okay, tender contracts, governmental contract. Client, the government or these body that requests an estimation from you. They know the value. So if it's a, let's say a rifle designed specifically, it is usually designed by a client. And so they know the characteristics of this rifle to actually work for them. So they will only bargain. They will only negotiate on the cost of the production. So then they will require, they will request an estimate how much time and money it will take you to build this rifle or software.

Vitaly: So if we look at this from the theory of constraints perspective, and I highly advise everyone to read it out, Alan Schuller was a genius. So not all sugar comes from under the name of the inventor. Time constraint is an external one, so we have to expose our predictions and estimations on how much time it will take us to build the software to the client.

Vitaly: And what's interesting that there is this huge body of knowledge a PMI, project management Institute, which certifies project managers, who are assumed to have enough knowledge to predict how much time the project will take to build. And yet BMI's own information and statistics show that only 30% of projects run on time on budget, which means that apparently this whole approach is not that efficient, but anyway, if you run governmental contracts, you will have to predict how much time which will take you.

Vitaly: And then you can imply any big methodology waterfall methodology, they call it, to satisfy the requirement. And then the biggest one is when will it be done? That's the question the managers love to ask. And my thesis here is that most often this information is not needed at all. Usual excuses or usual reasons why managers asked these question is that, oh, we are going to be having a marketing campaign on the 1st of January, let's say, or on the 14th of Feb for the Valentine's day. And we need to know for sure how much how many features will be ready till then.

Vitaly: There are interesting consequences of that, that the code quality will be get will be much lower if we try to feed features til that date, because we're going to be handling our constraint of time. But even more, why can't we just build something and then marketing campaign depends on us and advertise what we've built. Why can't we advertise only things that are ready and why can't marketing team than just enable them using feature toggle on the server. So this situation where the IT department is depending on the marketing department is a status quo. Yes. We're all living in this scenario, but is it all right to have this? I'm not sure. And also managers sometimes say, okay, this is an external event. FIFA cup is going to be, it's going to be having our city costing the event. Fine. That might happen. But then how many times during your business life do external events like that, that requires estimations happen, rarely. And if they happen often, maybe you should employ some different way of working with your IT department.

Vitaly: So let's say fire brigade, a typical fire brigade has only 10% utilization. So firefighter sit on their desks, by the desks, nine hours out of one, just to be able to handle critical situations like that, an external event, a fire. So, if your line of business, if your business model, if your business, whatever demands you to respond to critical events, maybe you should hire them much more. Maybe you should hire five times more for people not to be over utilized and then having no time to actually do anything, but maybe they can be just free most of that time.

Vitaly: So that whenever an external critical event happens, you will have enough time for them to respond. And then there is this even, even better one. How much does the feature cost? Managers love to ask this. So whenever we come, I have this good analogy. Whenever we come to a market and here's a picture of tomatoes, we see tomatoes and we see the price. So first we know the value of the tomato. We know the nutritional value of it. We know that we like the taste. We know that we want to consume it. We are sure of the value. And then we decide which tomatoes to buy, comparing the prices. So once again, we know the value and only then we pick the good for the price.

Vitaly: So if we didn't know what was there. Would we change? Would we check any prices? Even some said six pounds per a box. Would we actually compare the prices? If we don't know the value, we can't compare the price. And there's this good screenshot. There are cases when people try to purchase something on the internet based just on the image of it, on the picture of it. So my roommate ordered a TV stand on Amazon. This is what came, a toy one. So the value is not obvious. You're just looking at the picture and you're buying it. And then you figure out that the, the, the thing itself is not suitable for your needs. There was another one that nephew wanted a converse backpack for school, and the bag size was just fit for the cat.

Vitaly: So why am I showing all this? Because we must first know the value and only then, we check the price. What does it mean in IT? That if we don't have value forecast, value estimate, we should not do any ghost cost forecast or estimate. Let's see the example, it's very simple. So a product manager comes to us, says, okay, have these three features, feature square, feature circle, and feature triangle. And feature square, he says, we'll estimate us a revenue of from 50 to 90k to $90,000. Feature circle will estimate us a revenue of 150 to 200 and triangle from 300 to 400. Then he asks us for estimation for our cost estimation. So he wants us to find out how much time it will take us to build those features. And we provide that.

Vitaly: And I'm showing quite a good example of both products being able to forecast the estimate of a feature and us being able to forecast within a certain range of quality. So we say, we're saying that square will take us from 10k to 40k to build circle from 15 to 30 and triangle from 22 to 24. So using this table, we can kind of understand that it seems to be obvious this we should run for triangle feature. Because in the worst case scenario, each will yield us 10 times more than we spend.

Vitaly: So what happens next? Reality strikes. So we see that square actually yielded us only 90K, which is, which is good. It's within the estimate the products provided. Cost of square feature was 13K, again, within our estimate. With circle, we got two hundreds. That's good. costs still, still good, but triangle failed. Why it failed? Because the product estimated it wrong wrongly. So, regardless of, I mean, it doesn't matter that we spent more time than we actually predicted we would spend on building it. The failure of the estimation lies in the revenue estimation in the value estimation. So we could have spent, I mean, if the product estimation was correct, we could have spent 10 times more money on building the feature and we would still be profitable with this feature.

Vitaly: So I'm here with this two imaginary example, I'm showing you the value of the forecast on the product side. So I think that it's very important for us to make sure that we optimize forecast of revenue, but not the forecast of cost. So once again, if we don't know the value of a feature, if the product team or product manager can’t show a proven history of success in estimating the value of a feature, it doesn't matter if we do estimates on our side or not. And so if there is no revenue forecast, then we shouldn't do any cost forecast. If we can't see tomato, these or something else, we won't compare the prices.

Vitaly: And what do we do with all this? Of course, we can become enemies with a product manager and tell him, mate, we won't show you any estimate on our site. I mean, if you don't show us estimates on your site, if it's your Wilde's guests, that this feature A will bring us this amount of clients or this amount of money, we're not estimating our work. But I will always advise to become partners rather than enemies. So why do product managers or team leads demand estimation. Because they are afraid. I think they are afraid that they will be asked on return of investment in the team. They are afraid that they will be asked what's going to happen with the features. So they don't know how intellectual labor works, that we can't predict things properly. And he can't, and the manager can't predict his work properly too, because we don't know if our feature actually will be liked by clients.

Vitaly: We can do certain amount of work to figure it out to a certain degree, but we don't know for sure if the clients will want this feature or not. There are plenty of startups going bust going broke, just because they failed to understand the product feeds of their business. So they came up with an idea, but the clients didn't want to pay for the results. They didn't want to pay for the product. And that's alright. But again, proper partner relationship means that we are equal in this situation. And so if the product cannot predict how much money or value the feature or the project or an epic or a story we'll bring, he has no rational reason to ask how much time it will take us.

Vitaly: And yet, again, partner not enemies. Let's not just say we won't give you estimates. Let's try to figure out how to help him or her, help the manager that we engineers can help the managers technology that have attends. We can help him or them with AB testing with building something really, really, really small, like iterating within a few days only sitting closer to the client.

Vitaly: We IT guys can ask a manager to give us a client representative contact and the work with that client representative. That's why all that agile and scrum and all those frameworks were kind of invented for, of course, they all now getting south where, and, we'll talk about that as well. How scrum fails us sometimes, but anyway, we can iterate smaller. We can help managers with their discomfort, with their fear by showing how we work. We can then work in smaller iterations, ask to work closer to the client and deliver AB tests. I mean, when I used to work in Badoo, for example, in huge dating we're ran very small fraction of users in our AB tests, we gave them new code. We saw how those users behaved with the code. If it proved to be okay, if it proved to validate the product hypothesis that this new feature will actually succeed with them, run it properly with them, coded it properly with real way. The proof of concept work because it's proof of concept. The code is the code quality is bad and we built proper features.

Vitaly: Or for example, same case in Badoo. I had mobile web team where we ran AB tests, which then became hypothesis, proper hypothesis for iOS and Android team. So before investing into costing a lot into something, that's costing a lot, you can do it in a throw away manner. And also from the estimation standpoint, you can use stats. That's what kanban is all about. There is this huge area of kanban, statistical analysts, it's called, I think. Where they show, they show that our team usually like 80 percentile of features is done within two weeks. Is this information enough for most managers? For the financial planning is more than enough.

Vitaly: So if we see that our team delivers on average, not an average, like median percentile, 80 percentile, features is delivered within two weeks, management, top management can decide how many more teams we need. Of course, nine women can't give a birth to two kids in one month. They will be communication, synchronization costs, et cetera. But again, for the top management analytics and statistics will be enough. So if we help the manager fight his or her discomfort and fear. And show them how we can help them with the technology we have with the processes we, we can, we can invent. It might be beneficial for both the manager and the team because estimates, they have side effects.

Vitaly: We're never talk a lot about that. And I will just briefly say what I witnessed that any estimation from IT, from product, from whoever in the company, is always considered a promise always and always. Whenever you say I'm going to be, I'm going to build this in three days. You mean usually three working days it will take me to do the coding and maybe the testing as well, maybe the deployment as well. But then again, It's always perceived like in three calendar days, users will be using this new functionality, which is not always the case because you have all the tasks, you have all the duties, you might get ill, you might get hit by a truck, whatever might happen.

Vitaly: So always estimations are considered to be a promise and promise then becomes a deadline. And if there is a deadline, then Goodhart’s law says that whenever you pick any measurable metric and use it in your management, that's the metric that the people will tend to hit rather than clients value to hit. So whenever you say lines of code should be more and more, you should like produce more lines of code. That's what you're going to have. If you say clients value is the goal, then that's what you're going to have.

Vitaly: And so if you have team KPI's or team let's say measure it by how accurately they run estimations and how accurately they hit deadlines. That's what you're going to get. You won't get client’s value. You will get either people adding margin on top of every estimation to make sure they don't fail the estimations. They don't fail the deadlines. Or you will have people burning out. And if people are burning out science, once again says that there is no proper intellectual labor under stress conditions.

Vitaly: So deadlines hurt performance, because people can't perform well under stress. It's like the proverbial two-week sprint. Every two weeks, you have a stress of a deadline and deadlines hurt quality. Because if you have someone really wanting to deliver on time. This person will decrease the quality of code even irrationally, just to make sure, oh, I won't test this one, it's obvious. Let's just deliver it to the client. We'll figure it out later. So deadlines do hurt quality. So again, estimations have to be done only when there is a proper value for the estimation when you need to do this. And there is very low chance that a proper business will have a real need for the estimations because when you have them, chances are the problem is elsewhere.

Vitaly: And with that, I think I'm done. I have my Twitter, Telegram, Email and Github, feel free to subscribe or whatever with it. And I will possibly talk to Rene and he will talk a lot about the consequences of estimations. Thank you.

Darren: Okay. Yeah. Awesome. Yeah. Thank you so much Vitaly for sharing with us, and I think it's really helpful how you organized the arguments for estimation and I kind of just dealt with them one at a time. So I think we just have one question in the Q & A right now for Vitaly and, yeah, and don't, don't worry because we'll have a longer Q & A at the end after Rene shares with us.

Darren: So let me just read off the question that we got. So it's from an anonymous attendee. it says, what should we do if managers keep pushing us on having a clear estimation? What sort of responses should we give them? Maybe Rene is going to touch on that later, but, but yeah, Vitaly, feel free to throw out some thoughts.

Vitaly: Thank you for the question. It's a great one. I could wrap it up as change your company or change your company. So you either try to change your manager or you just change the company. So I succeeded in cases like that when I built proper trustworthy relationship with my manager, showing him the time vulnerable that I can fail, that I'm a human and showing him that if he can open up to me, if he can explain why he needs this estimation, I might help. Not with the estimation itself, but with the problem. Because you know, there was this anecdote that someone is just looking, under the electrical light, looking for something, and another person asks why you're looking, what are you looking for? He says my keys, but where did you lose them? Oh, it's back there. But my looking here it's lighter here. So we shouldn't look for something where it's lighter. We should look for something where we lost it. So if a manager wants estimations, there is a reason for that. And if you, if you are able to build a relationship with a manager where you will understand what the reason is, maybe you can help with that reason.

Vitaly: Saying that. There are “lost” companies, companies which are unable to change, because culture company, culture changes people a lot. It does. So there are companies where something is so deeply rotten that you can't change it. And managers there just say things like I'm telling you to give me an estimation. That's why you need to give it to me. So if you have a manager like that, leave.

Darren: Yeah, thank you so much for the answer. As I said, we'll continue to Q & A at the end of the event, and you can continue to ask questions in the Q & A section. But now since we're moving into, Rene's talk, like if you want to ask a question that's specific to either Vitaly or Rene, make sure you write down their names along with the question, for example, like this is for Rene, this is for Vitaly.

Darren: Okay. yeah. Now I want to introduce our next speaker, Rene. He has had over 10 years of experience as developer, and now he is developer advocate at Ombori, focusing on the developer experience. He's going to share with us his personal experience, dealing with estimations and deadlines and what he has learned from the experience. Okay. So without further ado, Rene, I'm going to give it over to you.

Rene: All right. Thank you so much. Let me just share my screen here. and we can get started. There we go. All right. So how not to deal with estimation? That's the title here and I'm going to go ahead and share one of my experiences I had as a developer.

Rene: But first I want to introduce you to this quote from Douglas Adams, from The Hitchhiker's Guide to the Galaxy. Like”:I love deadlines. I love the whooshing noise they make as they go by.” This is very typical in software development and this should always take a deadline with a grain of salt. But of course you have to be explained, like that's not always how it works. So first, who am I? My name is Rene Pot. I'm a developer advocate at Ombori. I've been a JavaScript developer over 10 years and I've started programming, well, first HTML of course, but then PHP when I was 12. So overall more than 20 years of experience as a developer, but professionally like 13 or something.

Rene: You can find me at the nickname you can see there is “@Wraldpyk” it's from a very obscure frisian language that no one knows, but I use it as a handle. So, let me start and let me tell you a story of my experience a couple of years back at a company where ironically, I didn't stay long, and you'll soon find out why.

Rene: So first let's go to the conference room because everyone is going to have to estimate here. and that's how our typical schedule was. And it was a little, it was offset a little bit. So we started on Friday. So after the estimations, we had a weekend to, I guess, mull it over a little bit, think about it. My boss also took a little bit of the weekend time, so I could after we did our estimations, my head could go spinning and prepare for the Monday.

Rene: But then when I started that company, I was like, okay, this is like to give you a picture just as a startup, 20 people, a couple of developers come marketing people, a design team, everything like they were just funded, in an accelerator. So it was like this, the speed was high that's. I mean, that's the general gist of a startup. I'm going to start it now, but the speed is high too. But it's much more relaxed, even though the speed is probably higher than it was there. And this is all due to the estimation cycle.

Rene: So Fridays we've started sprint planning and the sprint plan typically looked like this. Even though we were like five or six developers or something, we had probably a hundred different post-its, maybe more, on a board where everything, every task was split up into as many segments as possible. So each task was no longer than a couple hours. Like if it took more than four hours, split it up and we can see that we can distribute it, that we can keep track of it.

Rene: And as I said, when I started, it was like, okay, I'm amazed here, how these people understand how to estimate and how to do things. So this is the trap I fell in, right. So Monday through Thursdays, we had daily stand-ups every morning, probably around 10. I don't even remember at the time it was, but it was I'm guessing around 10. We stood together in front of this board, with hundreds of post-its and everyone talk about tickets that were in progress. Everyone talked about like the typical scrum things, blockers, what are you going to do today? What did you do yesterday? Like those kinds of things, and this was probably the company that followed scrum to the letter. They did everything scrum tells you to do. and I thought, oh, this is cool. Everyone knows what they're up to. The design team knows what's happening. We know if we have blockers, like you name it, everything was known. So daily stand up, talked about everything. And that kept on going.

Rene: It looked a little like this. But then, our board was a little bigger than this. Let's just say a couple of meters wide anyways. This is how I felt. I felt very organized. I knew exactly what was happening and. Okay. So on Friday we of course had another stand up. and we had a halfway check-in like, are we on schedule? Are approximately half the tickets going to be moved to done end of this week? And typically the answer was, no. No, we have too many blockers. There's some tickets that kept hanging in the to-do list that should, should've been done probably earlier. So like, how do we, how do we handle this? Like, what do we do? Do we kick tickets out now? So the halfway check-in was typically a two hour meeting about which tickets should be moved, which tickets should stay.

Rene: And often it was decided that we should probably do more than we did this week. Next week, we are gonna focus more, make sure that we do the tickets that are necessary to deliver this feature at the end of the sprint. And as Vitaly said, like, why do we have to deliver it at the end of the sprint? Well, that was something that was in the air. This is what our tickets turned into. And not necessarily in the shredder, no, usually they ended up on a pile that were revisited in the next sprint planning if they were removed, of course. So then Monday through Wednesday, the next week, we had our daily stand-ups, daily routine, nothing changed compared to first week. However, the pressure was higher because there were more tickets there were left than there should have been.

Rene: And then another third on the last day of the sprint, because we were offsetting by a week. We have the last day of sprint standup. So it was more like a wrap up here. And then, then about four o'clock in the afternoon, we had a retrospective we all sat together in a different room. Discussed things casually, told what went wrong, what went right, you name it. Like all the things scrum writes, all the things scrum says you should do. And in retrospective, we did. And if we made our sprint, then we would get a treat like, a good job you did this week, well, here's a glass of whiskey or here’s a nice chocolate bar. We were rewarded for making our sprint.

Rene: And this was of course meant as an incentive to deliver higher quality work and go faster. But of course you already know this is not the case. I lost my mouse. There we go. So, yeah, sprint in a nutshell, we missed it.

Rene: And honestly, in the period I worked there, I think I got like, one or two rewards. So you understand, we never met, we never made it. And then we were Friday again. So things repeated again. And again and again, so it's all groundhog day. And that's my typical, that was my typical schedule. And you think, okay, so this is great. A company knows what we're up to, tickets for moved halfway. Everything went well like it communicated. We probably even deployed on Thursdays, and this was sort of true, but what happens typically was overtime. In order to make our deadlines and in order to make the tickets that were planned, we went to overtime and so in the period I worked there and it's about six months. I've stayed like six, seven times, during that period. And I'm like, how many sprints are there half a year, like 16 or something. And we offset that probably a little bit here and there. Like Christmas time was one, it was one less. So half, let's say half the sprints I worked overtime. and a couple of times we even stayed until like 10:00 PM.

Rene: They gave us dinner, which was nice, but, that's not something I want to exchange for overtime because we didn't get paid more, because we were a startup, so it was tight budget. So now the question is now that you know how a typical schedule goes for a startup that follows everything for agile, you need to know how to deal with it. So this is what I learned in a company that followed up here, because the next company I worked for over four years and I liked it there. And we also did estimations there and we also did scheduling and deadlines and everything. but we were a bit, a little bit more loose with our deadlines.

Rene: And also, as a retrospect for myself there, like I asked myself, like, why were there deadlines? Like, why did we have to release this after the sprint? And this was a startup with their own product, they released an app update, it was a mobile application. They released an app update every two weeks because like following that schedule. But no one was really asking for these features, like there were wishes from the community, there were investors that wanted to see growth in users, but did they want a chat function? I don't know and no one knows. They were like the AB testing was also done, but it was done after the sprint not before despite not investigating do we really want this? But that feature was properly built and after it was built and released, we looked back at it in a couple of weeks and see if it performed well. And again, discussed a lot of stress for everyone.

Rene: So first, how not to deal with them. So don't do overtime, don't stay quiet and don't change your way of working or do, sorry, double the negative here. So, you should not do overtime because overtimes do not fix estimations. And when I take stick with it in your mind is when you do overtime, you do not fix the estimation. The estimation was wrong and you should not have to stick to this. You should also talk to your manager and he goes, I think I have this here. Right? I'll get to that. Sorry. you should talk to your manager because, or coworkers or, or, or anyone really that is involved in decision making and you, if you don't have any impact on the first time to, you should change your way of working in it. Vitaly also, already touched upon this a little bit.

Rene: So let's go. First, identify your problem. Who makes the estimations, who decides on the deadlines and who's in charge of changing. So, have if you already want to make estimations and you have to do overtime because you don't make your estimations, then they were wrong. If you're a manager forces you to stick to your estimations, then, well, the logical conclusion is change your estimations to be a higher number. But this is not the, this is not the great outcome, but you need to identify who actually defines the estimation. So who decides on the deadlines is usually your manager or usually the manager manager or a marketing team or anyone else that thinks it's a good time to release a certain feature.

Rene: And then you also need to identify who's going to be the person that can change deadlines. And usually it's the same person that defines it. But that's not always the case. So then you need to make changes. So first, talk to your managerm as often as possible, over communicate. There's no, no, you cannot talk too much to your manager about issues that you're encountering on a daily day-to-day basis. If they get, if they are like, okay, you're talking too much. And then they also should realize that there is a lot of problems going on. So as soon as you, like, you're working on a ticket and like, this is not out of your world, so you have a deadline. All right. You have estimations, you need to stick to. So as soon as you're working on a ticket and let’s say this ticket was estimated for four hours. And you're working on it for two hours and you notice I'm not even close to halfway. So at that point, when you notice this, talk to your manager, don't wait for the four hours or five or six and tell three manager I'm doing overtime on this one. This doesn't work out. No, talk to your manager as soon as you noticed it's because you are the one liable for your own estimations.

Rene: And so also communicate the wrong estimations there. So, when you were working on ticket A and you know notice ticket B is sort of related, but it's probably also going to take me more time than do this as well. If ticket B turns out to be part of ticket A and therefore ticket B is less time also communicate this because communication is key in and understanding. And then do you need to talk to your coworkers, see how they feel, and just help me massively there. I understood that, everyone felt the same way and everyone had issues with the estimations and overtime.

Rene: So yeah, a summary here is avoid this at all costs. Right? Don't do overtime. If you, if you, if you are in charge, don't do it. If you have to do it, make sure you expand your estimations. And then also don't complete the tickets too fast if you are forced to overtime because you don't, because then you show you're wrongly estimating longer. So like, if you're forced in this situation where you have to do this, then make sure your estimations are higher and make sure you complete your work about the time you estimate. and at the same time you influenced your coworkers to do the same thing and you started the job search because you don't want to be stuck in a company where you have to estimate double time and then you can be bored to make sure that you can do this.Right.

Rene: And of course you need to improve yourself. You always need to look at like, where did I estimate wrong? Did I do this on purpose? Like for manager reasons? Or did I do it accidentally? Like did I notice that I have a hard time with integrating a certain aspect? So, if you're always having issues with third-party libraries, then you know that if you need to do something with a third-party library in the future, make sure you estimate a little extra time there.

Rene: And so yeah. Learn from your mistakes and, and, and, and, and keep on improving these estimations because there's no way around them usually. The only thing you can do is make sure you are getting better at them and make sure that you're communicating well.

Rene: And then let's talk about deadlines. You need to understand why they exist because they do exist. Usually for the wrong reasons, but when they are there, you need to understand them, to know how you can influence them. So if it's your manager that needs to know, then there's a higher chance of influencing his deadlines than when it's a government contract to get back into the subject. Like you can, there's a lot of changes here. And if you cannot change the deadline, then you can maybe change the scope. So do we really need all the features that we've listed or is it good enough to remove one, or simplify a certain feature to make that, that time? So, instead of having a like I mentioned before, a chat functionality, maybe just providing some sort of email functionality is easier.

Rene: Chat is usually like user sockets and up to date and it reflects quicker and maybe a message box is easier to build for you and some way. Or maybe just exposing email addresses also does the trick, like, do we really need it? And that can, that can help there. And as I said, had extra times where your estimations, if you have to do this, this gives you your own flexibility.

Rene: So about me. Because this was my talk and I want to quickly expose what I do. As I said, I'm a developer advocate. What we do is we do IOT device managing management, monitoring, updating software on the fly. Like all the things that you are having issues with. If you have a raspberry PI, you know all the drills, removing the SD card and everything, and we can just handle this all for you, starting for free. And I can give you a coupon for $250 on paid products. So a free to start is like three devices forever, so you never have to pay. So if you're ever interested in this, make a screenshot and then, or watch recording or whatever, or contact me, I can help you out. I want to give you all the tools you need to make your work easier so he can make those deadlines.

Rene: Thanks.

Darren: Okay. Great. thank you so much, Rene, for just being transparent about your personal experience and also sharing practical things that you have learned. I think it makes it pretty easy for us to relate to you apply in our own careers. Okay. So now we have another Q & A time, feel free to keep putting questions in the Q & A, we already got some that I see. We'll try to get to as many as our time allows. Okay.

Vitaly: The point that there is no over-communicating, that was seriously just great. Talk to your manager, guys and girls. They want to know about the problems as soon as the problem arise.

Rene: Yeah, exactly. I still make that same mistake. I don't communicate enough. Honestly, just talk to your manager 10 times a day. You won't even notice.

Darren: Great. All right. So the first question is from Daphne, both Vitaly and Rene mentioned the marketing team being a source of stress for unrealistic deadlines. What are some ways marketing and product, including engineering team can work together to come up with more manageable estimations?

Darren: It doesn't have a name attached to it. So any of us, any of you want to answer, please do.

Vitaly: May I?

Darren: Sure, of course.

Vitaly: So there's this common misconception or strange pattern where teams depend too much on each other. It's easy for marketing to market what's done. So if I being the marketing person let's say, have this headset at hand, I can market it properly. I can explain the pros and cons of it. I can find the audience, the target audience for the headset to buy it. I know how to sell it. If it's not done yet, if it's just a prospect, it is even harder for me to market it. So if marketing team only markets what is already done, they can plan campaigns. They can do freely, whatever they want and the IT can help the marketing team with feature toggles.

Vitaly: So if I am a marketing person and I want to launch a campaign for the Saint Valentine's day, let's say. I can have IT team done the feature maybe five, five months ago. And I can enable this feature only on the 14th of September, sorry for February. So it's easy peasy for me to enable things which are done and to market them properly and I can run the campaign even on the TV.

Vitaly: So once again, if you decouple marketing and IT, so that marketing only uses what's already done or can even enable certain features when they want it's much easier. And there is no stress in this collaboration between teams.

Darren: Okay, awesome. Rene, do you want to add anything on to that?

Rene: Yeah. I mean, there's, that's I also say, I think that's the ideal situation there. Typically you have, like, in my experience, like with a company I worked for, there were marketing efforts in place for features that that didn't exist. What you need to do is you need to like, make real sure you can actually do these things right?

Rene: Because there is gonna be a point where either you or your manager is going to talk to marketing to discuss this feature. And it can also be a product owner, like any, any decision-making person. And that person needs to be armed with all the information they can have. So this boils down to over-communication and again is make sure you have communicated how difficult this issue can be, and also make sure to add extra time to estimations and to deadlines, because there's always going to be issues, by making estimations.

Vitaly: I cannot agree more here. It's in project management, it's called risk management where you align wherever you just align all the risks and see what might happen and think of them. Or you can just double the estimate. And that's the safer option.

Rene: Like one example I want to give is, if you ask someone to dig a hole, right, the meter deep meter wide, how long is that gonna take? And no one can answer that, because no one knows what's on the ground. So there could be roots. There could be rocks, there could be solid bedrock, or it could be just loose sand and you're done in five minutes. All right. it could be everything of the above. So if you want to make sure you have enough time, then just estimate the worst case, and assume everything goes wrong. And then, then use that as the deadline.

Vitaly: Or if you're planning, let's say to build a proper house. So you need to dig a hole. You need to put some concrete on inside this hole. So there is this investigation phase where you actually spend efforts on reducing the risk of failing the estimate. So you spend effort on understanding the feature probably on building the skeleton of it, or building the API, even with the mocks, like building something in advance to reduce the risk of failing the estimate.

Vitaly: That's what I personally do when I have marketing team saying we must do something on that date. So I'm telling them, okay, guys, we can do that, but in order to, in order for me to tell you, like, with a better guarantee, with a better assurance that it will be done, I need to spend a week now with my team.

Darren: And, thanks for answering that. We have one question for Rene specifically. How do you convince a product manager if he or she thinks that the task is overestimated?

Rene: Oh, that's a good one. I would say track record, because, this isn't probably not the first task you done, and the first task you estimated and if that person says, well, this one is overestimated, just look back at your history and see how well you've done. Ideally you should not have to convince them, but of course the situation occurs. So, look at that and otherwise explain your thought process. So explain why you think this ticker takes longer than that person thinks. Like what complexities are there? Is it technical debt? Is it uncertainties? It could be you estimate higher because you don't know certain aspects. So this is also part of the preparation phase and then you can give the responsibility to the product manager to make sure those uncertainties go away. And otherwise you stick with the estimate,

Vitaly: The minor thing here. It's okay to not know things. As soon as you explain that, I don't know this part of the technology let's say or maybe this templates in your language or something else, it's more visible for your manager what the risks are. So don't blindly say, yeah, it's fine. I'll figure it out. You won't, it's hard. People don't understand. Our problem is that we don't understand how much time or how much we don't know how much time it will take us to understand that. So it's hard. It's better to say. I don't know something. After all it’s the manager’s duty to actually help you to learn things.

Darren: Okay. So because of time, let's wrap up the event. I know we didn't get to everyone's questions, so feel free to leave them in the discussion section of the event page. My colleague will put the link in the chat if you need that again. And just to have some, some final words. Vitaly, do you have any final thoughts you want to add to share with everybody?

Vitaly: My final words are always pretty much the same thing. Why you are doing something before you actually do something pretty much everywhere. It's useful, pretty much everywhere from a technological choice. Whenever you want to choose something, think why, what problem you're doing, what problem you are trying to solve, will this tool solve this problem?

Vitaly: Same about the processes. Like will overtime solve anything much? None of the time. It will, et cetera.

Darren: Awesome. Yeah. Great advice. and Rene, what about you? Anything you'd like to add or share?

Rene: I mean, never do overtime. You're not getting paid for it and you're solving someone else's problem and it's your time and your head. And if you do overtime frequently, you might even burn out. So, think of yourself. Yeah.

Darren: Okay. Awesome. Yeah. So thank you everyone for joining the event today and also a huge thank you to our speakers Vitaly and Rene, and for taking the time to share with us. so I hope you all enjoyed this talk. I hope it was helpful.

And as you can see, my colleague has put up. The next week's event is React with TypeScript, Build a React component together. And as the name suggests, there will be a live coding time. You can use the QR code for the event page, or look for the link in the chat. Yep. That's all. And thank you everyone, and see you all soon.

Vitaly & Rene: Thank you guys. Thank you. Thank you.