Stephen Brenish
Three months into production on a mid-sized RPG, two of my best people stopped talking directly to each other. The art director wanted painterly, impressionistic environments. The lead level designer wanted readable silhouettes and clear gameplay sightlines. Both were right. Neither would budge. And every week that went by without resolution was a week of work getting built in two incompatible directions.
That’s the version of creative conflict nobody warns you about. Not the dramatic blowup in a review meeting, but the slow, grinding misalignment that quietly doubles your rework budget while everyone stays professionally polite on Slack.
I’ve been managing creative teams for 14 years across AAA and indie, and I’ll tell you honestly: creative conflict handled well is one of the most productive forces in game development. The same conflict handled badly will kill your project. The difference is almost never about talent. It’s about process.
- Unresolved creative conflict is a leading cause of late-stage rework; address it at the direction level, not the task level.
- Document design decisions with explicit rationale, not just outcomes, so conflicts revisit principles instead of personalities.
- "Who decides?" should be answered before a conflict starts, not during it.
- Team trust is built during low-stakes disagreements; wait for a crisis and you've waited too long.
- The goal isn't consensus. It's a clear decision with understood reasoning that the team can execute together.
The Thing That Makes Creative Conflict Different
In most industries, a conflict is about facts or resources. You either have enough budget or you don’t. The delivery date is right or wrong. Game development is different because so much of what teams fight over is genuinely, legitimately subjective. Is this combat feel “punchy enough”? Is this UI “clean” or “sterile”? Two highly skilled, deeply experienced people can look at the same prototype and reach opposite conclusions in complete good faith.
What most people don’t realize is that this subjectivity doesn’t make the conflict harder to resolve. It actually makes it easier, once you shift the frame. The question isn’t “who’s right?” It’s “what are we actually optimizing for, and does our current direction serve that goal?” That reframe does more work than any personality-management technique I’ve ever seen.
The mistake I made early in my career was trying to mediate these conflicts by finding the middle ground. Split the difference. Blend the two visions. I thought compromise was the mature answer. It usually isn’t. A blended vision in games often produces something that satisfies neither goal and confuses the player. The art director and the level designer above didn’t need a 50/50 solution. They needed a hierarchy: in this game, at this moment, which goal comes first?
Building the Decision Architecture Before You Need It
Here’s the thing about conflict: it’s always easier to establish rules when nobody’s fighting yet. I now do this deliberately on every project I run, usually during pre-production, before anyone has strong attachment to specific decisions.
The practical tool I use is a one-page document I call a “Decision Map.” It’s not fancy. For each major discipline (art, design, audio, narrative), we write down three things: who has final say on direction decisions, who gets a required consult before that call is made, and what happens when two disciplines genuinely conflict at the direction level. That last one is the important one. Knowing “design leads on gameplay clarity disputes, art leads on visual tone disputes, and the creative director breaks ties” sounds obvious until you’re in the middle of a heated review and nobody wants to be seen as escalating.
This isn’t a bureaucratic exercise. It takes about 90 minutes to run with a core team, and in my experience it prevents three to five significant production slowdowns per project. The specific numbers are hard to measure, but I tracked rework hours on two comparable projects at one studio, one with a Decision Map and one without, and the one without it logged roughly 40% more design-revision hours in months four through seven of production.
A reader emailed me last year after running this exercise for the first time on a small mobile game. She said the most useful part wasn’t the document itself. It was that her team had a two-hour conversation about values they’d never explicitly had before, and two people who had been subtly clashing for months realized they actually agreed on the core goal. The conflict dissolved before it needed resolving.
What to Actually Do When It’s Already Happening
Jobs in Game Development [Team Management] · Masahiro Sakurai on Creating Games on YouTube
So the conflict is live. Two people, or two disciplines, are genuinely stuck. Here’s the process I use, in order:
First, get both parties to write down their position independently before any group discussion. This sounds small. It isn’t. When people articulate their stance in writing first, they almost always discover their actual concern, which is often different from the position they’ve been arguing. The art director above, when asked to write it out, said what she actually cared about was “not looking like every other fantasy RPG.” The level designer wrote that his concern was “players skipping content because they can’t figure out where to go.” Those are two completely compatible goals. They’d been arguing about solutions before either of them had named the actual problem.
Second, hold what I call a “constraint review.” Before debating options, both parties list every hard constraint they’re working inside: technical limits, schedule, the game’s stated pillars, platform requirements. In my experience, about a third of creative conflicts dissolve entirely when both parties see each other’s actual constraints. It turns out people frequently argue against a position that, if they knew the full context, they’d support.
Third, if the conflict is still live after those two steps, it goes to whoever holds decision authority in your Decision Map. Not for a vote. Not for mediation. For a decision. And the person making that call should explain their reasoning out loud to both parties, not just announce the outcome.
The explanation is the part people skip. It matters enormously. “We’re going with the higher-contrast silhouettes because player testing in the March build showed 23% of players were missing the side path in the forest area” lands completely differently than “we’re going with design’s version.” One gives the art director something to actually respond to. The other just makes them feel overruled.
When the Conflict Is Actually About Something Else
I’d be doing you a disservice if I only talked about principled disagreements between reasonable people. Some creative conflicts are not really about creative direction at all.
I’ve seen “we disagree on the art style” mask “I don’t feel like my input matters on this team.” I’ve seen “the narrative doesn’t support the mechanics” really mean “I’m burned out and angry and this is the thing I’m able to say out loud.” I’ve seen genuine scope anxiety come out as aesthetic nitpicking because aesthetic nitpicking feels safer to raise in a review.
These are not management failures, exactly. They’re human. But you do need to be able to recognize them, because no amount of Decision Maps will fix them. If a conflict keeps re-emerging in different forms after you’ve apparently resolved it, that’s usually the signal. The issue is not the issue.
The short answer: one-on-ones. Not formal performance conversations, just regular, low-pressure check-ins where the only agenda is “how are you actually doing.” I run these weekly with direct reports and monthly with leads whose work I oversee. The number of times a “creative conflict” has quietly dissolved because someone finally had space to say “honestly, I’m exhausted and I don’t think we have enough time to do this right” is more than I can count.
How Creative Conflict Looks Across Team Sizes
One thing I want to acknowledge: the dynamics here shift a lot depending on your team size and structure. What works for a 60-person studio doesn’t necessarily apply to a five-person indie team, and vice versa.
| Team Size | Common Conflict Pattern | Recommended Approach | Watch Out For |
|---|---|---|---|
| 2-5 people | Everyone has opinions on everything; roles blur | Explicit “decision owner” per discipline, even if one person wears multiple hats | Founder dynamics where one voice always wins by default |
| 6-15 people | Discipline leads form; inter-discipline tension emerges | Decision Map + documented pillars; weekly cross-discipline sync | “Polite avoidance” masking real disagreement |
| 16-40 people | Political dynamics appear; information silos form | Formal escalation path; conflict resolution framed as process, not personal | People managing upward instead of resolving at the right level |
| 40+ people | Creative drift across teams; “telephone game” vision dilution | Strong creative direction documentation; regular direction reviews; explicit “who breaks ties” at every level | Conflict going underground rather than surfacing |
As of July 2026, most indie teams I work with or talk to are sitting in that 6-15 range, where the shift from “we all just talk” to “we need actual process” is happening and often catching people off guard. That transition is genuinely hard. The team that shipped fine as four friends making a game together sometimes fractures when it becomes eight near-strangers under deadline pressure.
Three Real Scenarios
Scenario 1: A narrative lead and a systems designer disagreed for six weeks on whether a particular mechanic “fit the tone of the game.” Neither could define what they meant. Producer asked both to write a one-paragraph description of the game’s tone independently. Their descriptions were almost identical. The mechanic was adjusted in a single afternoon meeting. Total resolution time after applying the written-articulation step: four hours.
Scenario 2: At a studio I consulted for in 2024, a creative director was making every direction call personally, which he saw as protecting the vision. What it actually did was create a bottleneck and, more damaging, a team that stopped surfacing disagreements at all because they knew it would just get overridden. When he redistributed decision authority to discipline leads with clear charters, production velocity improved and, more importantly, his team started bringing him problems earlier. The creative quality of the game improved because more people felt safe dissenting.
Scenario 3: Two leads on a co-op shooter had a months-long conflict about camera behavior in tight spaces. Looked like an aesthetic disagreement. Was actually a resourcing conflict: one lead didn’t have enough engineering time to implement his preferred solution and was arguing against the other option as a way of not admitting the constraint. Once that came out in a one-on-one, the producer reallocated two weeks of eng time, the conflict ended, and the implemented solution was actually a third option both leads preferred anyway.
Sources
- Lencioni, Patrick. The Five Dysfunctions of a Team (2002): Widely used framework in game dev leadership programs; particularly relevant chapters on conflict avoidance and trust.
- Fullerton, Tracy. Game Design Workshop, 4th edition (2018): Contains practical material on collaborative iteration and feedback culture in game teams.
- International Game Developers Association (IGDA) Developer Satisfaction Survey (current as of 2025 release): Annual data on team culture, burnout, and communication breakdowns across studio sizes; igda.org.
- Kim, W. Chan and Mauborgne, Renée. “Fair Process: Managing in the Knowledge Economy,” Harvard Business Review (1997): Research on why explaining decisions matters as much as making them, directly applicable to creative team management.
- Valve Corporation. Handbook for New Employees (2012): Unusual primary source, but the section on “how decisions actually get made” in flat structures is a useful contrast case for understanding where implicit hierarchies create conflict.
Photo: cottonbro studio via Pexels
