The following excerpt is from Great Games Need Great Leaders: Multiclassing to Lead Game Development Teams by Matthew John Dyet. The book will be published August 30, 2024 by CRC Press, a division of Taylor & Francis, a sister company of Game Developer and Informa Tech. Use our discount code GDTF20 at checkout on Routledge.com to receive a 20% discount on your preorder. Offer is valid through October 1, 2024.

Leadership

When starting a new position as a leader, we may take up the shield and set our intentions on the protection of the team. We might place ourselves out in front of them, directing them to where you need them to go while protecting them from the unexpected. The team comes to rely on us for direction and protection. We are out in front, sword in hand, team at our back. We charge into danger on their behalf and hack away the things that keep them from success.

Our mantra may be that we would never ask the team anything we would be unwilling to do ourselves. We work late nights in service of the game and the team, but we refuse to ask the team to do that themselves. By the time we finish that first game we feel exhausted, but we are satisfied that we did everything in our power to protect and lead the team. We got the game out the door. We have successfully released a game, and that is no small feat.

But the team seems dissatisfied with our performance. We were so focused on their protection that they avoided bringing their problems to us, meaning we often got surprised by threats at the start of the project. We started being nosy in order to protect the team from threats. Control of the project was reliant upon us, as nobody could make a decision without our involvement. As a result, the team felt creatively stagnant.

We led from the front, removing the ability for people to go out seeking their own paths or more effective solutions. Without their input we lead the team down dead ends. Our constant need to jump to the defence of the team leaves the team feeling like you don’t believe they can fight their own battles. They didn’t feel empowered by our actions, they felt that we did not trust them.

This theoretical leader tried to do everything right. They had the team’s health and wellbeing at heart, and made it their responsibility to try and protect these things. But the reality is that for us to improve we need to first let go of any preconceived notions that we understand what leadership is. Leaders are not just experienced members of staff. They are not just protectors, advocates, or vision holders. They are all these things, and they change based on the needs of the moment.

Leadership in the studio is responsible for two things: the business and the people. We may have a publisher, development partners, clients, or stakeholders. These are all specifically business concerns, however. We are responsible to all of them, and where they land in our list of priorities will depend upon our title and where we exist in the studio hierarchy. The people in our team are always equal in priority to all these business concerns.

Where many leaders in the games industry fail is by focusing more on the business than the people. We are never just developing a game for a business, we are also developing the people employed by the businesspeople work on the games we sell to maintain the business, and in return the business pays the people. Ignoring one is detrimental to the other.

This failing then is likely the fundamental motivator for the focus on people that came with every leader I spoke to. We were not discussing how projects get made or how to balance budgets, these things change depending on our position and place in the hierarchy of a studio. The one thing that every leader shares in common is the people that they work with.

The reality of making games is that the individual games aren’t the product, the people making them are. We might make a single great game, but it will likely be our last if we fail to maintain or support the people that made it. A team will only go on to make more great games if they work for a business that respects and empowers them. Our responsibility as leaders is not to make great games, but to empower and retain the people that do.

It is telling then that so many leaders in the games industry discourage unionisation. I have spoken with leaders in past who explained this rose out of a concern for the employment of their teams. They were worried about reprisals by businesses, or funding going overseas. There are absolutely challenges and risks involved with unionisation, but these things do not outweigh the value of a strong union presence. As leaders, we should be pushing to ensure our teams are cared for. This can only truly happen if they are empowered to hold their businesses and its leadership accountable.

Great leaders are not only willing to be accountable, they also actively seek improvement. They action the feedback they hear from their teams. They adjust their practices based on the input of others. This need not just be feedback about their personal performance, it could be feedback about the direction the project is taking or how things are being managed. Sometimes it is difficult to hear that feedback, but they have chosen a path of self-improvement. Every great leader is always learning what the best possible practice looks like, and are improving upon their own skills and techniques. Great leadership is the sum of its parts.

The characteristics of leadership are universal. It’s not attached to a specific role or position in a hierarchy. It would be incorrect to say that a leader is somebody who has command over others. A leader is anybody who chooses to act with self-awareness of how those actions may impact upon others. They are somebody whose behaviour inspires and motivates the people around them. They take responsibility for people, for projects, and for processes. Anybody can be a leader.

There is no one way to lead people in the games industry, however. The expectations of a leader in a publicly held AAA studio will be incredibly different from those of somebody leading a small indie team, to say nothing of the cultural differences depending on where it is they are leading from. Great leaders understand adjust appropriately to their environment. The people and the projects change, and so the leader must be willing to change too.

We may find ourselves put in a position where our options are limited. We have been given our own instructions from leadership above us. Even if we disagree we just have to enact it. It can be easy in such circumstances to feel powerless, to give up and walk away from the idea of improving our leadership when the people we report to are all too content in their own mediocrity. But today our team needs us to guide them out from the darkness, so that we might be better prepared for that moment in which we have the capacity to avoid putting them in a dark place in the first place.

Great leaders are set apart by their adoption of ongoing learning and improvisation. Every tool or skill that we have at our disposal has examples of both good and bad ways in which it can be used. We can very easily make wrong decisions for all the right reasons. Taking on the responsibility of leading others does not mean that we are perfect or avoid failure, but that we embrace and learn from our failures. It is the only way we can grow as great leaders in our own right.

Working in the games industry means that every day is different. We work on creative products that have an immense variety of challenges and potential complications. We work with creative people who come from a variety of artistic and technical backgrounds. Leaders reside at the point between the project and the team, and so we need to have the capacity to work with both.

Multiclassing as a concept came about due to the need for leaders to be prepared for every circumstance. It is not enough to just be great at leading in just one way, we cannot just be a great protector of the team if we wish for them to be empowered to take creative risks. Protection is a great ideal, but we cannot only be protectors. We have the tools at our disposal, great leadership is knowing what tool is necessary in the moment.

This isn’t a book of solutions to the unique problems we will experience throughout the course of our careers. It’s a book of the characteristics that enable us to solve problems.

The only certainty that we have is that nothing is certain. We must be open and prepared to experiment with style and process to best serve the unique circumstances of our team and the project that we are developing. Many leaders that I spoke with referred to leadership styles such as situational leadership or servant leadership, but heavily emphasised that these were just tools in their toolbox (Greenleaf, 1970; Blanchard, Zigarmi and Zigarmi, 2013). It is the fundamentals of these styles which we desire to achieve; changing in the moment, always in service of the people.

I was expecting a variety of styles and perspectives to arise out of my research and interviews on leadership. Instead, I discovered that many leaders were gravitating towards specific traits with very little outside influence. Experience and practice within the games industry by those leaders who reflect and work on improving their practice leads to similar solutions. Perhaps it’s just the nature of games development that the appropriate response to change and the unknown is to embrace adaptability.

Crunch

To have a foundational understanding of leadership and its role in the games industry, we must also understand crunch. However, it makes for a particularly challenging subject to discuss as it is so poorly defined. Even among the leaders I spoke with, many of them had differing feelings and definitions of what crunch was. Without a clear definition, it may be easy to say that crunch is just another misunderstood tool in our kit of tools. But crunch has a human cost involved in it, and we need to be clear on the reasons why crunch should not be an option we are willing to entertain as leaders.

Crunch has been a subject of discussion for the last decade, with coverage generally presenting it as excessive overtime. There were some leaders I interviewed whom responded as I expected with this simplistic definition; crunch (excessive overtime) is always bad, and we should never do it. But when pressed with examples of circumstances that other studios had experienced and had chosen to crunch, many leaders found it difficult to condemn their actions. If the choice was to keep the studio operating and ensure the ongoing employment of staff, and the only reasonable way to do so was an expectation of excessive overtime to get there, was that a trade worth making? A few leaders even saw value in the overtime, and the way it had bought the team together during a particularly difficult period.

The issue with defining crunch as simply being excessive overtime is that it does not capture the real issue. While discussing crunch with game developers, there are three recurring themes: overtime, overwork, and burnout. It’s not unusual in any job to have a degree of overtime expected of you in your role: that you will work additional time if necessary to remain on top of your tasks. Defining crunch as just being overtime - even excessive - makes it easier to excuse. Overwork by comparison is a symptom of poor leadership. An overworked team is one who has been given more work than is reasonably achievable in the time allocated to them. Overwork can lead to needing to do overtime, but working overtime does not necessarily mean we are overworked.

Burnout is a symptom, not a cause. It is a feeling that may arise out of crunch and any number of other negative circumstances in a studio. But unlike crunch, burnout is a particularly well-researched subject. The 2023 Game Developer’s Conference titled “Occupational Burnout in Games: Causes, Impact, and Solutions” (Boccamazzo et al., 2023) explores a model of occupational burnout proposed by Dr Christina Maslach, and contrasts it against the stories of game developers working in the industry (Maslach, 1998). Dr. Maslach’s model defines occupational burnout as the result of enduring overwhelming long-term stress, and identifies six contributing factors that lead to burnout:

If we define crunch simply as the excessive application of overtime caused by overwork, then workload is the clearest connection between burnout and crunch. However, it is clear from Dr Maslach’s identification of the factors leading to burnout that there are many other potential factors involved in crunch. Game developers are typically not paid overtime, meaning that those hours spent crunching go unrewarded. The expectation to crunch is one that is dictated by leadership, leading to a lack of individual control over how the tasks are completed. The leadership setting those same expectations to crunch may or may not participate or take ownership of the failure that led to crunch becoming necessary in the first place. If the place we workplaces value on people and work-life balance, then being expected to crunch is a betrayal of those values and of the studio culture.

It is possible then that the leaders that saw benefits in crunch were not actually crunching, they were working overtime. Dr Maslach’s model categorises burnout into three dimensions: exhaustion, ineffectiveness, and cynicism. All three of these dimensions must be true for a person to be experiencing burnout. We may feel exhausted after a long workout at the gym, but we aren’t ineffective or cynical. So a team working together to solve challenging problems and empowered to do so may not feel overwhelmed at the end of a long or challenging task. If we worked additional hours and feel good at the end of the tasks set before us, were we really crunching?

During my time at University, I worked with a friend on a project which we had drastically over scoped. I found myself asleep on the floor under my desk while he slept in his car. The following morning when the project was due to be presented, we found ourselves dishevelled but successful and proud of what we’d managed to achieve. That pride quickly turned to embarrassment as - unshaved and smelling like two-day old university student - students from the school of music came to discuss creating soundtracks for our games. We left unscathed, but it made me quickly realise the importance of scope and taking care of myself.

It was somewhat ironic then that I ended out working on projects with that same friend that would see us repeating this kind of behaviour. But now it was not because we had misunderstood the scope. Presented with extremely tight deadlines on projects that paid well, we had taken it as a challenge. Now instead of university desks, I found myself crashing on his futon after working well into the early hours on games.

Nothing about these memories is unpleasant to me. We were presented a challenge, we accepted the challenge, and it had a clear deliverable and deadline. We made the call to work late hours to get the projects delivered. There was a real sense of satisfaction and pride when we got to see people playing those games and hearing how pleased the business was with what we’d managed to achieve. We were working overtime, but we certainly did not feel that we were crunching.

Later experiences in my career would be far less positive. Working with a team well into the evening hours on projects that had been updated just moments before they were due to be submitted, only for them to break down and fail. We would stay back late, hammering away on the problem until we were ready to resubmit lest we miss our deadline. Just to hear back from our console partner days later that they had discovered multiple bugs with the build that would need to be fixed, and have the deadline pushed back. We would repeat these late nights over and over again for months as we worked to get the game finished within the limited budget and time that we had available to us.

I recall one morning where I woke up and broke down after the night before had caught up with me finally. Feeling a responsibility to the team, I still went into work.

In one case, we had made the decision to take on the challenge. We looked at the problem, measured ourselves as capable to the task, and we got it done. We delivered the project and the stress ended. In the other case it was a made necessary by leadership. At no point did anybody declare that we were crunching to get the task done, it simply felt like an expectation of us that nobody was willing to say no to. We were in it together as a team. Every time we went through that stress together, we quickly learned that any relief gained would be short-lived. There would be another push over the horizon, and we would be repeating the actions all over again. There was no satisfaction in delivering that project, just relief to be rid of it.

Looking at the examples of crunch in the industry, the uniting factor among all of them is not just the overtime: it is the human cost. This is a conversation that started back in the early 2000’s with the story of the EA Spouse, Erin Hoffman. Posted on Livejournal in 2004, Hoffman describes the circumstances surrounding the employment of her partner who was working at Electronic Arts at the time. It paints a picture of a dysfunctional studio with a workload set on a schedule that would never be achievable in a reasonable timeframe. Developers would be expected to perform gradually scaling levels of crunch that would eventually require staff in the office thirteen hours a day, seven days a week (Hoffman, 2004).

The story of the EA Spouse would thrust crunch into the limelight, but it would do little to change practice in the games industry. Fifteen years later, and history would repeat itself at another Electronic Arts owned studio. Bioware’s Anthem would release in February of 2019 to a poor public reception, criticised for shallow gameplay and technical shortcomings. Just two months later, Jason Schreier would publish an article providing insights from the developers working at Bioware as to just how things went wrong.

Schreier’s article details a studio in crisis, plagued by indecision and mismanagement. Anthem was in development for nearly seven years, a lengthy period of time even by AAA standards. However despite this lengthy development the game did not begin to take shape until the last eighteen months of development, as decisions got made and core concepts of Anthem’s gameplay and narrative were finally solidified. Finally clear on what they were making, staff were required to crunch. For many it was too much, with some of the studios most experienced developers leaving the company due to the oppressive working conditions. This was so prevalent that staff at Bioware referred to these lost coworkers as “stress casualties” - a term typically used to describe members of the armed forces who are unable to perform their duties due to exposure to operational stress (Schreier, 2019; APA Dictionary of Psychology, 2023).

There is this idea in art circles that great art comes from great pain, that art is unlikely to be good unless the artist suffered (Zara, 2012). Unfortunately, many industry leaders have seemingly adopted this same perspective. Under these leaders, crunch is treated like a workflow or process. They push to meet the deadline and requirements of the current milestone, and then they do it again and again until the project is finally completed. The people who remain at these sorts of studios tend to adopt a similar mindset of its necessity, or simply do not have anywhere else to go in order to support themselves or their families.

No piece of art is worth so much human suffering.

Crunch is self-replicating, doing crunch leads to more crunch. This is due to the fact that measurements taken of team output during crunch fail to be consistent. Our teams output the first time they crunch may be more or less than the next time they crunch. That period that you crunch for becomes unreliable data; the team, when pushed, can achieve this sort of output. But will they achieve that sort of output for long periods of time if we continue to push them? How much turnover and how many stress casualties are we going to suffer from along the way?

So what is crunch? It arises primarily from overwork due to poor scoping of projects. It may arise from overtime if it is long and excessive enough. And it is not unlikely to create burnout due to the lack of control a crunched team may feel. Leadership can identify and avoid many of the problems that lead to crunch: read enough stories out of the games industry about those studios that crunch, and it is either not unexpected by the team or just a choice made by leadership. Crunch is not a tool; it is a failure of leadership.

We may find ourselves in circumstances in which asking the team to work overtime may be an option or even necessary. Key to making such a choice is the need for leadership to maintain control. It must be temporary, brief, and followed by an opportunity to recover. This isn’t condoning or calling for overtime to become essential, but a reality of leadership and of making games.

If the room is on fire around us, the time to calmly escort the team out has passed. We are now in an emergency, and that requires acting with urgency and decisiveness. This is the time that we reach for the fire axe and direct our team with appropriate energy. We bark orders and push them to do whatever is necessary to get us all out of the building alive. As we stand outside and everybody catches their breath, the team will be understandably shaken by the experience. This is our time to step in and ensure their wellbeing, and to take care of them. We give them the time necessary to tend to their physical and psychological wellbeing.

Overtime is our fire axe. It is survival. It is urgent, rushed, and the focus is on getting out of the building. If we find ourselves here, then quality is no longer our priority. We are not in a place where we can criticise the form of the person swinging the fire axe. When we find ourselves in an emergency, we don’t blame our leaders for needing to put pressure on us to get out quickly. We blame our leaders for missing the signs that our building was a fire risk.

The fire axe is an emergency tool. When we reach for it, we must be doing so on the understanding that we are going to be damaging something. We are breaking the glass, we are hacking down doors, and people might get hurt. It is essential that we have tools at our disposal to handle emergencies, but this is never a tool we want to rely upon to get work done over long periods of time. We should rightfully feel bad if we need to ask the team to work overtime, but sometimes it is better than the alternative. The best we can do in some circumstances is learn from the experience and work to prevent it from happening again.

Leaders are not perfect. We cannot predict every issue we will need to face. But crunch does not come out of a singular mistake, it comes out of a long-term failure of leadership to identify or act upon issues within a project. It is our responsibility to watch for the signs and do whatever we can to ensure that our teams never need to endure such working conditions.