In this chat with Gamasutra, Zynga lead producer Tami Sigmund shares what she's learned about avoiding overwork and keeping crunch at bay while working on living, evolving games.

Can you share a bit about your background and experience with "games-as-a-service" or live ops in game dev?

I’ve been working in games for 12 years, and aside from a brief 3 year stint working on the company brand team at Riot Games, all of that time has been spent working on freemium games-as-a-service (starting on Facebook, then into mobile). I’ve worked in both community & production on games at companies like Disney, Playdom, PopCap, and now Zynga.
 
Have you ever crunched (however you define it, though we typically start at "working more than 40 hours a week because you were asked, expected to, or afraid of the consequences") on a live game? If so, why?

Yes, though admittedly much less than others. I feel that the mobile/social space tends to offer a bit of a shield from traditional AAA “crunch culture” because development pipelines tend to model non-games tech industries. However, I have certainly crunched.

In my first job, there were times where I’d put in a bunch of extra time out of my own free will -- typically when others were doing it because they were so invested/passionate about our startup and I wanted to be “in the trenches” with them. I’ve also experienced mandatory crunch at a previous mobile games studio when we had unmovable submission deadlines that could make or break our game launch. During these times, as a Producer I’d often be there for morale support with the engineering team.

Have you ever worked for a significant amount of time on a live game without crunching? Did you or anyone else feel any pressure (from within or without) to work harder on the game, and if so, why?

Yes, I’ve actually crunched very little overall in my career. I’ve been fortunate to work at studios that value work/life balance and treat their employees as human beings with lives outside of the office. However, any time you’re working on a creative project, which is a passion for many - you’re going to feel a pressure to put in as much time as possible to cross every "T" and dot every "I". With traditional development schedules, developers are often forced to make hard decisions in order to meet deadlines. There have been plenty of instances where the schedule only allowed for the highest priority tasks, but the  lower priority ones felt important too – so it’s common to struggle between what should be included or not. However, it’s a slippery slope that can sometimes lead to scope creep and an unsustainable pace that has potential to burn developers out. 
 
There’s a pressure that creative people inherently inflict on themselves. We want to put our name on products that we’re proud of.
 
What's the key to sustainable, effective live ops game dev without crunch, in your opinion?

The key is a studio culture that views crunch as a production failure at all levels, and a development process & pipeline built to avoid crunch at all costs. You can’t have one without the other and expect to actually avoid crunch.

During my interview at Zynga Austin, I came in with baggage of being a single parent who just assumed Zynga was the kind of ruthless company that would require long hours. I was beyond surprised when one of the producers who interviewed me was a single parent too. Several of the women who interviewed me were also mothers. One of the Executive Producers flat out told me that this studio doesn’t crunch that he considered crunch to be a cosmic production failure and that the last thing he wants was for his production team to fail at anything. I’ve now been here for 1.5 years and have never stayed later than 5:30pm. I’ve been able to pick my son up from preschool and have dinner with him every night. While also being Lead Producer on a successful freemium mobile game with hundreds of thousands of daily players. This wouldn’t be the case if the studio leadership didn’t strongly advocate for it. Player-focused companies like Zynga often have the added benefit of being developer-friendly too, since devs are also players.
 
There’s a common belief that “live ops = unpredictability”, and while that’s true for some aspects of development, I believe that running a live game is a ton more predictable than a game in development. The trick is setting a cadence schedule that you can reasonably commit to, that has enough wiggle room within to adapt to change as necessary. For the games I work on, we commit to releasing a new feature  to our players every two weeks. This is an extremely predictable and regular cadence, so the team that is working on those features  has a rigorous and tight pipeline that’s well-staffed to support that ongoing content without requiring extra hours from anyone on the team.  
 
Any specific production practices, tools, systems, etc. that you would recommend to other game makers working on live games?

Build extensible engineering solutions the first time, so that if things go wrong you have kill switches and fail safes so that recovering from live ops  challenges is something that can be done quickly and without much work from team members outside of work hours.
 
Build in at least 20 percent extra time into your schedule to allow for pivots, but don’t eat up that time if you don’t have to. Instead of stretching work to fill that schedule, build up a bank of extra lead time so that you can expend it on things like -- passion projects that the dev team wants to work on, going above and beyond on particular features, or learning & development time for the team.

Make sure whatever Gantting or tasking software that you’re using takes PTO into account so that you’re not expecting people to do more with less time. Well-rested, fresh game developers do better work. Taking time off should never be a punishment, and schedules should allow people to do so without it feeling like “a trap”.

Create robust reporting & retrospectives on live ops. There’s nothing more frustrating for a team than having to crunch and stress when the issue was preventable because it had already happened before. Learn from past mistakes and iterate on processes to prevent history from repeating itself. What happened, and how the heck are you going to make sure it doesn’t happen again?

Do whatever you can to rotate your “on-call” developers so that the same people aren’t giving up their evenings and weekends over and over again.

Lead by example. If you don’t want people to be pressured into crunch, don’t set up a precedent where they’re receiving emails and Slack messages from you at 10pm at night. Even if your intentions are good, this makes people feel bad that they’re enjoying themselves while their bosses are putting in extra time. Avoid the optics of looking like you’re overworked -- save the emails for the morning.

Your production process is never “finished” when you’re on a live game. Always seek ways to iterate on it, improve it, and change it as the team and product changes throughout its lifecycle.

To many, working on a live game is the “less sexy” side of working in games. Most creative people want to be on something brand new, have a hand in shipping a fresh game to players. Live ops game teams require a careful eye on morale because team members can often get burned out and tired of working on the same IP.  Seek opportunities to have them do new things outside of their comfort zone, learn new tools, and offer them ways to breathe new life into the game so that things avoid being stale.
 
If you do require extra hours to hit a milestone, it should be owned as a production and business failure and communicated as such. Some companies have offered days of “comp time” as a result. If you’re requiring a team to give up an evening, they should be granted back a half day of time.