Reacting to team process explosions – mitigating damage

A video game producer’s primary responsibility is to plan around the chaos of a team project. Producers typically love to see a well-executed process where everything is relatively under control. Unfortunately, in real life, it never quite happens exactly this way. Sometimes, the process just goes wrong.

When such a thing happens, it will challenge a producer. When the team panics, producers must stay calm and give the team direction. Different reactions will lead to different outcomes. In this blog article, I want to share my student game project experience in which I had to address several such blow-ups.

I was on a team game project at the Southern Methodist University (SMU) Guildhall as part of its Master of Interactive Technology program. On this nearly 50-person project. I was the Programming Producer in charge of the programming team. There were 50 developers on our team, and we made an underwater arcade racing game in Unreal 5. The game is well-finished and will be up on Steam soon.

As a Programming Producer, I encountered certain moments, especially in late production, when emergent things would cause the team to fall behind schedule. We had to employ several solutions to mitigate the damage from the “explosions.”

Let’s first plan to solve the problem!

When things go wrong, it is people’s natural reaction to figure out who caused the issue, which will easily end up blaming the troublemaker. For example, it could be a programmer accidentally deleting a file or a feature missing due to the producer forgetting to plan (both happened during our development). However, as a producer, I first need to find out how to deal with the issue rather than fixate on who causes it.

There are several elements for us to consider:

· What is the severity of the issue?

· What will it cost if we want to fix the problem?

The severity level determines how we want to deal with a problem. For instance, if we find that one feature is missing in late production, do we really need that feature? If the feature is non-critical (and implementing it would lead to some developers failing to finish what they are doing on time), then the best practice is to cut the feature. However, if the feature is critical to the game, then it is highly likely that the feature must be re-prioritized and implemented.

In this instance, we would need to consider ways to minimize the blow-up’s damage. For example, one day during the development of our arcade racing game, one of the maps is completely unplayable. The player was spawning in the middle of the track landscape. The team knows we must fix this issue, or we will potentially lose the whole map. We didn’t know if the map issue was caused by the designers’ work or the programmers’ blueprints since both teams had worked on the map. So, we brought most of that map’s designers and programmers to fix the issue.

The resourcing cost of pulling the designers was low since they had no map to work on either way. But pulling the programmers cost quite a bit because some of them were working on other high-priority tasks. In response, the Production team reallocated other programmers working on mid/low-priority tasks to those unrelated high-priority tasks - minimizing the cost.

After the plan is made, let’s sit down and talk it out.

In a team project or team studio setting, if something blows up, it mainly comes from the management or developer levels.

At the management level, most of the issues were related to the production pipeline. Our team game project’s management was composed of four producers and three disciplines based on their assigned disciplines. For example, as stated earlier, I was the programming producer, so I focused on the programmers.

It worked well in the beginning. However, things started to go wrong once we implemented a cross-disciplined strike team. At the end of the Alpha milestone, we created a strike team responsible for Menu and UI, and it consisted of two artists and one programmer. This strike team was positioned next to me and my Programming Lead in the studio room. Initially, I thought the Art Lead or Art Producer would give them directions – as the artists made up most of the strike team. However, the Art Lead later told me that he thought we would give them directions because they were sitting near us in the room. Consequently, those two poor strike team artists were not that “strike” for a few days.

When such communication pipeline issues occur, producers must reflect on the relevant pipeline and determine whether to make changes to it or not. The answer may be less obvious in other cases, especially when the pipeline has been established for quite a while. Changing the pipeline may also inadvertently make things worse.

There will certainly be times in which a specific developer causes the blow-up. When such a thing happens, no matter how simple the issue, always remember it is not their intention to mess things up. If they did, it would be easy to tell, and that would be a different topic.

In the middle of our Beta milestone, one developer accidentally deleted the .uproject file for the project from Perforce. For non-tech readers, it just means he deleted the project from the server side. He was trying to revert his changes and made a mess of it. Ultimately, it was a silly mistake, and it has nothing to do with his intention. And I believe the wise thing we did is that we didn’t blame him for it at that point but focused on how to recover the mess.

Conclusion

Producers must stay calm and give the team direction when things blow up. Our highest priority at this point is finding a solution to the problems and mitigating the damage. And after the team has a solid development direction, the leads need to figure out the reason behind it and find a way to avoid it happening again.