Game crunch lessons: How to avoid game development crunch

Game crunch has been a recurring conversation in the industry over recent years. Although 100-hour weeks are certainly not normal in games development, having to put in multiple extra shifts during deadline periods is not uncommon.

Yet crunch is not just bad for staff, it can be bad for business. There's plenty of evidence that tired, overworked staff perform well below standards. When I worked in QA myself, some 11 years ago, the bugs I reported for Ratchet & Clank: Tools of Destruction at 3am one morning needed completely re-writing the next day. They were unreadable. Crunch is bad for the team and it's bad for the business.

Avoiding crunch isn't easy. Simply saying that it's down to 'bad project management' isn't especially helpful to anyone. What is bad project management? What is good project management, for that matter? What tips and tricks could be used to reduce overtime and crunch as much as possible?

Here are some lessons on how to avoid video game crunch from those who have experienced it themselves. Experts from Wish Studios, Hutch, Criterion and Bungie give us some answers:

Casper Field, ex-studio head at Wish Studios

Best Places To Work in the UK, small company winner:

"I worked some pretty horrendous hours in my 20s when I was establishing my career. Starting out in journalism in the '90s, I was normalised to the idea that 12 to 14-hour days, even working through the night on a heavy deadline, was what it took to get the job done.

But as I've learnt over the years, the issue was down to a combination of commonly occurring issues. These I would summarise as:

• poor planning by (often inexperienced) managers
• under-staffing of the team
• over-specification of the product
• refusal or inability of middle management to push back on demands from above or outside

It's usually a fatal combination of those factors.

The myth arises that working late will fix the problem. To be fair, if used very sparingly, for a day or two, I think that additional hours can help if something is in crisis, but over the long-term they are never the answer. The solution is to plan sensibly, to trim specifications, to hire enough people, and to learn that it's okay to say no to external forces now and then.

Equally, you cannot lean on just one of those solutions -- it has to be a mix. Is it really worth staying late to implement a 'cool' feature that 95% of users will barely notice? What are the knock-ons of that feature on other parts of the development team? I would argue it's a waste of time, or even worse, outright risky for the entire project. I think that the decision-making related to feature-planning grows more confused and less logical as accumulated exhaustion kicks in. I know, because I've done it myself.

"There is a dangerous notion of team members being 'heroic' when individuals pile into problems and crunch like crazy to fix them"

Casper Field

You also need to be honest with your team -- it might seem cool having people start at 10am or later, but that leads to leaving at 6.30pm or later. There's still a working day to be done. That's why at Wish we operated a standard 9am to 5.30pm working day, with an hour for lunch that we encourage people to take (and to get out of the office, or at least sit in the kitchen, to get away from their screens). We flex 30 mins earlier if it helps with school or travel, but that's it. Come in, work your day, go home, live your life.

Similarly, eating pizza while 'working late' usually means you're not really working -- you're just sat around the office ordering and eating often middling-quality food while not achieving much at all. And how much more frequent are bugs in code that's written at 10pm, versus work done in the normal working day?

There is a dangerous notion of team members being 'heroic' when individuals pile into problems and crunch like crazy to fix them. I find this entirely toxic and incredibly risky. What does it say about accountability, about planning, about culture? If you're at the point where this kind of behaviour is necessary, guess what? Someone, some people, messed up badly, and there's nothing 'heroic' about it -- it is indicative of a failed process, and it should never be celebrated.

Back to where I started out, as a young, inexperienced team member, I should never have been put in the situation of working 12-hour days, week after week. 20 years later, I know it still goes on in some places, and it is well past time that we, as an industry, make clear that it is unacceptable."

Shaun Rutland, CEO at Hutch Games

Best Places To Work in the UK, mid-sized company winner:

"Avoiding crunch is fundamental to the way we operate. As a mobile, free-to-play, games-as-a-service company that serves millions of daily active players, we need our team to be happy and productive, so crunch simply doesn't work. 

Teams who are having fun make better games and making games should be fun -- otherwise, what's the point? We have a responsibility to our staff to ensure our development culture and processes foster a productive, creative and motivating environment. There's always enough work and urgency from our players that we could easily ask them to work 12-hour days, seven days a week. There's just no let up in our opportunities so we simply never allow it to happen. It's zero tolerance attitude towards crunch. 

"Ultimately, crunching is a result of feature creep, design iteration, poor planning or, most commonly, an all-or-nothing approach to design, which is often mandated from the top down. Understanding and appreciating lean development is about understanding what is valuable to the players, prioritising the core quality of the product over everything, and trusting your team to execute and understand their audience. We have greater access to our players than ever before. With beta programs, early access systems and soft launches now commonplace, there is no excuse.

Here are my key tips:

• 1. A leadership team that fundamentally understands that crunch doesn't work as a planning option. When developing games-as-a-service the workload increases and evolves after launch once you are supporting a community. If you've burnt out the team by the time you launch, you're not putting yourself in position to succeed.

"Teams who are having fun make better games and making games should be fun -- otherwise, what's the point?"

Shaun Rutland, Hutch

• 2. The leaders in the business need to lead by example. Avoid sending important emails on week nights or weekends and encourage holidays and long breaks. Your next big idea will come from rested and motivated staff returning from holiday.

• 3. At Hutch, we use lean methodology; if we are working on something that takes a long time, we break it into smaller and manageable pieces of work. Our teams are encouraged to estimate honestly -- it's this honest, bottom-up approach to planning that enables the team to make the right choices and manage their own work and time.

• 4. Bottom-up planning means staff are defining how long it takes and therefore are accountable for their estimates. Sprint retrospectives enable the teams to reflect on their planning accuracy, which then makes planning in future better.

• 5. Adopting agile and lean help with better planning and ensuring good work life balance.

Having said that, we are in no way perfect. Our team, on their own volition, sometimes work long hours because they either feel they need to or want to, so there's still some work to do on this. By getting our team to define their tasks, and by fostering an accountable and inclusive culture for planning, they're taking responsibility for their work load. As we are services company, we do require after hours support from engineers from time to time. We rotate this across the team and ensure they're not doing excessive hours as well. 

But in summary, you need leaders who fundamentally understand that crunch doesn't work in the long run. Games-as-a-service is ideal for moving away from date-driven and feature-bloated development. Empowered and responsible teams that define their own work schedule ultimately plan better and deliver better work.

Matt Webster, VP at Criterion

Best Places To Work in the UK, mid-sized company winner:

"If we commit to respecting the time, livelihood, and continued growth of our teams, we will not only avoid crunch but rule out its existence entirely"

Matt Webster, Criterion

"Developers love to final. This is the period when we go the fastest. We build fast, we play, and we change fast. We communicate, and we make decisions. We come together, and we prioritise. There's no reason that these actions and behaviours have to wait until the end of the process -- make it happen way earlier in your timelines.

There's a wealth of research from across various industries that shows you that crunch reduces output. In the games industry, we think we're special and that this research and data doesn't apply to us. The reality, of course, is that it does apply. We're seduced by crunch in finalling, but it's dangerous and if unchecked it will bring real harm to your people, and subsequently your business.

There's just really great work out there that shows you crunch doesn't help your outcome. For example, the Game Outcomes Project communicates this in real detail and concludes: "Crunch does not in any way improve game project outcomes and cannot help a troubled game project work its way out of trouble."

If we commit to respecting the time, livelihood, and continued growth of our teams, we will not only avoid crunch but rule out its existence entirely.  

Be honest with yourself and others about where you are right now and where you can realistically get to in the time you have. Plans based on hope don't work -- you can't hope it all fits and expect a good outcome.

Choosing not to start work on a feature that you can't finish is behaving 'player first', because you focus on finishing the rest of the features to higher quality. Trust your people. If they say it takes an amount of time to do something then don't push them to halve it. If you stop focusing on working longer you can focus on working smarter. Never underestimate the productivity boost of a well-rested, happy person. Regularly get candid feedback from your team and measure their health. Listen to what they say and act on it.

Don't be afraid to cut lower priority features or content, the earlier the better.

Make decisions early. An incorrect decision made is a lot better than not making any decision at all. It helps to move you forward quickly and make other decisions that stem from this. It also lets you see a lot sooner whether you've made a bad decision or not. If those decisions are based around scope and cutting features, then inevitably you will have also wasted people's time and energy for working on features that could have been cut earlier. Those people could have been working on adding quality elsewhere.

Decisions are sometimes hard, sometimes unpopular, and sometimes you don't have all the information available to back them up. But you need to make them anyway or you can't move forward.

Everyone has to believe and want to work in a better/different way -- especially the leadership. Work together to agree on the rules, such as core hours, lunch times, game times, flexi, and so on. Don't celebrate or reward bad behaviours, in any way. 'She's just passionate', 'it's only one late-night' -- if you really have to compensate for these moments, then spend time understanding what led to them.

Live the behaviours you want to see. If you believe everyone should leave at 6pm... Then leave at 6pm. Be mindful of your leads and managers. These people tend to be the ones that will always work a little extra and more frequently, which can sometimes result in more junior members of the team looking to this behaviour as the way to behave. A team reflects its leader.

There's a big fear out there about whether a product is good enough and often there's not enough tools to measure this accurately. This leads to management just putting in more features, more hours and more people onto a product, to try and alleviate that fear. It's important to not give in to this easy way out and to keep the faith. Believe in your original vision and the implementation of that in the software.

Software is the truth. At the most basic level, if you don't have any other tools to measure the quality of what you're doing then at least you have the software. If you can play the game on a regular cadence, then you are able to review and gauge the quality of your software. This helps to reduce that fear.

"Teams will add every single idea and feature they can think of if you let them"

Matt Webster, Criterion

Leadership has a responsibility to the product and to the studio to ensure that the best quality product comes out at the end. Quantity does not necessarily equal quality. Editing a feature set and looking at a product holistically should allow you to edit out a great deal of things that don't add a great deal of value to the player. Focus on the most important things to the player. Player first. Don't give into fear and keep adding more features.

As well as a responsibility to the product, leadership has a huge responsibility to the team. Teams are passionate. Teams will add every single idea and feature they can think of if you let them. They'll work on features until they drop, to try and add as much quality as possible if you let them. It's up to leadership to have the responsibility and discipline to know what they are making, to not bite off more than they can chew.

Luke Timmins, Bungie

Speaking at Casual Connect USA 2017, Timmins traced the evolution of Bungie's approach to "people management" in his 16 years at the company, which he joined as a tester five months prior to the launch of Halo.

"Your manager is responsible for your happiness, your engagement, how you're actually doing as a person, how you're doing in your craft as an engineer," he said. "They're also responsible for your career planning. That's what management means at Bungie."

"The Halo 2 crunch almost killed Bungie as a company. It is the most I've ever seen humans work in a year and a half"

Luke Timmins, Bungie

It wasn't always the case. Timmins described the 18 months leading up to the launch of Halo 2 in November 2004 as "brutal" on the company's workforce, and its engineers in particular. Bungie was in a state of crunch for virtually that entire period -- based on Timmins' definition of crunch as "whenever you're working at least 50 hours a week."

"The Halo 2 crunch almost killed Bungie as a company," he continued. "It is the most I've ever seen humans work in a year and a half. It was brutal.

"It almost killed us, and those of us that were left basically vowed 'never again'. Never again can we put ourselves through that."

The strain of that time led to a new way of thinking about crunch within Bungie.

"There's the crunch you want to do, and there's the crunch you have to do," Timmins said.

The latter, where employees are required to work 50 or more hours a week to ship the game, is the more "nefarious" form of crunch. However, while the former is mostly driven by positivity and passion, it can still result in a negative outcome for both the individual and the company.

"The one you want to do can be awesome, because you have passionate people who are excited and have cool stuff to work on. That can be really good, but you've got to be careful. People can be super excited and before you know it they're working a ton and getting burned out."

Timmins warned the Casual Connect audience that crunch will become part of internal culture faster than most expect -- and it will take far longer to purge that from the company that it did to take hold.

"When your company is used to crunching, not relying on crunch to ship is now hard," he said. "Un-ringing that bell is very difficult. It requires changes to planning and culture, which takes a long time to do. It took us years and multiple games to move away from crunch philosophy."

With Halo 3, Bungie started to think about "people management as a craft" in greater detail, laying the foundations of a new philosophy intended to improve trust and communication within the company. The "bedrock" of this new approach to management were "one-on-ones" -- mandatory weekly meetings for every employee and the manager assigned to them.

"When your company is used to crunching, not relying on crunch to ship is hard"

Luke Timmins, Bungie

"Once a week, you'll probably find half of Bungie walking around Bellevue park," Timmins said, stressing that the goal of these meetings is to reach beyond the "cultural programming" that makes most people pretend to be fine when asked by a superior about their wellbeing. The one-on-one meetings are used to set goals and targets for each individual, which are then reviewed by all of Bungie's managers every six months.

"You should take this seriously, but it's not free," Timmins said. "If I'm a manager, every report I have is about 10% of my time... It's really hard, and you're constantly going to have that pressure: 'Can't we just skip one on ones? Can't we just skip your goals for this period?'

"The answer is no. People management is more important than that one extra feature."

By the time Bungie launched Halo Reach in 2010, at which point work had also started on Destiny, it became clear that one of the outcomes of a culture of crunch is a lack of trust in management. The system of one-on-ones and reviews was put in place for the benefit of the company's employees, but it lacked transparency.

"Building a system that's not intentionally opaque is not the same thing as making it transparent," Timmins said. "The downside is that it can take years before people really believe that there is no smoke filled room at your company, and there's no big boss with a cigar saying: 'That guy gets a promotion.' This is hard to do."

Bungie's managers started to meet with the employees they supervised before the six-month review meetings, to detail what would be discussed. Not everything would be positive in some cases, but Timmins said the benefits of that honesty and transparency were immediately obvious.

"That relationship is gold," he said, adding that Bungie also places great importance on managers supervising the same employees over long periods of time. "That relationship could be the thing that keeps a person from quitting. That could be the thing that saves them."

"It can take years for a culture to develop; for people to believe it's okay to take a vacation"

Luke Timmins, Bungie

Destiny brought the final stage of the process: enforced vacation, a measure directly related to, "the crunch you want to do." Bungie gives its engineers 40 days off each year, but whether through paranoia or passion, a lot of employees simply weren't taking the opportunity for a break.

"A lot of people get burned out because they don't take the vacation, so as a manager part of your job is to make sure they do," Timmins said. "Leadership needs to set examples. It can take years for a culture to develop, for people to believe it's okay to take a vacation, that it's not a crazy crunch culture where something bad is going to happen when they come back."

Destiny was the last "department-wide crunch" for Bungie's engineers, Timmins said, but there was none at all on its various DLC releases.

"Destiny 2 [was] our fifth release -- we've done all these DLCs with no full, enforced crunch. We've very proud of that. It took us a long time to get there from the Halo 2 days."

Part of that is better development processes, but Timmins insisted that the majority was down to better and more personal management of people. It allowed Bungie to address and reduce both the crunch you have to do, and the crunch you simply want.

"With crunch, and it's not just engineers, it really is the buy in from everybody," he said. "We always have designers who think a feature is going to be amazing, but it's over by four months and it's not going to fit. On Halo 2, I was that person, and before you know it I'm there every day until 4am and I never see my wife.

"The majority of it is always having enough awesome ideas and things you want to build, so you always need to have that rigour. 'No, we can't do that, and that's okay'. The second you don't, the whole thing falls apart."