Overtime, done right

We’ve all heard the games industry overtime horror stories.  ea_spouse is still the most famous example but if you work in games, you’ll know more.  I’ve heard of people that were forced to stay late every night because of a “nobody leaves until everybody’s finished” policy – with people challenging the policy losing their bonuses.  I’ve heard of another employer criticising a programmer for not looking tired enough (they started playing WoW at work).  And I’ve worked some fairly brutal weeks myself!

But how much overtime is reasonable to work on a software project?  I suspect it’s a question every software developer must confront at some point in their career (if you haven’t, count yourself lucky!).  Let’s start by caricaturing two opposing points of view I’ve heard:

  1. Overtime should be avoided at all costs.  Nobody looks back at the end of their life and wishes they’d spent more time at work.  You’re much more likely to regret missed time with family and friends, or experiences you missed out on in life.  Overtime is a direct result of poor management – why should the developers pay the price for this?  You get paid your salary for a standard working day – if the project requires more effort than this, the employer should extend the schedule, hire more people or cut features.  Making great software requires top quality work, not just a great quantity – and excessive overtime leads to tiredness, reducing quality – thereby harming the product over the long run.
  2. Greatness is not achieved by working 9-5 and viewing your work as just a way to pay the bills.  Making great art requires sacrifice.  If you don’t work overtime, you’re missing the chance to ship sooner and add polish.  You’re saying “that’ll do” rather than “I gave it my all”.  Adding more people doesn’t work because it’s tough to maintain quality when you hire lots of people, and increasing team size introduces all kinds of new problems (possibly even making you later).

Personally, I can see both points of view.  Part of me is highly driven, loves my work with a passion and measures myself by my success at work.  I have some definite workaholic tendencies as a result.  At the same time, I have a wonderful family that I love spending time with.  Our 3-year-old daughter changes at a frightening rate, and each stage of her development needs to be treasured before it’s gone.

Learning functional programming

Learning functional programming

Nowadays, I definitely lean more towards the “overtime is bad” end of the spectrum.  I got turned off overtime back at VIS.  It took me a while to realise, but we were working some crazy hours with no end to the project in sight.  We suffered from a basic inability of management to balance the scope of the project with the budget.  We were trapped in a classic bad publisher/developer relationship, constantly hanging by a thread, driven to a spineless position where feature creep and random changes in direction were normal.  When we finally realised NARC had slipped way behind schedule, we “renegotiated” a longer timescale that came with a ton of new work.  It wasn’t more time to put us back on schedule, it was more time so we could catch up ourselves by working harder (and an on-site producer to check up on us).  The real killer, of course, was that NARC was clearly destined to be crap (and I do say that with love).  Once I realised how futile the overtime was, I started looking for something else.

Moving to RTW

Moving to Realtime Worlds was a hugely pleasant surprise after that background, as they’re definitely an enlightened employer in this respect.  I no longer work overtime as a result of blatantly unrealistic scope or underfunding.  I do still work overtime, generally a steady-but-low amount – and always out of choice, to turn something good into something great, to satisfy my own pride.

We manage our projects pretty carefully, we have sufficient funding to achieve our goals and no publisher applying arbitrary external pressure.  We value the wellbeing of our employees and respect their own preferences on overtime.  In other words, we’ve eliminated all the wrong reasons for doing overtime.  That leaves us with an interesting question: what should you do then?  What place does overtime have in our projects?  What does it look like when it’s done right?  If it’s useful, what are the right reasons for doing it?

Here’s how we do it right now:

  • Overtime is voluntary.  This allows people to make their own choice, depending on what they value more (achievement at work versus life outside work).  It’s easier said than done, especially when you take into account things like peer pressure that can quickly slip out of your control.
  • Overtime is paid for.  I wasn’t fully sure about this at first; I thought we might be in danger of displacing intrinsic motivation.  That may still turn out to be the case; it’s too early to tell.  But I like the positive intent: it says “we value our employees’ time”, loud and clear.  I’ve noticed that it looks attractive when we’re recruiting.
  • Overtime is valuable in moderate, sustainable amounts.  For one thing, it’s incredibly hard to hire top quality developers – so a bit of overtime from your existing team can make a lot of sense.  Secondly, the resourcing demands of a project aren’t constant across time, and standard hiring mechanisms are too slow to react to short-term adjustments (plus, reducing headcount is best avoided whenever possible, for obvious reasons).  Finally, strategic use of overtime can unlock rewards out of proportion to the effort invested – for example when one programmer stays late to make a critical pipeline improvement for the art team to use the next day.
  • Extended, excessive periods of overtime are harmful, and we can make world-class products without them.

We’re definitely still finding our way; this is very much an emerging view that changes over time (hopefully always for the better!)

Morning mist

The finishing line

The main question I’ve been struggling with recently is whether overtime really needs to be weighted more towards the end of the project.  This weighting seems to be pretty standard, but does it have to be that way?  My first thought is, why should it be more valuable at the end?  Couldn’t it be equally valuable early on, where discovery of new techniques, invention of new gameplay concepts, and large boosts to artist productivity (by tool and pipeline improvements) are most likely?  And isn’t it best (as an employee) to spread your overtime relatively evenly across a project, ensuring a sustainable level and avoiding all-out crunch?  Sure, it’s psychologically easier to accept overtime when the finishing line is in sight – particularly when your product has a chance to be great – but it still doesn’t seem good for your personal life, particularly when “the end of the project” can last quite a while!  And whether it’s good or bad, the curiosity inside me wants to understand why things are the way they are.

The main reason I can see is that the end of a project is your only real deadline.  Every other deadline is non-final and has wiggle room.  You can easily choose to polish later, cut features, hire extra developers or delay the ship date when you have trouble meeting an intermediate deadline.  But the end is different:

  1. Once you’ve arranged a ship date with distribution and marketing, it becomes outrageously expensive to move it.
  2. Once you’ve placed expectations of feature set with the press and the public, it can really harm your product’s public image (and hence sales) to cut things.
  3. Simply being “final” means there are no opportunities to make adjustments and change the course of the project.

These reasons seem compelling to me.  Here are a couple of other reasons I’ve heard:

  • Once you prepare to release your game for real, your quality standard goes up; very few people are able to retain that kind of quality bar early on.
  • The amount of work required to truly reach “done” is always more than you think.

I don’t like these two.  These two, in principle, come under the “bad management” category for me.  Granted, they aren’t the most outrageous examples of bad management; they’re more like the difference between decent and outstanding management.  But ultimately, ensuring that there isn’t a huge pile of unexpected work at the end of the project is a management responsibility and not an excuse for overtime.

It all depends

Views on overtime are highly context-sensitive.  It depends on the project (I’d work overtime far more readily on a project that has a chance to be great), the employer (particularly whether they’re a new start-up or an established place with a revenue stream) and most of all the employee.  My own views are constantly developing.

How do you view overtime?  If you’ve worked somewhere that’s “done it right”, do tell 🙂

This entry was posted in Realtime Worlds, Software development. Bookmark the permalink.

2 Responses to Overtime, done right

  1. Rob Chant says:

    Like you, I mean towards the ‘low overtime’ end. I’m pretty much agree with everything you’ve said really, especially from a management point of view.

    Overtime increasing towards the end of a project (be it a game or your final year essay) is just simple human psychology. The brain has evolved for short term thinking — dealing with immediate needs, dangers, pleasures, etc. While some people have the discipline to do it well, for the average person (and especially for groups of people), balancing long term needs against short ones, whilst being intellectually easy, is almost impossible practically.

    It’s exactly the same reason why people don’t exercise, eat too many pies, smoke, etc, when they know that this behaviour will harm them, in the future, hugely disproportionately to the pleasure they’re gaining now.

    • lukehalliwell says:

      Yes, nicely put. I heard someone else mention the “student essay” analogy. Pie-eating sounds much funnier though! 😀

Comments are closed.