Results from the Game Developer Quality of Life Survey are in: Happy developers make better games, working longer regular hours means working longer crunch hours, and unhappy devs will find new jobs.
Game Developer magazine surveyed 1051 game developers, ranging across development discipline, studio size, and targeted platforms, about their satisfaction with their jobs, careers, compensation, and projects. Here are some of the key findings included in the March 2013 issue of Game Developer magazine:
Job satisfaction: 29% of developers reported feeling "very satisfied" with their jobs, 39% "somewhat satisfied," 13% "neutral," 13% "somewhat unsatisfied," and 6% "very unsatisfied." Developers were far more likely to report higher levels of job satisfaction if they had a flexible work schedule and the ability to work from home.
Game quality: Developers are largely optimistic about the quality of their current project: 31% report they are "very confident" and 36% are "somewhat confident," compared to 16% "neutral," 11% "somewhat unsure," and 6% "very unsure." A whopping 88% of developers that reported being confident in their game's quality also report positive job satisfaction.
Connecting workload to success: Developers on 51- to 60-hour work weeks are the most likely to report their last project as a market success (64%), followed by devs on 40- to 50-hour weeks (60%), 6170 (50%), 7180 (43%), and less than 40 hours/week (38%). 70% of devs who never work weekends or holidays report having successful projects, compared to only 43% who worked weekends/holidays at any frequency. Also, about 60% of motivated teams had successful projects, compared to 40% for unmotivated teams.
Crunch time report: Crunch times vary rather wildly. 7% of respondents report working crunch schedules less than 40 hours/week, 25% work 4050 hours, 27% work 5160 hours, 20% work 6170 hours, 12% work 7180 hours, and 10% work 80+ hours. These schedules rarely last more than four months; 29% report crunch cycles that last less than a month, 30% 12 months, 23% 34 months, 7% 56 months, 3% 78 months, 2% 1112 months, and 3% more than a year. (One wonders at what point a yearlong crunch cycle is simply considered a typical work week.) We found that simply having crunch cycles was enough to dent reported job satisfaction, though the duration doesnt seem to affect that factor.
Interestingly enough, 38% of devs who regularly work less than 40 hours and 32% of devs who regularly work 4150 hour weeks do not see their hours increase during a crunch cycle, compared to 25% for devs with 5160 hour weeks and 7% for 6170 hour weeks. Essentially,the longer your regular working schedules are, the more likely you are to work even longer hours during crunch, not less -- something to keep in mind next time you're asked to work longer hours during normal dev cycles in order to avoid crunch later on.
It's good to be in management: Managers are twice as likely to be satisfied with their jobs, more likely to be allowed to work from home (56%, compared to 29% of non-managers), more confident the product will be good (75% compared to 61% of non-managers), and half as likely to report a very negative impact on their family and social life during normal dev cycles.
Compensation and benefits: When it comes to compensation, 13% of developers feel they are very well compensated, 35% feel fairly well paid, 25% feel neutral, 19% feel fairly underpaid, and 8% feel very underpaid. Unsurprisingly, feeling adequately compensated strongly correlates to job satisfaction.
Layoffs: 23% of developers expect layoffs after shipping their current project, but the fear of layoffs is greater than the actual layoff rate, which, according to the Game Developer Salary Survey, typically hovers at around 12%.
Devs will leave: Devs are largely split over their future at their current company; only 55% say they want to be working at their current company in five years. Of the devs that want to stay, 90% of them also report positive job satisfaction, while only 3% of the devs that want to stay report negative satisfaction, which indicates that devs will leave if they're not satisfied.
For the full results from the Game Developer Quality-of-Life survey, check out the Game Developer Magazine March 2013 issue, which also features a postmortem of Telltale Games's The Walking Dead, an interview with Epic Games CTO Tim Sweeney on the future of engine tech, and more. You can also subscribe to Game Developer magazine, or download the Game Developer iOS app.
|
Regrettably, however, many of the bean counters won't budge from draconian perspectives without some kind of documentation or study done on any issue. So at least this can exist for that.
Your part about Devs will leave gave me some insight as to how things work. I never really imagined that many devs would leave during this current market. I guess if they are good at what they do finding a job is no real trouble in the long run.
For example:
Instead of Happy Developers make Better games... It could be that developers who make better games are happier.
I was an unhappy employee that produced poor games. Everything I say here is experience and opinion. But the biggest lesson I learned was that no one thing caused the problems. Noting was cut and dry right or wrong... but everything little thing compounds over the course of the problem.
It wasn't that "We made bad games because we worked too much overtime."
- We worked overtime because we planned poorly and kept running into "To Be Designed" sections
- Because things were poorly planned and written at the last minute... we couldn't polish it or ensure a consistent design.
- Because we worked constant overtime we were all tired and prone to mistakes and poor communication.
- Mistakes and poor communication lead to having to work weekends to make up for past mistakes... rather than to get ahead.
- These led to more problems... which lead to more problems... which lead back to the designer who couldn't catch up and design the TBD sections.
Everything effects everything.
I didn't make a bad game because I was unhappy... and I wasn't unhappy because of overtime. I didn't feel uncompensated because they didn't pay me enough. Every little thing added up.
We made a bad game because of a mistakes in our process. We worked overtime to compensate for mistakes in our process. I was unhappy because the mistakes in our process forcing me to work overtime and the fact that I could see the potential for a great game falling apart. It all added up.
From my point of view, I can't believe the interpretation "If we make developers happier they WILL make better games." but to learn what development methodologies worked best to make better games without killing the developers.