Industry Issues: Overtime

This will be the first of many pieces breaking down the elaborate issues plaguing the games industry. This is a fair warning that this will be a no-holds-barred run-down of the experiences that I have had, that my colleagues have had, and the stories you have probably already heard, to some degree. I say this because I know most of my readership are gamers, not developers. And most gamers want to, some day, be game developers on some level – be it casual games, AAA console games or MMOs. I know that they have a very starry-eyed but unfortunately naive outlook on the industry and what it is really like working in it. My goal in this is not to deter you from working in the industry, but I know, from experience, that sharing the realities of the games industry is a very powerful deterrent. The reason most gamers want to work in the industry isn’t because they love making games. It is because they love the idea of making games.

Anyway, on to the topic of the day: Overtime.

Overtime, by itself, is not the issue here. Overtime just means working more than 40 hours a week. Almost every profession and industry has some form of overtime at one point or another. We have overtime at my business software company when we really need to hit a deadline. Overtime becomes an issue when it turns into Crunch. Now, before I continue, I want to more thoroughly define crunch. Crunch is extended periods of mandatory, and usually unpaid/uncompensated, overtime. There are three key parts to this.

Extended: Crunch usually lasts for several weeks, and in some cases several months. Crunches can last from anywhere from the last 2-3 weeks of the project to the entire 2 years of the development cycle. The longer the duration, the worse the effects on the quality of the product and the quality of life of the developer.

Unpaid/uncompensated: Some studios/publishers are better at this than others. But for the most part, crunch is either completely uncompensated or ridiculously under-compensated. In a typical work environment, overtime is compensated as “time and a half”. Now, this compensation can be anything from additional salary/hour wage, bonuses, or paid time off – or any combination of the three. In crunch, however, you will be lucky to get compensated as “regular time”, if at all.

Mandatory: Crunch is mandatory. You don’t have a choice in whether you want to put in the extra effort or not, it is simply expected of you. The second part of this is that almost every studio has crunch. Granted, there are a handful of studios that brag about their minimal crunch or lack of crunch – but unfortunately they are far and few between – and most of the time, they eventually end up reverting to crunch. So, even if you disagree with the crunch practices of your current company, the grass isn’t exactly any greener anywhere else in the industry. Chances are, if you quit and find a new job, you will still have crunch, because every studio does it.

So now you know what “Crunch” means. It usually means something bad. It means the management is bad. It means the project is suffering. It means the developers are suffering. Crunch is not a good thing. Don’t let anyone convince you otherwise. There are developers and managers who will tout the benefits of crunch. But they are wrong. There are no benefits to crunch. The benefits they conjure up are nothing more than fabrications and justifications for their poor management skills and poor project management. Most managers make incorrect assumptions about correlation and causation.

“We crunched and the game was a success, therefore crunch works.”

“We crunched and the game failed, therefore, we didn’t crunch hard enough.”

Those are the two typical responses at the end of a crunch cycle. Either way, you, as a developer, will be crunching again next game. There is a mountain of evidence to show that crunch only negatively affects the final product and negatively affects the individuals working on the product. If your company does crunch (not overtime to hit deadlines, I mean crunch as defined above) and your product is successful – then you were successful despite crunch, not because of it.

So the question arises? Why do we crunch? If crunch is so bad, why does everyone do it so often? There are a few reasons why:

Compensation:

Compensation in the industry works almost completely in the favor of the studio/publisher. A typical game developer can expect to make a base salary 60%-80% less than a similar position outside the game industry, at a business application software company for example. But developers agree to this level of pay because of all the additional compensation that comes with working on video games. Namely bonuses, royalties, paid time-off, and perks. However, each of these compensation packages has its own positives and negatives. First off, if you were fired (see: Infinity Ward vs Activision) the company is only obligated to pay you what you are owed. All of the mentioned additional compensation packages are not considered “owed”, they are at the discretion of the company. They can technically give you absolutely nothing and it’s perfectly legal.

This is why you see massive layoffs and firings right after a product releases. Studios/Publishers do so to limit the amount of compensation they need to pay out in the form of bonuses, royalties, and paid time-off. You only get the bonus, royalties and paid time-off after the game has launched and if you are let go immediately afterward, they don’t have to pay you anything. And this ties back into crunch, because developers work crunch under the promise of large bonuses, royalties and extended paid time-off after a successful launch.

However, the company is going to do everything it can to subvert the compensation paid out. Bonuses will be garnished to pay for dinners while you working crunch. That’s right, that is your bonus money buying you dinner, not the company being gracious and kind for all your hard work. Royalties will be slashed regardless of how well the game does post launch. Most companies have variable royalty percentage rates. Which means that they can change the percentage of profits you receive from the product at any given time. So, let’s say the standard royalty rate for the company is 0.001% per person annually. If the game does insanely well – take Modern Warfare 2 for example – the company can, and will, change the percentage rate so they don’t have to pay you so much of their profits. The game sells well? Sorry, we’d have to pay you too much so we’re secretly going to change the percentage rate to 0.0002% instead.

Paid time-off is much of the same. At the end of crunch you may be given a week or two of PTO to use at your leisure, but many times you won’t be allowed to. PTO will be denied or you will only be able to use it until the end of the quarter or year and then it will expire. Also, generally speaking, your PTO will not be equivalent compensation for overtime. For example, say you work 80 hours a week for 4 weeks. That’s technically an extra 4 weeks of work, so you would get 4 weeks off for compensation right (assuming you are not factoring in royalties and bonuses)? Wrong. You get one week. Enjoy it. That means you just worked for one fourth compensation instead of standard one and half compensation that overtime would normally give.

Performance Reviews:

Fun fact about the games industry is that your performance review, the review that determines your promotions, bonuses, raises, and whether or not you get to keep your job, are based solely on your social status in the company and the amount of hours you put in. Performance is measured in how dedicated you are to the project, not necessarily how efficient of a worker you are. For example:

Developer A works 14 hour a day, finishes 15 quests and gets back 10 bugs.

Developer B works 8 hours a day, finishes 12 quests and gets back 2 bugs.

In logical terms, Developer B is the better worker. He completes more content per hour and does so with fewer mistakes. However, in the eyes of a game manager, Developer A puts in more hours and is therefore the better worker. Regardless of the fact that he actually works slower and makes far more mistakes. Most developers have learned this trick and as such are “willing” to work more hours. They have realized that it doesn’t matter how efficient or fast you work because all that is measured and compared is how long you were at the office. As such, you’ll find many developers goofing off during crunch. Because they know that they have to be at work for 12+ hours a day, regardless of the workload they have, just because their bonus, raise, or promotion is riding on it.

Overtime is a Necessity:

Crunch is not seen by executives as a failure on the part of management. Which it ultimately is. It is a result of over-promising publishers and investors, improper or unrealistic project time lines, deadlines, and scope, and feature creep. All of which are controlled solely by managers. Instead, crunch is seen by executives and managers as a “necessary evil”. They believe that they cannot manage and launch a product without it – which has been proven time and time again to be untrue. Overtime, of course, is a necessary evil. Sometimes things go wrong, deadlines must be met and a few people have to occasionally put in a few extra hours. Shit happens. However, that isn’t what crunch is. Crunch is a systematic failure in management and planning.

Additionally, there is an unfortunate allure to crunch that new and delusional game developers have. There is this social expectation that you have to work crunch to be a real developer. That you have to prove yourself by working crunch. That crunch is a badge of honor. These coworkers are what I call the “problem employees”. They are the saps that management love, because they don’t complain, they don’t argue for higher pay, raises, promotions, bonuses, or anything like that. They just do what they are told and do it with a smile because they love working on games. And the managers exploit and abuse this fact. They exploit the problem employees by using their own enthusiasm against them. And they abuse the rest of the employees by setting these problem employees as the example of a good worker.

There is a mountain of evidence to show that working long hours is bad, for the business, the product and the worker. For example:

Let’s say you are working 14 hours a day.

For the first 4 to 6 hours, you are highly productive. From hours 4/6 to 8/10, you are still productive, but less so. From hours 8/10 to 12, you have starting making too many mistakes and slowly becoming unproductive. You are still slightly in the green here, but your work is starting to suffer. Anything after 12 hours a day, you are in negative production. You have either stopped working completely and are now goofing off (typically interrupting your coworkers) or have begun making more mistakes than progress. At this point you are better off going home than anything else as all you are doing now is creating more work for yourself or your coworkers in the future.

And this compounds for every day you work more than 8 hours. Every day it gets slightly worse. You will reach negative production sooner. You will be highly productive for less and less time. And, your personal quality of life will suffer in relationship to your work. As your work suffers from prolonged crunch, your quality of life will drop sharply as well.

So, the product suffers because everyone is ultimately making more mistakes (more bugs, less polish, higher budget costs) and the developers suffer (lower quality of life). This is why crunch is ultimately bad.

Labor Laws:

In most circumstances, there are legal protections for employees. For the most part, there are none for game developers. In the state of California, for example, there are two exceptions to labor laws that the games industry falls into. Software Development and Entertainment. Each exception has different rules that the respective fields do not have to follow – the big one being the limits on the amount of overtime and overtime compensation. Now, each state and each country has different laws and regulations, but typically the game industry finds some exception or loop hole around those regulations. And ultimately the employees suffer. This is one of the reasons you will rarely see successful lawsuits against studios/publishers regarding the treatment of their employees. A company has to cross some very firm legal boundaries for any such suit to be feasible by one simple worker. More often than not, the lines that are crossed are fuzzy – even to legal experts – and any one worker would be overcome by the army of lawyers a publisher is going to be willing to throw at you.

So, in the end, you are on your own as far as legalities go. You are, more or less, completely legally unprotected in terms of working conditions, overtime, and compensation.

So how do we fix this?

None of the problems have easy solutions. You can see proof of that by visiting the IGDA forums. There are literally pages and pages of arguments on the causes and solutions regarding this very topic.

I do, however, have some suggestions:

First, legally mandated overtime compensation in some way. The reason we, developers, tend to get screwed on compensation is the non-binding pact we have with studios and publishers. That pact is that we will work longer hours for less base pay in return for a share of the profits in terms of additional compensation. Unfortunately, the company is not legally obligated in any way to give us this additional compensation and, more often than not, take advantage of this legal fact.

Second, better and required management training seminars and courses for anyone in a management position. Far too many managers in the industry have no formal training, no education, and no experience managing anything. This is one of the main reasons there are so many managerial problems in the industry – bad management. We need to make management better, by promoting and hiring individuals with managerial experience (preferably from outside the industry) and training the individuals currently in a management position.

Third, realistic and accurate performance benchmarking and tracking. As I said, most current performance tracking is done based on social status (Are you friends with the producer? Yes? Promotion!) or based on amount of hours worked – not efficiency. If developers were pressed to be more efficient, rather than working longer, it would alleviate some of the pressures and problems with crunch. The procedures and practices in the industry have not really improved. Documentation isn’t accurate or updated. Calling for efficiency over brute-force crunch would encourage managers and developers to find better ways to do things rather than just throw endless man-hours at the problems.

So, there are ways to improve the situation here, but they are outside the reach of one lowly developer.