In September, we ran a story asking developers about the real reasons game development cycles have grown longer and longer over the last decade. After publication we heard from a surprising number of readers who asked us “why doesn't your story say anything about bad leadership?”
Mea culpa, dear readers. I couldn't include that topic because…well…no one I interviewed really brought it up.
It's also difficult to define “bad leadership.” Bad habits at one studio may be healthy in another. That's one lesson we learned speaking to another round of developers in the last month, asking them how they've seen poor leadership slow down development timelines. The six industry veterans we spoke with described a number of nightmare scenarios that dragged out and sometimes doomed the development of high-profile games (some requested anonymity to speak freely about their experiences without fear of retaliation).
Their experiences show why claims that generative AI—or any piece of technology—will speed up game development are missing the point. You can build the fastest racecar in the world but if the team owner keeps shuffling mechanics, engineers, and drivers around, there's no way it will stand out from the pack.
There are seven key traits of poor leaders that slow down game development
This is a longer piece, so we're going to take an unusual step here and outline the behaviors we identified in multiple conversations with developers. We hope it's a quick guide to identify if any of this behavior is taking place on your team.
We've grouped these into seven high-level traits and are quickly spotlighting examples of how these traits might show up in the workplace.
-
Failing to understand realities of game development
-
Approving content and then throwing it out
-
Asking for features with no understanding or direction of how to implement them
-
Needing to see expensive polished material early in development to make decisions
-
Poor project management skills, issuing unrealistic timelines and not accounting for departmental dependencies
-
-
Failure to trust employees
-
Requiring signoff from too many leads
-
Ignoring when workers say a task can or can't be done
-
Laying off or retaliating against colleagues who speak up
-
Disregarding warnings from quality assurance team members about bugs that could have dramatic consequences down the line
-
-
Treating developers as interchangeable
-
Expecting developers to be experts in genres they haven't worked in before
-
Not recognizing that developers who leave the studio take key institutional knowledge with them
-
Assuming other workers can easily replace those who move on
-
-
Slow decision-making
-
Once again, requiring approval from too many leads
-
Leads hyper-focusing on specific development points and not offering direction on features that affect multiple teams
-
Not making decisions for weeks or months for unfathomable reasons
-
-
Providing little-to-no feedback when critiquing work in reviews
-
Publishers rejecting milestone builds with little explanation
-
Team leads criticizing work with little more direction than “make it cooler”
-
-
Demanding sudden changes in direction or new features
-
The classic “our creative director played X game over the weekend” anecdote
-
-
Vague crunch policies caused by refusing to acknowledge changing timelines
-
Promising that the team “does not crunch,” but setting deadlines that require overtime
-
Setting company policies that place a hard cap on hourly workers' work time—driving them to do unpaid work in off hours
-
All of these behaviors (generally witnessed among those in project and studio leadership, but some anecdotes described team leads guilty of them as well) can dramatically and unnecessarily slow down how games are made.
Failing to understand the realities of game development
Developers we spoke with described different scenarios where key decision makers did not understand the nitty-gritty details of making games. 3D rigger Sol Brennan said they've witnessed experienced leads decide to skip the “grey-boxing” step of level design and dive straight into art production, not recognizing how much of that work would need to be redone whenever a necessary change came to the level design.
Meanwhile, an anonymous game designer said they worked under project leads with outdated expectations of the development process and leads with zero experience at all. This designer described how at multiple studios, project leads would approve content to go in production, then throw it out after review, sometimes just because they'd become bored with playing it over and over again.
They called it “circular iteration,” as often the final content would be so similar to discarded earlier versions. These leads were also the most likely to be irritated when encountering bugs in a build, seeming to forget they would be hopefully removed in the final version.
They sometimes demanded extra work because they couldn't picture what their colleagues were pitching them. “Frequently, management staff don't come from dev backgrounds and won't be able to understand what they see unless it looks like a final game,” explained producer Masao Kobayashi. To appease these leaders, developers produce what he called “fancy concept art and highly-polished, super early demos.”
“Usually all of this is fake and is thrown out as soon as it is made,” he said. As we noted last time, ever-improving graphical fidelity standards have made this a more lengthy process—and time spent on that wasted content is time not spent on making the final game.
Kobayashi also said that across the multiple games he's shipped, leaders often have poor understanding of project timelines and departmental dependencies—the kind that can leave some teams spinning their tires while others are overwhelmed by poorly-scoped tasks.
Failure to trust employees
An anonymous game writer we spoke with said that across their work in triple-A games, double-A games, and indie games, it was leadership on triple-A games that seemed to actively distrust their employees. They described one big-budget project where every department needed sign-off on their work not just from department leads, but leads from departments who had little-to-no experience on the work they were reviewing.
Whenever these leads couldn't come to a consensus, it led to weeks of work hanging in limbo, as these individuals were (justifiably) busy and difficult to get in the same room at the same time.
“This to me was a lack of trust in the people who worked for them,” they said.
The industry's dismissive attitude towards quality assurance as a discipline can also lead to leaders ignoring colleagues who are the first to ring the alarm bell. Community manager and QA specialist Rose Whitcomb recalled a project where developers deprioritized bugs centered around less popular selectable characters. “The dev played into community favorites and would prioritize those while directing QA to focus on them despite the piling issues for the others,” she said. Some of these bugs triggered hard crashes when underplayed characters were paired together.
Then the game launched—after those under-loved characters had been improved and were more likely to be selected for missions. The team lost precious time hotfixing an issue that could have been cleared up months before.
Treating developers as interchangeable
Time and again, Kobayashi and the other employees we spoke with watched their employers greenlight games or shift direction solely on the basis of what was commercially successful in the last quarter. Setting aside the fact these games weren't as safe a bet as companies believed, they also were dangerous projects because studio leads didn't understand their employees may have little-to-no experience in the new genre they were chasing.
For example, developers used to family-friendly platformers can't quickly pivot to making a League of Legends-like MOBA. MOBA developers may struggle to understand third-person “hero shooters,” even if there's design overlap. And developers experienced with hero shooters may struggle when working on family-friendly platformers.
Studio leads might also dig their heels in when it comes to refusing pay or promoting key employees, observed Brennan. That refusal would come back to haunt the team when said employees when searching for better-paying jobs.
That interchangeability gets worse when you consider what happens when developers leave the studio—either as a result of being laid off or because they received a better offer at a competitor. This phenomenon is only growing more frequent as studios rely on external development studios like Keywords or Virtuos, said Kobayashi. “With the massive layoffs and increased reliance on external co-dev partners, these previously-solved problems became novel problems that cost more and take more time to solve,” he said.
The failure of slow decision-making
Another anonymous developer recalled their experience making games in the 2000s where for unexplained reasons, their department lead was incapable of making decisions. “He was confoundingly incapable of making decisions,” this developer recalled. If the team presented this lead with three options—all equally executable—it would sometimes take them months to make a final call.
What was this unnamed team lead doing while his team waited in frustration? Apparently obsessing over minor details of the game's story.
This trait can be another consequence of top-heavy approvals process like the kind discussed by the anonymous game writer. Even if individual leads can make decisions on a feature, the requirement for consensus bogs down the project. Whether it's one person or a committee—the refusal to make a decision can have massive downstream effects on development.
Providing useless or unclear feedback
Developers we spoke with said one of the most frustrating moments they encountered was when their leads criticized their work, but offered vague guidance on how to improve it. The anonymous level designer recalled their coworker summarizing the vacuous feedback they both received from their lead.
“Another designer described it as ‘get me a rock. No not that one, a better rock,'” this person said. “They would just do that until string lock forced us to ship whatever was the last iteration.”
Readers interested in a clear case study of this phenomenon should revisit Double Fine and Two Player Productions' documentary on the making of Psychonauts 2. It highlights how unclear feedback from studio founder Tim Schafer and then-project lead Zak McClendon frustrated employees and left some designers working on R&D while the game was working towards an Alpha build.
Demanding sudden changes due to playing other games/watching shows
Over a decade after FromSoftware and Bandai Namco released Dark Souls in 2011, game designers still joke about what might be called the “Dark Souls phenomenon,” where creative leads in game development head home for the weekend, play a (deservedly) popular game like Dark Souls, Bloodborne, or Elden Ring, and return to the office with sudden directives for new features inspired by these titles.
The anonymous writer pointed out that these changes sometimes happen after the game director watches a hotly-talked-about movie or TV show as well. Sudden narrative changes can have a drastic downhill effect on all departments if they happen too late in the process.
The willingness to make these pivots can be compounded by the lack of trust for employees and a lack of understanding for the cost of implementing these changes. The developers we spoke with said that the best leaders they had listened to workers when they explained a requested feature wasn't possible or might take too much time. They didn't always cancel the feature, but they would either give direction on how to implement it, or adjust their demands based on the team's capabilities.
Vague crunch policies
“Crunch is a consequence of poor planning,” goes the industry refrain. Poor planning can strike in all manner of ways, not just as a consequence of bad leadership. But when crunch hits, how leaders manage the need for overtime can bring a team together or grind them into the ground.
Some crunch failures might come down to poor team culture, while others can be about company policy. On the team culture level, the developers we spoke with described how “no-crunch” policies began driving conflict between developers when some workers would be vigilant about their work hours while others pushed into overtime. Not only did they see some colleagues express resentment for their decision to leave on time, they felt pressure from leadership to crunch anyway despite stated policy.
Companies that employ hourly workers can create a codified version of this by capping out the number of workable hours. If team leads set unrealistic goals, but employees can only put so many hours on the clock, it's inevitable they'll start doing unpaid work in their time off. Then the game they worked on might go to make millions of dollars while they don't see a penny for the extra time spent.
When is bad leadership a structural problem? When is it an individual one?
A quote from writer Robert Caro rang through my head as I listened to these different stories: “Power reveals.” It's a more complex phrase than “power corrupts,” which implies anyone in leadership will inevitably become harmful and self-serving. “Power reveals” asks us to define not only a leader's actions, but the nature of the authority they possess.
There is no one way to speed up game development. And there is no one way to improve leadership across the video game industry. Sometimes educating how much power a small group of individuals can have over the project will clear mid-development blockers. In other occasions, leaders who plan early and stick to decisions made early in the process, changing course only when needed, can turn studios into game-making powerhouses. Change what “power” means in game development, and you can change what it “reveals” about those who hold it.
But there are those in leadership who, when given power, will always reveal themselves to be unworthy of it. They might verbally abuse colleagues, lock key team members out of meetings, or pit workers against each other. At the very worst, they might join the ranks of those accused of harassing or discriminating against developers, only keeping their position until some exposé shines a light on their deeds.
This is the contradiction at the heart of the game industry's leadership struggles. Structural reform is necessary. But poor leaders sometimes sneak through any attempts at positive change, keeping power thanks to close relationships with people up the food chain.
AI can't fix any of this. If you want to speed up game development, you need to do the one thing bad leaders refuse to: listen to the people who actually make games.
