A dev's guide to ensuring studio conflict is healthy and productive

Most game developers work with others and that means that, at some point, there’s going to be some conflict. Sometimes it’s good, and sometimes it can be toxic!

At GDC today, Finji CEO and cofounder Rebekah Saltsman shared some advice on cultivating the former and avoiding the latter, based on her own experience shipping multiple games at Finji alongside her husband (and Finji cofounder) Adam Saltsman.

“Adam and I get asked regularly how we can possibly stand to work together day in and day out, since we’re married and run an indie studio,” said Saltsman, skipping past the basics of maintaining harmonious working relationships  (“I’m straight up gonna assume that you’ve been to preschool") to zero in on something she says they've noticed in multiple development teams: a basic failure to effectively communicate about changes to a project.

This seems intentionally broad: we're talking here about anything from changing how much screen space an inventory screen takes up to rewriting the ending of the game. 

Whatever it is that you want to talk to your team about, Saltsman first recommends phrasing it as a pitch, rather than a complaint or a notification that you've identified a problem (for someone else to deal with.)

Keep your ego out of it, and communicate in clear, concrete specifics

Instead, Saltsman recommends you keep ego and personal feelings out of your pitches by identifying a problem (“this thing we already built totally sucks!”) you think the team needs to address -- and you need to be specific.

Next, you (the person who identified the problem) has to formulate a solution, not ask someone else to fix it. It may be that the solution you come up with isn't ultimately the best one, but you putting in that initial effort demonstrates solidarity with the team and helps your colleagues better understand what the game could be if the problem you're identifying was solved.

“We hack together test levels, we build prototypes to test mechanics,” says Saltsman. “It’s a requirement for our teams that if you believe in your idea, you also need to do the initial legwork so the team understands where you’re coming from.”

After you've identified a problem and formulated a possible solution, you need to present your idea to the team. Ideally, says Saltsman, you can explain both the upsides (this thing that sucks will be better!) and the downsides (we have to spend an extra week working on it.)  

If this all seems a little rote, understand that Saltsman cautions fellow developers not to treat this like a rigid process -- it’s okay to walk through the steps informally and in your own cadence, in a way that fits well with the way your team works. The bigger point, she says, is to have a structure in place for communicating with your coworkers about your project so that you don't get bogged down or lose sight of the concrete changes and challenges.

“These aren’t formal things we go through,” said Saltsman, noting that Finji is made up of people and not robots. “These are guidelines that inform the way that we work together.”

To stay in the zone of “good” conflict rather than toxic conflict as you're working through this process with your own team, Saltsman suggests you get everyone engaged by pointing out how the problem you’ve identified hurts the team’s shared goals -- and how your pitch is in line with the team’s objectives.

If that sounds a little vague, here's a concrete example Saltsman shared: in Finji’s upcoming game Overland, at one point the team had tiny on-screen character icons that Saltsman says “weren’t selling it” and were cluttering up the screen without making it easy for players to build empathy with their characters.

So at one point during development, “we proposed a group photo with the current player highlighted,” said Saltsman. “We talked through the pros -- showing 'group-ness' and group togetherness -- and the cons, which was….seriously a lot of extra work.”

Saltsman said it took a while because they had to basically build the feature from scratch, but that in the end it made the game better and advanced the team’s shared goals for the game (care for the characters you’re guiding) without a terrible amount of conflict or wasted effort.

In another example, Saltsman pointed to a cast of characters that were present in early builds of Overland. They worked fine and they were finished early, so the team didn’t stress about them -- until team artist Heather Penn came forward with a suggestion for how the game could be significantly improved by changing the character models, and presented mocked-up examples.

“These [models] were super, super important,” Saltsman says, because “Heather was like, we’re gonna fix something that’s not broken.”

In the end, Saltsman says it worked out well, but the implication is that if Penn had not outlined the problem using specifics, then mocked up some better models to show what was possible, the work might not have been done and the game might still have those old inferior models.

If you hit an impasse, either hold off or mock up a 'garbage solution' and circle back

Okay so this is all good and well, but what if you propose something and the team can’t agree? Like, past the point where the conversation becomes contentious and uncomfortable?

“That’s a really awful place to be,” says Saltsman. The path out, she says, requires stepping away and circling back on the problem at a later date -- and she has two suggestions for devs looking to do that effectively.

The first way is to just hold off on making a decision until the team has more information. “We don’t have enough information to come to a consensus, so we can just postpone it and circle back” is a viable tactic, says Saltsman.

The other option is what she calls “intermediate impossibles.” Basically, if you can’t postpone your decision and you can’t reach a consensus, you “hack together whatever garbage solution is easiest to do to make sure you can go from point A to point B.”

Saltsman's 5 steps for healthier conflicts

It doesn’t matter what that bridge you build looks like, says Saltsman, because you just need to get across the gap -- you can always come back later and fix or rebuild the bridge when you know more about the game you’re making.

As an example, Saltsman points to the introduction of enemies into Overland. At first the team knew they needed monsters that came into the playfield from off the map, but spent well over a year figuring out what the monsters should actually be. When the time came to put monsters in the game for demo purposes, they relied on “intermediate impossible” monsters (i.e. weird pointy black placeholder beasties) to get the demos to a playable state.

Another example of such an "intermediate impossible" is the game's ending -- there isn't one.

“We all have different ideas about Overland's ending, and zero consensus on it," says Saltsman. "There's no obvious right answer right now, given what we know about the game. But even at this point, three years into development, the ending of the game is not fully fleshed out at all. So, yeah...it will be a surprise to us too.”

If all else fails, trust your experts and lean on your mentors

So what if none of this works? What do you do?

“You need to lean on your leads,” says Saltsman. “This means you need to learn to trust your leads to make calls -- so long as you’re within budget.”

If you have leads -- if you have an art director, or a biz dev person, or someone who's main job is to oversee the audio on your game -- Saltsman says you need to trust their expertise, even if it conflicts with your own ideas and you have significant experience of your own in making games.

The important thing, says Saltsman, is that you trust but verify that your leads are actually right (presumably by acquiescing to their guidance but testing their proposed solution) and that you place trust in expertise, not hierarchy. Put more simply, if you’re at an impasse about something that’s related to the game’s artistic direction, trust your art director because they’re the person most focused and invested in the art direction, not because they have a weightier job title or more experience than you.

Saltsman also encourages devs who work within teams to have mentors outside the team that are willing to provide advice and outside perspective on a project. If a conflict within your team has reached an impasse and it's going from "good" to "toxic", talking about the problem with someone outside the team (or even just showing them the game) can often provide valuable perspective.

Lastly, Saltsman closed out her talk the way she opened it -- with a concrete list of five things you can do to ensure all the conflicts you run into in the course of making a game are healthy and not terrible: