Is bad leadership silently sabotaging your game development? It's a harsh question, but one that needs to be asked. We've all heard stories of projects bogged down by endless delays, miscommunication, and wasted effort. While shiny new technologies like generative AI promise to revolutionize game creation, the truth is, even the most advanced tools can't compensate for a leader who doesn't understand the realities of game development or actively undermines their team.
Back in September, we published an article exploring the reasons behind increasingly lengthy game development cycles. We asked developers for their insights, but after the article was published, we were inundated with messages asking, "Why didn't you talk about bad leadership?"
Our apologies, dear readers. The omission wasn't intentional; during the initial interviews, nobody explicitly brought it up. But after another round of conversations with industry veterans, a clearer, and frankly, more troubling picture emerged. Six developers shared their experiences – some requesting anonymity to speak candidly without fear of professional repercussions – and revealed a pattern of leadership behaviors that consistently slowed down, and sometimes outright doomed, high-profile projects.
Their stories highlight a critical truth: technology alone can't solve fundamental leadership problems. Think of it like this: you can build the world's fastest racecar, but if the team owner keeps swapping out mechanics, engineers, and drivers haphazardly, the car will never reach its full potential. It'll just blend into the crowd.
So, what are these detrimental leadership traits? We've identified seven key areas where poor leaders consistently derail game development. To help you assess whether any of these issues are present on your team, we're providing a concise breakdown:
Failing to Understand the Realities of Game Development: This manifests in several ways:
- Approving Content and Then Throwing It Out: Leaders greenlighting assets or features, only to scrap them later after realizing they don't fit the overall vision or are simply bored with them. One game designer called it "circular iteration," where the final product closely resembles earlier, rejected versions.
- Asking for Features with No Understanding or Direction on Implementation: Demanding features without considering the technical challenges or providing any guidance on how to bring them to life. This often leads to wasted effort and frustration.
- Needing to See Expensive, Polished Material Early in Development to Make Decisions: Requiring fully rendered assets or playable demos before making crucial decisions, even though these elements are subject to change during the iterative process. As producer Masao Kobayashi noted, this leads to developers creating "fancy concept art and highly-polished, super early demos" that are ultimately discarded.
- Poor Project Management Skills: Setting unrealistic timelines, failing to account for dependencies between departments, and generally lacking the organizational skills needed to keep the project on track. This can leave some teams idle while others are hopelessly overloaded.
Failure to Trust Employees: Trust is paramount in any collaborative endeavor, and game development is no exception. But here's where it gets controversial...
- Requiring Sign-Off from Too Many Leads: Implementing approval processes that involve multiple layers of management, even from departments with limited expertise in the area being reviewed. This can lead to bottlenecks and delays as decisions get bogged down in bureaucracy. One writer described a project where every department needed sign-off on every piece of work.
- Ignoring When Workers Say a Task Can or Can't Be Done: Disregarding the expertise of developers who raise concerns about the feasibility or timeline of a task. A prime example is ignoring warnings from quality assurance (QA) team members about critical bugs.
- Laying Off or Retaliating Against Colleagues Who Speak Up: Punishing employees for voicing concerns or offering constructive criticism, creating a culture of fear and silence.
- Disregarding Warnings from Quality Assurance Team Members About Bugs That Could Have Dramatic Consequences Down the Line: Community manager and QA specialist Rose Whitcomb recalled a project where bugs related to less popular characters were deprioritized, leading to major issues after the game's launch when those characters became more popular.
Treating Developers as Interchangeable: Assuming that anyone can easily step into any role, regardless of their experience or expertise. And this is the part most people miss...
- Expecting Developers to Be Experts in Genres They Haven't Worked In Before: Assigning developers to projects that fall outside their area of expertise, without providing adequate training or support. For instance, expecting developers with experience in family-friendly platformers to seamlessly transition to creating a MOBA like League of Legends.
- Not Recognizing That Developers Who Leave the Studio Take Key Institutional Knowledge with Them: Failing to acknowledge the value of experienced developers and the knowledge they possess, leading to significant setbacks when they leave the company. As Kobayashi pointed out, increased reliance on external co-dev partners can exacerbate this issue.
- Assuming Other Workers Can Easily Replace Those Who Move On: A dangerous assumption that fails to recognize the unique skills and experience that each developer brings to the table.
Slow Decision-Making: Procrastination and indecisiveness can cripple a project.
- Once Again, Requiring Approval from Too Many Leads: As above, this leads to delays and frustration.
- Leads Hyper-Focusing on Specific Development Points and Not Offering Direction on Features That Affect Multiple Teams: Getting bogged down in minor details while neglecting to provide clear guidance on larger, more impactful features.
- Not Making Decisions for Weeks or Months for Unfathomable Reasons: A complete inability to make timely decisions, leaving teams in limbo and wasting valuable development time. One developer recounted a department lead who took months to make a decision, even when presented with equally viable options.
Providing Little-to-No Feedback When Critiquing Work in Reviews: Offering vague or unhelpful feedback that leaves developers unsure of how to improve their work. This can range from publishers rejecting milestone builds with little explanation to team leads simply saying, "Make it cooler."
Demanding Sudden Changes in Direction or New Features: Implementing drastic changes based on fleeting trends or personal preferences, often inspired by other games or media. This is often referred to as the "Dark Souls phenomenon," where creative leads play a popular game over the weekend and return with demands for new features inspired by that title.
Vague Crunch Policies Caused by Refusing to Acknowledge Changing Timelines: Creating a culture of overwork and burnout through unrealistic deadlines and inconsistent policies. This can manifest as promising that the team "does not crunch" while setting deadlines that necessitate overtime or capping hourly workers' hours, driving them to work unpaid.
Developers shared an anecdote about a designer who described feedback from a lead as "Get me a rock. No not that one, a better rock." This went on until a "string lock" forced them to ship the latest iteration, regardless of quality.
Sol Brennan, a 3D rigger, observed experienced leads skipping the "grey-boxing" stage of level design, opting instead to dive directly into art production. This ultimately led to a substantial amount of rework when necessary design changes were implemented.
All of these behaviors, generally observed among project and studio leadership and sometimes among team leads, can dramatically and unnecessarily slow down game development.
So, what's the solution? There's no easy answer, but it starts with recognizing the problem. As writer Robert Caro famously said, "Power reveals." It doesn't necessarily corrupt, but it exposes the true nature of a leader's character and abilities.
While structural reforms are essential, poor leaders can sometimes slip through the cracks, maintaining their positions through personal connections and influence. AI can't fix this. To truly speed up game development, we need to prioritize listening to the people who actually make games and empower them to challenge ineffective leadership.
Now, it's your turn. Have you experienced any of these leadership pitfalls in your own game development career? Do you agree that bad leadership is a major factor in project delays? Or do you think technology can ultimately overcome these challenges? Share your thoughts and experiences in the comments below!
