5 ms·

> My suggestion: if a single week of overtime will help you meet a critical deadline, and you can promise your team it’ll be an extremely rare occurrence (like,

by donatj 3y ago

> My suggestion: if a single week of overtime will help you meet a critical deadline, and you can promise your team it’ll be an extremely rare occurrence (like, once a year, at most), consider asking for overtime. Otherwise, just take your lumps and accept the late project. I am of the strong opinion that there are very few projects where the benefits of a couple more hours of work out of your employees a day is worth the cost on morale. Project gets out tomorrow versus a month from now? Will anyone still care two years from now? No? Wasn’t worth it. The human propensity for screaming “I want it now!” about things that don’t really matter never fails to frustrate me. And please don’t get me wrong. There are certainly cases where people’s jobs or the entire company hang in the balance. That is a legitimate reason for overtime. There’s also cases like the UI redesigns with no effect on the bottom line the last time I had to work overtime - and in my experience anyway this is way more common.

mytailorisrich 3y ago
It depends on commercial pressure and on how overtime is compensated. Early in my career our main customer put huge pressure on the company to fix bugs ASAP and we had to work 2 weeks flat out with overtime late every night plus over the weekend. We managed to satisfy the customer AND I doubled my salary that month. If it is a rare event then I have no issue with that. This has no negative effect on morale (it can even be a boost and improve team spirit), and in fact would be happy to get the opportunity. It also helped that we had a good leader: our Director could not help on the debugging but made a point to stay with us and took charge of making sure we were kept well fed, paid for by the company, of course. Leadership and compensation are key.
- NeoTar 3y ago
  Sadly it feels that overtime has been eliminated from the industry. Every contract I've ever signed (and this is in the supposedly more worker-friendly EU) has had text along the lines of 'Your working hours are 40h a week. Occasionally you may be required to work more. Overtime is not compensated.' The best I've had in a workplace is an informal policy of time-off-in-lieu for extra hours worked.
  - em-bee 3y ago
    is not compensating overtime even legal anywhere in the EU?
    - hjadal 3y ago
      It is in Denmark, my contract also states that I work 40 hours a week with uncompensated overtime. The only rules creating a cap on my working hours are the EU's, with 48 hours per week on average in a 4 month period.
    - NeoTar 3y ago
      From what the Wikipedia page of Overtime says about the EU (https://en.wikipedia.org/wiki/Overtime#European_Union https://en.wikipedia.org/wiki/Overtime#European_Union) it seems that the laws are very concerned with working hours, but have nothing to say about overtime being required to be paid or not.
255kb 3y ago
Some things may be urgent but most deadlines are bogus and created by sales and managers promising something to someone. And everything revolves around that, creating a toxic blame culture. Looking at you Scrum!
- nradov 3y ago
  Sometimes the choice for salespeople is between promising to deliver by a certain deadline or losing the sale. Some companies simply aren't in the financial position to turn away revenue and still survive. If you don't want to ever be in that position, then make sure to only work for companies that are already financially secure.
Aurornis 3y ago
> Project gets out tomorrow versus a month from now? Will anyone still care two years from now? No? Wasn’t worth it. Depends on the industry and the circumstances. If this is a company shipping their own software product and the deadlines are arbitrary, then of course they should be a little flexible. But other software development is part of something bigger and/or accountable to third parties who are depending on it. If your software product must be ready for a scheduled run of a hardware build, a launch event that was planned months in advance, a date agreed upon with customers in a contract, or any other circumstance with real dependencies then getting it done on time is crucial. > The human propensity for screaming “I want it now!” about things that don’t really matter never fails to frustrate me. In my experience, people who have only worked in the first kind of environment (deadlines are arbitrary) are the most vocal about insisting that estimation is impossible or that deadlines shouldn’t exist. When they encounter a real deadline with real world consequences they struggle to track their own progress and have to do a lot of crunch mode in the last few weeks. People who have worked in the second type of environment (deadlines are real and have consequences) become quite good at estimating and managing progress toward deadlines without crunch mode at the end. They become good at communicating issues with deadlines far in advance to avoid surprises. I’ve worked a lot in the second environment. Eventually I learned that it’s important to screen for attitudes toward deadlines because many software devs have only worked in environments where they can deliver whenever it’s ready as opposed to working toward a target with a team. It’s a shock when they’re dropped into an environment where delivery dates actually matter, as opposed to being something a PM made up.
- sgarland 3y ago
  This was also my experience in the Nuclear Navy, wholly disconnected from software development. I was my division’s maintenance planner, among other things, and so I needed to plan when we would accomplish preventative maintenance on approximately 20 different systems. Planning was usually done a quarter at a time, but there were semi-annual, annual, and greater maintenance items you also had to take into account. Further complicating things, many of the items had specific plant criteria to be met (some are easy, like “the reactor must be shut down”), some of which would only happen once in a given quarter at best. Finally, if you wanted to maximize efficiency, you also should carefully read every maintenance item to determine where there was crossover, so you could use one to partially setup for another. I made a huge dependency table in Microsoft Project, and generated Gantt charts from that. It worked flawlessly. A few key differences on the people side compared to software: * No one insisted that I plan for the nominal persons’ abilities. If Petty Officer Schmuckatelli happened to be a savant at a specific maintenance item, guess what, he’s always getting assigned that one. Others would assist (nuclear maintenance is always a two-person operation), but getting the job done correctly and efficiently was priority one. * I didn’t have to get consensus from a team on how long everything should take. This one is of course quite different from software, in that a lot of software work is novel to an extent; on the other hand, my submarine was of a new class, so there wasn’t a lot of institutional knowledge to fall back on. * Accountability is actually a thing. If you say something has been done, it’d damn well better be done. If you make a mistake, there is an all stop while you convene a meeting of god and country to hold a retrospective (though we call them critiques). There will be consequences. Not career-ending or anything – it’s quite common to cause a critique or three – but you also don’t get to just skip on out. They’re not blameful in that the point isn’t simply to say, “why do you suck,” but they’re also not oblivious to the fact that often, a person’s inattentiveness is in fact the root cause.
gadders 3y ago
Yeah, I think "If we don't complete by XX we will be in breach of Regulation YY and will have to admit this to the SEC" is probably worth a bit of extra effort. "This milestone will go Red on my RAG report and make me look bad to my manager" - less so. But like anything else, hopefully there is give and take. "If you finish this version on time to help me out, we'll put half the story points in the next iteration so you can leave at 5/pay down tech debt/whatever."
jf22 3y ago
It will never be "once a year" once you do it once. Once you start doing it, mandatory overtime will become a tool for making deadlines.
scarface_74 3y ago
> Project gets out tomorrow versus a month from now? Will anyone still care two years from now? No? Wasn’t worth it. 1. TurboTax 2. A game or other software that needs to get out before Christmas 3. A dependency is being shut down (https://www.honeycode.aws/ https://www.honeycode.aws/)
- notact 3y ago
  The "No?" portion of the hypothetical you quoted is designed to filter out your examples. A few lines down from that clearly addresses the need for OT in critical situations.
  - scarface_74 3y ago
    Fair Side note: I was actually at AWS when Honeycode was introduced and on a team working on a popular open source “AWS Solution”. The Honeycode team wanted us to integrate with it and I vehemently opposed the idea. I said wait until it gains traction. Luckily, I won that fight.
iamthepieman 3y ago
I'm dealing with another common version of this right now. Another contractor (not from my company) had estimated a certain amount of time to fix everything and add some updates to code they had developed. Our mutual client didn't want to renew with them so asked if we could do it. But lo and behold, the deadline was two days from now so the sooner the better. I cut down the estimate by half but said it wouldn't include fixing anything since presumably they were living with existing bugs in production they could keep living with them if the new features were the priority. I did say that we would have to pay the piper eventually and that this rushed timeline would mean we would miss things and that it was only possible if we had everything in place to do the development work. Things like access, correct data, properly setup environment etc. Of course we started development and had none of those things. I did get it out on time according to my shortened estimated. But then they discover that they absolutely do need some fixes and that the assumptions the dev team had to make because we didn't have real data were wrong so the whole thing is delayed by about as much time as the original estimate but there's a whole bunch of hand-wringing and people thrashing about because of "slipped timelines". And I knew this going into it. No one ever hears "But we will have problems I just don't know what they will be" They just hear "I can get it to you in 3 weeks"
pwthornton 3y ago
This depends. SaaS software with a sales window you need to make is way different than random software that doesn’t really need to go out at a certain time. Certain industries may have a few month sales window, and missing it could cost many millions against competition.
pards 3y ago
> if a single week of overtime will help you meet a critical deadline In my experience, every unit of overtime is followed by a larger unit of "undertime" where the team (usually subconsciously) goes through a period of low productivity. The ratio is often as high or higher than 1:2, so a week of overtime can result in two weeks of undertime. I present this as a fact when project sponsors request that the team work OT so that they're aware that they're trading future productivity at a loss for productivity today.
pwthornton 3y ago
A good UI redesign should have an impact on the bottom line.
lowkey 3y ago
I agree and would add the following criteria to identify the few rare cases where it is worth it to meet a hard deadline and where cutting scope is not an option. Specifically, if meeting the deadline is so important that it justifies unplanned overtime or a death march, then leadership should be happy to pay the team a one-time special bonus equal to 2-5x the time spent or even more. If faced with this choice leadership balks at the idea that’s a very good sign that a death march is unwarranted.

by donatj 3y ago

mytailorisrich 3y ago

It depends on commercial pressure and on how overtime is compensated. Early in my career our main customer put huge pressure on the company to fix bugs ASAP and we had to work 2 weeks flat out with overtime late every night plus over the weekend. We managed to satisfy the customer AND I doubled my salary that month. If it is a rare event then I have no issue with that. This has no negative effect on morale (it can even be a boost and improve team spirit), and in fact would be happy to get the opportunity. It also helped that we had a good leader: our Director could not help on the debugging but made a point to stay with us and took charge of making sure we were kept well fed, paid for by the company, of course. Leadership and compensation are key.

NeoTar 3y ago
Sadly it feels that overtime has been eliminated from the industry. Every contract I've ever signed (and this is in the supposedly more worker-friendly EU) has had text along the lines of 'Your working hours are 40h a week. Occasionally you may be required to work more. Overtime is not compensated.' The best I've had in a workplace is an informal policy of time-off-in-lieu for extra hours worked.
- em-bee 3y ago
  is not compensating overtime even legal anywhere in the EU?
  - hjadal 3y ago
    It is in Denmark, my contract also states that I work 40 hours a week with uncompensated overtime. The only rules creating a cap on my working hours are the EU's, with 48 hours per week on average in a 4 month period.
  - NeoTar 3y ago
    From what the Wikipedia page of Overtime says about the EU (https://en.wikipedia.org/wiki/Overtime#European_Union https://en.wikipedia.org/wiki/Overtime#European_Union) it seems that the laws are very concerned with working hours, but have nothing to say about overtime being required to be paid or not.

255kb 3y ago

Some things may be urgent but most deadlines are bogus and created by sales and managers promising something to someone. And everything revolves around that, creating a toxic blame culture. Looking at you Scrum!

nradov 3y ago
Sometimes the choice for salespeople is between promising to deliver by a certain deadline or losing the sale. Some companies simply aren't in the financial position to turn away revenue and still survive. If you don't want to ever be in that position, then make sure to only work for companies that are already financially secure.

Aurornis 3y ago

> Project gets out tomorrow versus a month from now? Will anyone still care two years from now? No? Wasn’t worth it. Depends on the industry and the circumstances. If this is a company shipping their own software product and the deadlines are arbitrary, then of course they should be a little flexible. But other software development is part of something bigger and/or accountable to third parties who are depending on it. If your software product must be ready for a scheduled run of a hardware build, a launch event that was planned months in advance, a date agreed upon with customers in a contract, or any other circumstance with real dependencies then getting it done on time is crucial. > The human propensity for screaming “I want it now!” about things that don’t really matter never fails to frustrate me. In my experience, people who have only worked in the first kind of environment (deadlines are arbitrary) are the most vocal about insisting that estimation is impossible or that deadlines shouldn’t exist. When they encounter a real deadline with real world consequences they struggle to track their own progress and have to do a lot of crunch mode in the last few weeks. People who have worked in the second type of environment (deadlines are real and have consequences) become quite good at estimating and managing progress toward deadlines without crunch mode at the end. They become good at communicating issues with deadlines far in advance to avoid surprises. I’ve worked a lot in the second environment. Eventually I learned that it’s important to screen for attitudes toward deadlines because many software devs have only worked in environments where they can deliver whenever it’s ready as opposed to working toward a target with a team. It’s a shock when they’re dropped into an environment where delivery dates actually matter, as opposed to being something a PM made up.

sgarland 3y ago
This was also my experience in the Nuclear Navy, wholly disconnected from software development. I was my division’s maintenance planner, among other things, and so I needed to plan when we would accomplish preventative maintenance on approximately 20 different systems. Planning was usually done a quarter at a time, but there were semi-annual, annual, and greater maintenance items you also had to take into account. Further complicating things, many of the items had specific plant criteria to be met (some are easy, like “the reactor must be shut down”), some of which would only happen once in a given quarter at best. Finally, if you wanted to maximize efficiency, you also should carefully read every maintenance item to determine where there was crossover, so you could use one to partially setup for another. I made a huge dependency table in Microsoft Project, and generated Gantt charts from that. It worked flawlessly. A few key differences on the people side compared to software: * No one insisted that I plan for the nominal persons’ abilities. If Petty Officer Schmuckatelli happened to be a savant at a specific maintenance item, guess what, he’s always getting assigned that one. Others would assist (nuclear maintenance is always a two-person operation), but getting the job done correctly and efficiently was priority one. * I didn’t have to get consensus from a team on how long everything should take. This one is of course quite different from software, in that a lot of software work is novel to an extent; on the other hand, my submarine was of a new class, so there wasn’t a lot of institutional knowledge to fall back on. * Accountability is actually a thing. If you say something has been done, it’d damn well better be done. If you make a mistake, there is an all stop while you convene a meeting of god and country to hold a retrospective (though we call them critiques). There will be consequences. Not career-ending or anything – it’s quite common to cause a critique or three – but you also don’t get to just skip on out. They’re not blameful in that the point isn’t simply to say, “why do you suck,” but they’re also not oblivious to the fact that often, a person’s inattentiveness is in fact the root cause.

gadders 3y ago

Yeah, I think "If we don't complete by XX we will be in breach of Regulation YY and will have to admit this to the SEC" is probably worth a bit of extra effort. "This milestone will go Red on my RAG report and make me look bad to my manager" - less so. But like anything else, hopefully there is give and take. "If you finish this version on time to help me out, we'll put half the story points in the next iteration so you can leave at 5/pay down tech debt/whatever."

jf22 3y ago

It will never be "once a year" once you do it once. Once you start doing it, mandatory overtime will become a tool for making deadlines.

scarface_74 3y ago

> Project gets out tomorrow versus a month from now? Will anyone still care two years from now? No? Wasn’t worth it. 1. TurboTax 2. A game or other software that needs to get out before Christmas 3. A dependency is being shut down (https://www.honeycode.aws/ https://www.honeycode.aws/)

notact 3y ago
The "No?" portion of the hypothetical you quoted is designed to filter out your examples. A few lines down from that clearly addresses the need for OT in critical situations.
- scarface_74 3y ago
  Fair Side note: I was actually at AWS when Honeycode was introduced and on a team working on a popular open source “AWS Solution”. The Honeycode team wanted us to integrate with it and I vehemently opposed the idea. I said wait until it gains traction. Luckily, I won that fight.

iamthepieman 3y ago

I'm dealing with another common version of this right now. Another contractor (not from my company) had estimated a certain amount of time to fix everything and add some updates to code they had developed. Our mutual client didn't want to renew with them so asked if we could do it. But lo and behold, the deadline was two days from now so the sooner the better. I cut down the estimate by half but said it wouldn't include fixing anything since presumably they were living with existing bugs in production they could keep living with them if the new features were the priority. I did say that we would have to pay the piper eventually and that this rushed timeline would mean we would miss things and that it was only possible if we had everything in place to do the development work. Things like access, correct data, properly setup environment etc. Of course we started development and had none of those things. I did get it out on time according to my shortened estimated. But then they discover that they absolutely do need some fixes and that the assumptions the dev team had to make because we didn't have real data were wrong so the whole thing is delayed by about as much time as the original estimate but there's a whole bunch of hand-wringing and people thrashing about because of "slipped timelines". And I knew this going into it. No one ever hears "But we will have problems I just don't know what they will be" They just hear "I can get it to you in 3 weeks"

pwthornton 3y ago

This depends. SaaS software with a sales window you need to make is way different than random software that doesn’t really need to go out at a certain time. Certain industries may have a few month sales window, and missing it could cost many millions against competition.

pards 3y ago

> if a single week of overtime will help you meet a critical deadline In my experience, every unit of overtime is followed by a larger unit of "undertime" where the team (usually subconsciously) goes through a period of low productivity. The ratio is often as high or higher than 1:2, so a week of overtime can result in two weeks of undertime. I present this as a fact when project sponsors request that the team work OT so that they're aware that they're trading future productivity at a loss for productivity today.

pwthornton 3y ago

A good UI redesign should have an impact on the bottom line.

lowkey 3y ago

I agree and would add the following criteria to identify the few rare cases where it is worth it to meet a hard deadline and where cutting scope is not an option. Specifically, if meeting the deadline is so important that it justifies unplanned overtime or a death march, then leadership should be happy to pay the team a one-time special bonus equal to 2-5x the time spent or even more. If faced with this choice leadership balks at the idea that’s a very good sign that a death march is unwarranted.