Are 40 hour work-weeks (no overtime) acceptable for development teams?

Question

No matter what our current conditions are, it seems like my team is always working 40 hour work-weeks.

Under normal work conditions this would be fine, but as we approach a deadline on a major product, we really should have all members dedicated to staying late to see it finished.

We also offer the ability to log in to their work PC's remotely, so they are able to access them from home or other locations.

I don't want to just set "more hours" a goal since that's not necessarily tied to more success for the company, i.e. they could have just spent 8 hours on a project that should have taken 4.

Still though, as we approach deadlines, it does bother me that more of the team members seem to only be doing the minimum required.

In your experience, what is the best way to get development team members to increase their hours and make them count?

NOTE: I know there is a counter-argument that any work above a 40-hour work week will not be productive. I think that has some merit, but the realities of the industry dictate that sometimes we can not finish everything that needs to get done within that time frame.

Answer 1

Very short term solution: Based on my experience, there is always somebody who'll do anything for money. Money is the worst motivator ever, but if you are in trouble - such as losing a customer - you have to do something. If the money motivation works, think about the why and start thinking about hiring a new team, because they kind of put upon the situation and want more.

Short term solution: Try to emphasise that the company needs - in the positive - way to stay longer for this major release. If people feel that they count (needed) they become more flexible. Don't bother with the usual company BS, that we are a family and without you it won't happen. If necessary, you can give them some extra vacations days for their additional effort. But no money!

Mid term solution: Learn from your mistakes and find out what went wrong with the last delivery, and add buffers to your schedule so that teams don't have to do overtime. Involve the team into this discussion.

Long term solution: Find out why the team members provide only the minimum. If you know their motivation, you can counter-act and manage the situation. For example, I know a company where developers just did the minimum because they had family and didn't want to go home exhausted.

Personally, I don't like the idea of doing overtime at any release. Teams should prepare for releases from day one and improve until the release happens smoothly. Sometimes it's ok to stay late, but when I'm the only one who stays and cares, I'll be angry and provide the minimum the next time too. I suggest you solve the current situation and put some effort in the mid and long term solutions.

Answer 2

"but as we approach a deadline on a major product, we really should have all members dedicated to staying late to see it finished."

If a PM is doing their job efficiently, this would be exactly the opposite of true. Your team should be working about the same amount of hours every week. If they have planned their project properly, and continually monitored the progress while updating the timetables, there should be no need to put in 60 hour weeks.

Furthermore, you never mention whether or not your project meets the deadline, or fails to meet the deadline. Are your developers continually missing deadlines, or not? If they are, then you should probably think about altering the way you manage your projects. Unless you have a team of complete incompetents, missed deadlines generally imply a poorly managed project. On the other hand, if your team is indeed meeting the deadlines, then why in the world do you think they should be working more hours? Simply because you feel like there should be a big rush to finish the project at the end?

Finally, if you have members of your team that consistently fail to pull their weight and always put in the minimum amount of effort possible while allowing others to carry the project, fire them. Don't wait, don't torture yourself or your team any further. The general reluctance to fire team members that detract from the quality of our teams never ceases to amaze me. One member who consistently brings the team down will slowly but surely lower the quality of output from all team members. And no, I don't believe you should warn them, or give them second chances, or talk to them to see why they choose to put in the minimal effort, or any other sort of feel good crap. Team members who continually choose to underperform will pretty much always choose to do so. Serve the many and facilitate a good team dynamic by removing those who choose to detract from it.

Edit: In the interest of clarity, I will explain myself further. A properly planned project has very firm short deadlines, and flexible long deadlines. Obviously the unforeseen will always occur, and it must be accounted for. I'm a huge proponent of shortened cycle times (< 1 month), in order to increase the accuracy of our estimations. A caveat to this is extremely limited work in progress. Team members should be working on no more than two or three things at one time. This limits the amount of things that can go wrong, allows them to focus their efforts, and increases the accuracy of your time estimations.

I would also like to emphasize that the team members I spoke of firing are ones who consistently choose to put in the minimal amount of effort to get by. I am not referring to Jimmy who's a good team member normally, but has been having some issues at home and has been off his game for the last month. That is entirely different.

And finally, I would like to add that regardless of your estimation skills, it will at times indeed be necessary to crash at a deadline to finish the project. This however should not be the norm. Things sometimes go wrong, and you must make up for it. Sometimes you can throw more people at the problem, sometimes your product owner will be happy with a reduced feature set (which is much easier to gauge if you're agile and have had continuous feedback from your product owners), and sometimes you just have to suck it up and stay late. But again, this should be the exception, not the rule.

Answer 3

Things that have prevented me doing any more than I'm contracted to do include:

• Habitual requests for extra time, if it happens every deadline, then the project manager is not pulling their weight.

• Lies. If you tell me you need it tomorrow, you'd better be using it tomorrow. If I ask you about it a week later, and you say you haven't looked at it, you can bet I'm not going to take any of your deadlines seriously ever again.

• Presumption of extra time - If I go home on time or only give an extra half hour one day, I don't expect to be asked why I'm leaving so early.

• Asymmetry in the extra time. If I work 8 extra hours one week, I don't expect to be chewed out for turning up half an hour late the following Monday. In fact, I expect a manager to say, "Well done, take Monday off."

If your team has been subjected to either of the first two, then you either need to regain their trust, which may take years, or replace them with a more gullible team.

You may be able to fix the other two by offering, up front, a programme of lieu time with at least a 1:1 ratio, that can be taken at any time after the deadline.

Answer 4

No matter how many times I read this, this line slaps me across the face "we really should have all members dedicated to staying late to see it finished."

It is dripping with false expectations. When an employee accepts a job, at least in North America, a 40 hour work week is standard. Some overtime is expected, but only in exceptional situations. Nearing a release is not an "exceptional situation". It has been planned for months. It's a target that has been nearing for months. When the schedule started to slip a quarter of the way through the project, measures should have been taken then to get back on track. What action is required varies from team to team, project to project. But something can almost always be done.

Waiting until the "final push", and expecting everyone to put in extra effort is a management failure. For several reasons. First, as mentioned, it should have been handled sooner. Secondly, that "death march" at the end of a project will be the shotiest code written. It will be full of bugs, and cheap hacks to get things done quickly. Third, and the reason for point two, is it destroys morale. Employees want to go live their lives, and this death march, which they probably saw coming months ago, and warned management about, and were ignored is motivating them to one end and it isn't quality software. It's to finish as fast as possible so they can go home.

And after hitting the deadline, at least on the calendar. You'll spend the next several months fixing up the bugs, costing more. And annoying the coders stuck on the project in the mess that was created because of the death march. Which will ultimately result in worse performance next project because they're now starting with poor morale.

Ultimately, you end up with your best people quiting. And a reputation as a company (or IT Department) for not delivering quality work.

Answer 5

There are some answers about dealing with the immediate problem. You should also invest some time into making sure you're not in the same boat again.

I notice you say:

the realities of the industry dictate that sometimes we can not finish everything that needs to get done within that time frame.

Some questions I'd be asking:

• Who set the release date expectation and how was the date arrived at? (was the team involved & did they agree it was a reasonable target)

• What are the business reasons for releasing on that day? (how much do we lose by delivering a week later. I've seen cases where the loss was less than the overtime paid!)

• How far apart are your releases? (shorter releases are easier to plan for)

• How do you deal with unexpected work (discovered work, live support etc)?

• How do you communicate the affects of that to your customer?

Answer 6

From everything I've read, switching to a Results Only Work Environment results in an upswing in productivity. It tends to result in more hours worked too, but that's not the goal per se.

In a nutshell, ROWE means that you stop managing hours and work location and instead manage measurable objectives and let employees control their own time and decide for themselves how best to accomplish the results that are expected. If the team produces a specific result (features developed, bugs fixed, etc.), that's more important than how long it took them to complete it or whether they worked late or not.

Note that it's really important for these expectations to be reasonable and to be agreed to by the person expected to perform them. If expectations are unreasonable, you'll burn people out and your good employees will leave. If people are on the hook for what others were supposed to do and didn't, again, they're likely to get frustrated.

Not managing hours means that saying "I put in 40 hours, that should be enough," isn't an excuse if a task that you're on the hook for didn't get completed. Therefore, it should encourage people to put in extra effort when it's needed. But on the flip side, it means that they get to pick when and where they work, provided that they get the work done. So one person might come in at seven, eat at their desk, and work straight through til six PM. Another person might roll in at nine, work until one, take a lunch break, work from two until four, then go pick up their kids, deal with dinner and homework, and then do a bunch of work from their couch after the kids are in bed. Both of these are the employee's choice to make. They're given a set of things to accomplish, and it's up to them to figure out when, where, and how they work best and juggle priorities appropriately.

Part of the reason it results in more hours worked overall is that people are willing to bust their tails for you when they have control of their time. If I'm not getting the stink-eye because I leave at four to let my dog out, or I can schedule doctor's appointments without it having to be the last appointment of the afternoon, I'm much more willing to work some in the evening or on a Saturday.

Also, people can often be more efficient if you get rid of expectations regarding hours and location. Someone who has an hour commute each way is spending ten hours a day to work for eight hours. That same person could work nine hours from home, get more done, and take less time out of their day to do it. Similarly, someone might choose to come in later in the morning to avoid rush hour, leave before afternoon rush hour hits, and do some work in the evening.

Admittedly, this is a huge culture change and requires the willingness and ability to commit to it, and especially to fire people who don't produce the expected results.

Answer 7

Lot of long winded answers here, plenty of good content. One of my favorite posts on the subject is by Rob Mee of Pivotal Labs, a company known for sustainable work ethics. The full article debunks several myths. Here's what Rob says about >40 hour work weeks:

"Working crazy hours doesn’t get you there faster. In fact, it slows you down. Sure, you can do it for a week. But most start-ups plan to be around for a little longer than that, and developers will going to have to keep programming for months, if not years, to build a successful product. Many start-ups operate as if the pot of gold is just around the corner; if we only work a little harder, we’ll get there. Pretty soon developers burn out, and simply go through the motions of working long hours without any corresponding productivity. Working intensely, for shorter periods of time, is far more effective. Pivotal has helped hundreds of start-ups build systems, and has done it on a strict 40-hour week."

Quoted from Four Hour Workweek Blog: What’s Your Start-up’s “Bus Count”? 7 Myths of Entrepreneurship and Programming.

Answer 8

Unless your development team is already committed to the project and it's deadline, I think you will have a very difficult time motivating the team to deliver more functional hours and more importantly effective code, by which I mean properly tested and documented code that was designed well.

At the point were the deadline is looming you either have the team mentally and emotionally onboard and they are already putting in the extra time because they don't want a missed deadline on their watch. Or you need to threaten them (e.g. people will lose their job if deadlines are missed, etc.)... which really doesn't work for many reasons, but it may produce something that the 'deadline setters' would accept.

To fix this problem, you need to go back in time. You need the team to be held accountable to estimates and timelines that they accept. Without diving into the details, take a look at Scrum or another agile development models. Basically you need to reset the software development process at your organization; the development team is likely not very happy, if you keep missing deadlines, the deadline setters aren't very happy. All of this can be fixed, but not by whipping the development team to make them go faster or pull harder.

One side comment, as aclear16 said

if you have members of your team that consistently fail to pull their weight and always put in the minimum amount of effort possible while allowing others to carry the project, fire them. Don't wait, don't torture yourself or your team any further.

I agree with this approach. If someone is unwilling to play nice with others and carry their weight they need to find a new home. That does not mean that a junior developer should be expected to deliver the same volume and quality of work as a senior developer.

They may not be a bad nasty person but they are in the wrong position and should go find something more useful to do.

Answer 9

Under normal work conditions this would be fine, but as we approach a deadline on a major product, we really should have all members dedicated to staying late to see it finished.

No, your (obviously bad) product managers need to set better deadlines and the amount of work that must be done before said deadline. This is likely to be your failure, not theirs.

Answer 10

The answer is on the contract that every employee has signed with the company. Whatever number of hours is reflected there should be not only acceptable but what you must expect and rely on to get the job done. Now, taking off my 'union hat'... development is not a production chain where number of hours translates directly in productivity or maybe it does but in such a complex way that the comparison will always be dangerous to be considered for you as project manager.. supplies shortage, unplanned repairs, ... have their analogous in the IT world but it's a game that you cannot win if your problem as it looks refers to most of your team.

What can be done then? There is a fine balance to be kept and a small 'cheat' to play. The planning of the work, following whatever methodology you use (waterfall, agile, ..) must be realistic and with enough definition level so that when things don't work the person taking a task considers himself responsible for the miss. The developer will be responsible but you will still be accountable (I am using the RACI model here). Getting to a level enough of definition may not be easy so, involve the team on achieving it (write specs, contact customer representatives, ...) make them feel IMPORTANT and they will be motivated. The cheat to play is that you must fix a minimun that is slightly higher that what you think can be done. More often that you can imagine, you will see this threshold achieved, sometimes because the person will push, others because you will have underestimated and some others because the team will come out with more efficient solutions...

The size of your company is another important factor. In big companies, where the failure of a project or the loss of an important customer is not relevant. This false conclusion must be conveyed to every employee in the company to avoid that they get accomodated.

About salary, in my life as developer I have had sustantial salary increases and none of them have made me work more or better nor staying in the company. Salary is a short-term motivator in the best case. For this, I consider important that any incentives can be awarded directly linked to direct contributions by individuals and given with a regularity enough so that effect may last from one to the next if both are achieved but if one fails there is the possibility for another not far down the road.

And incentive may not be only referred to money. You must get to know your people to know what they like: training, attending a conference, public recognition, a second screen, extra holidays, ... will be easier for you to provide as companies CFO don't see them in the same way. Given them what they prefer not what you would like to get yourself.

But of course, as several people have already mentioned, if everything else fails after trying for some time, you must know how much effort you can afford, you must redistribute the team to other functions or just fire them and have a better assessment on people responsibility and motivation when hiring. Quite often though this will be difficult to do because the burnt out people will be people who has been on the company for long and hence, is difficult to justify that they are no longer valid.

It is important to take advantage of annual appraisal to stay in touch with your people expectations and motivations. This will require that you have honest and open communication with the team throughout the whole year so that the environment is friendly. No doubt, if there are indicators that show a problem you must act inmediately.

To finish, let me tell you also something that I hope you will take it properly. I detect in the way your question is expressed certain old-times attitude that I think is biasing how you approach the problem. You should, and here I connect with my first paragraph, consider your developers not 'blue-collar' workers that will try to work the least but 'artists' looking for a muse that inspires them to create.

Answer 11

In response to the question in the title - YES 40 hour work weeks (no overtime) are acceptable for development teams.

The best run teams (in my experience) can deliver good results most of the time on 40 hours.

In the case of an occasional project that is going over a lot at the end (and this is usually going to lead back to a business development failure, or a project management failure) then appealing to how needed your people are might get them to pitch in extra time without resentment. But in my experience, you have to be careful pushing even happy teams, because once people start to feel taken advantage of, you'll end up with a festering culture of resentment where nobody can be bothered to do anything more than whatever bare minimum will cover their own asses. (You can also get passive aggressive behaviours like presenteeism, malicious compliance, and even malicious damage to projects depending on how annoyed your team are)

But really... a well run project will show slippage before the deadline is due, as soon as you start losing ground against the plan. So in the that case, an appeal for overtime at the time when the project starts to slip would make a lot more sense than having it at the very end. I can't see any reason other than bad management/planning for overtime requests at the end.

Bottom line - If you're depending on compulsory overtime at the tail end of every single project, your problem isn't learning how to make people stay late, it's learning how to not need to make people stay late.

Answer 12

There is nothing about 40 hours and the degradation of work performance. The law of diminishing returns has been butchered. There are certainly stamina issues, but you can expect quite a range when people start to crap out. The concept of 40 hours is around the law--here in the US--that says certain roles must be compensated a certain way when passing 40 hours in a work week.

The notion that, when approaching a deadline, op tempo should increase seems odd to me. Op tempo should go up or down, or stay the same, throughout the work cycle based on many different issues, not just an imminent deadline. If you are finding the need to increase effort at deadline, something's wrong with your teaming set up and how work is done long before the deadline.

Also, if you are finding your team not willing to do what it takes when the pressure is up, then you haven't built a high performing team, yet. Look at the following key motivators: autonomy, mastery, and purpose. Build your team, get them wanting to be successful, get them to feel that the team succeeds together and fails together, then this question will be come irrelevant.

Answer 13

As it’s already been said, working long hours doesn’t necessarily mean pulling extra weight. At the end of the day, it all comes to motivation. As the infographic I recently came across suggests, the three leading motivators are a sense of responsibility, a good mood and a possible reward, respectively. Oddly enough, the mentioned reward is valued by only 42.1% of employees. So, if you earned enough of trust with your team, try to appeal to their dedication to the project. And try to avoid the atmosphere of high stress and burning deadlines. Good jokes and cheering people up is almost always better than a stick.

And if they actually make it, don’t forget to mark the contribution of every member of your team and even have a small celebration to show your appreciation. Small gestures matter.

Answer 14

anybody who thinks you can do big projects based on two week estimates to meet the ultimate promised delivery date is pretty much clueless. I don't know where these so called software engineers work but they must never have bugs in their code that are hard to find or hardware that the software runs on is not working right. These kind of set back happen all the time.

Overtime is only good for permanent employees if they work it for free. Then the management is all for it especially in times like i mention above. Otherwise, if you go home at 40 they are ticked off.

As for contract employees, money is a morale boster for them. Tell a contractor he has to work over for 40 for free and just take the hinges off your door. For that matter, don't give your employees any pay raises once and see what happens...just keep the hinges off the door.

Agile is strawman's argument against Spiral development. Agile proponents just bash Spiral development and therefore it's better. Or they put a pie chart that shows there's a higher %age of successful projects that used Agile compared to spiral/waterfall. It's like leftism. You just bash the other side or the other way.

Companies that use Agile are treating their employees like children. Whoever heard of holding up a card (at the count of 3) to estimate a task for which you have no clue what has to be done? You may as well throw some sh*t on the wall and whatever sticks that's your estimate.

A morale killer is making your employees go to a daily scrum and "go around the room" and tell everyone what you did and what your blockers are. I go to those daily, when i leave them i have no clue what anyone is working on. I don't listen. I have my own work to stay focused on. When the day comes to integrate code with them i usually send them an email and ask for a get together.

I could go on and on. This IS empirical evidence on how much Agile sucks.