How to Manage LiveOps Burnout

Many GAAS games take five years or more to develop. Once you go live, you are not at the end of the development process, but rather at the beginning. You exist in a constant release mode rather than building for a single release. The pace is much faster, and depending on the content treadmill you’re on, it can be exhausting for developers. I always tell people it is a marathon, not a sprint.

I recently had a great discussion in a private forum, and I wanted to share some lessons that other developers and I have learned from running live games and how to prevent burnout.

It is essential to choose the right individuals for live development. Live games can often be chaotic, as you constantly evolve and enhance the product. Working on live games is a contact sport with the community. Depending on the community's sentiment, this can be both good and bad. Many times, I have faced difficult launches or patches. I have been threatened and harassed online by passionate players. As a developer, you must have tough skin and recognize that the vocal players represent a minority and may not comprehend the real cause of the issues they are experiencing. This is why you must assess which team members are appropriate for live development. I have found there are two types of developers – builders and finishers. Builders prefer a slower pace, a less chaotic and more predictable environment, with reduced contact with the community. Finishers aim to get things into the game as quickly as possible, favoring fast-paced development, and appreciate immediate feedback. They don’t dwell on ideas. In my humble opinion, they are best suited for a live environment.

 Recognizing burnout

 At your weekly or biweekly team check-in, ask everyone to place themselves on a 4-quadrant chart with two axes: high vs. low energy, and positive vs. negative mood. 

• High energy, positive mood = performance
• High energy, negative mood = survival
• Low energy, positive mood = recovering
• Low energy, negative mood = burnout

This gives you a way to monitor the team's health. Also, during 1:1s, look for these four key indicators of burnout:

• Exhaustion - a complete depletion of energy reserves, making it difficult to move or think
• Cynicism - a persistent belief that work will fail or hold little value
• Depersonalization - feeling detached or disinterested in work
• Self-efficacy - the belief that one cannot perform well

How to Prevent Burnout

1.   Watch out for developers who don’t manage their work-life balance well -They pour their heart and soul into the game at the cost of their well-being. Ensure they don’t take on too much and encourage them to delegate their workload. I truly appreciate their dedication, but I don’t want them to harm themselves physically.

2.    Allow Designers to Switch Up Their Work - A major, major trap I've seen is that Someone is good at developing one type of content for these projects, and, oops, that's the only thing they've done for three years. Check in regularly to see if your team members have skills they want to develop or, more likely, have existing ones that are going unused, and make sure to utilize them. In my experience, the trick here is to get production to approve this—adding extra time to allow someone to ramp up or learn something new is daunting when the train is coming down the tracks, no matter what, but it's crucial, IMHO, for team health. 

3.   Seek co-developers to help scale the team effectively. Finding a suitable co-developer is crucial for achieving rapid growth. Additionally, this eases some of the content pressure on the development team. However, you should look for co-developers during production so they can contribute without overburdening your development team after launch.

4. To alleviate the constant stress of keeping the service running and finding time to dedicate your core team to content generation, divide the live team into three strike teams.

• The first is the “DevOps” team, which manages the daily operations of the game. They address bugs, exploits, security issues, minor updates, and the store. I rotate team members in and out so that everyone understands what it’s like to support the game on a daily basis. This experience allows them to see the consequences of poorly released patches. This team serves as a buffer for the content teams, enabling them to focus on creating engaging content for players.
• Form two content teams, Team A and Team B, to develop the larger content releases for the game, and typically, I have them leapfrog each other.

5. Consider content in terms of seasons and episodic structure. The goal is to maintain a constantly evolving game experience for players and creators. It also allows a beginning and an end to content, which provides more room for creativity.

6. Develop a visual staffing plan and roadmap. Early long-term planning for the next 6 months to 1 year gives people time to select projects they’re passionate about and fosters idea incubation. It also allows more flexibility to adjust the plan according to the team's bandwidth. When doing this:

• Balance rotation and stability: Rotation helps refresh creatives, but the change also resets the team-building process. Rotation is most helpful near the end of a release cycle, like a seasonal content update.
• Enable focus: Assign one person to one project at a time to reduce context switching and competition for support between teams. If multitasking is unavoidable, clarify project priorities across the team to avoid overloading individuals.
• Enforce margins - Two strategies we implemented that proved most effective in avoiding crunch time are: (1) strongly advocating for early playtests and shippable products, and (2) ensuring that milestones are established to allow dedicated time for iterations, beta testing, polishing, and bug fixing before releasing an update.
• Ensure backups: Aim to provide everyone with at least one backup or a work buddy for their role.
• When possible, separate feature development from seasonal deadlines. Keep major features in beta until they are completely ready, which helps to minimize rushed releases and technical debt.
• Hire junior team members and utilize them as a live training ground for your studio. Being new to the team, they can provide a fresh perspective on the game.

7. Hold a Game Jam at least once a year to break up the pace of delivering updates to players and to provide a creative outlet for everyone on the team to generate exciting ideas for future updates. I usually set aside two weeks in the schedule for the team to pause game development and participate in a game jam. This functions as an excellent team-building exercise. People form teams and present their ideas to the group at the end. Additionally, this allows team members to collaborate with colleagues they don’t typically work with.

8. Empowering everyone to be the game's author—no team member should make content decisions alone. In my opinion, avoiding a situation where a closed group of stakeholders dictates the team’s work is crucial, as they often do not engage with individual contributors. Frankly, this is not optimal for team morale. Set goals and problem statements during long-term planning while allowing everyone to provide input on how to achieve and resolve them. Clearly, leadership must make the final decisions about what happens, but ensuring the entire team has a voice is essential.

9. Take time to celebrate significant content updates. When the team works on a major update, treat it like a small game launch. Do something special for the team and incorporate a few days into the schedule to relax. You don’t want to merely acknowledge it happened while focusing solely on the next project. That can be demoralizing for the team. 

10. Organize community event(s) for the dev team to engage with their community in person at least once a year. This serves as a significant energizer for the team.