Managing Conflict on Small Teams

[Music] okay uh my name is Becca Saltzman and I'm the CEO and co-founder of Fini with Adam Saltzman who is also my husband so no we're not brother and sister thank you people who think we look alike I appreciate that uh I'm going to talk today about how we maintain good conflict and avoid toxicity in everyday decision-making at Fini um with both of our internal uh development projects and our partner publishing projects so give me a second let me actually start my timer because I forgot to okay so who am I um I'm just going to go through some stuff that we've done stuff that we're working on so then you have a little bit of context um because sometimes especially me I'm completely invisible generally with Fini um so we've worked on a lot of projects over the years um some of our previous titles um at Fini and our previous iPhone company um include cannibal which is sort of like the first endless Runner um gravity hook hundreds en capsule which is like seriously Niche horror um we've

also done a lot of weird TurnKey work in advertising and the Ed uh Education and Research space um so with Old Spice Hunger Games stuff like that um we're currently building uh Overland um with a small distributed Team all over the United States um and after three years of development we published Night in the Woods uh last week so I know uh sorry if you didn't play it apologies uh Adam hasn't played it either long story with that I have played it though 10 times or more okay the problem okay Adam and I get ask regularly um how we can possibly stand to work together day in and and day out since we're married and we run an indie uh development Studio which we've been doing for like a decade because we're straight up old way older than most people think I am uh and this talk is not going to cover ways to be a nice person um or words to use to not be a jerk um I'm not I'm uh straight up going to assume that

you've been to preschool um but I am going to tell you about a problem uh We've noticed with our development teams over the years and our friends development teams we've seen the wrong kinds of tension and conflict produce catastrophic outcomes we've seen canceled games wrecked friendships sleepless nights wasted life savings and uh Adam and I have actually experienced all of these things over the last decade um and we've uh over the last couple years have found ways to collaborate uh but lower the risk of disastrous results So based on our experiences of the last two or three years especially um there are some solutions that we proposed that can help avoid some of the most toxic uh Team conflicts that we've encountered so one use a planning and design process that emphasizes problems and solutions and downplays ego two maintain flat and concrete discussions as of plans um I'm sorry maintain flat and concrete discussions of plans and design merits

three learn how to postpone contentious decisions as long as they're not bottlenecks to current development four trust but verify your experts within each discipline and five always engage external mentors especially for long-term planning now you're thinking whoa that sounds awesome but how in the hell do you do that um it's all great that's cool um so first we're going to start with like the the very very very first one which is keeping ego out of uh out of your pitches um when you talk to your your team on how to solve problems and this is our methodology that we use oops I'm sorry so there are three things that we do one we identify the problem two we develop a solution and three we present it to the team which seems really simple however identifying the problem for example uh a problems that you make come

across this thing we bu already built totally sucks happens a lot this part of the game is missing something also happens a lot we have these things to do but no time to do it pretty much our life our players don't get it yes uh it isn't fun when we get to this part of the game obviously uh basically which problems or issues are you even even trying to get rid of you have to identify that first and you have to be specific second you need to develop your theory on how to fix it this isn't necessarily the team's Theory this is your theory you identifi the problem you develop a theory on how to fix it you have to put in the work this isn't like hey dudes this this shit's broken you fix it you identified it you must have an idea of how to fix it so some things that we do internally we make thumbnails um we draw Comics we hack together test levels we build tiny prototypes to test mechanics um it's a requirement for our teams that if you believe in your idea

um you must also do the initial leg work um so the team understands where you're coming from sometimes um this is just like a really carefully phrased suggestion but often it's much much much more in depth and finally you need to present your idea which is actually one of the scariest ones because we all have some form of social anxiety and not like haa we're video game developers but like we're straight up humans guys like we're putting ourselves and our ideas on the line and that's scary um so yeah you are required on our teams to present your ideas um it's awesome you've uh identified the problems and figured out great way to solve them but now we really need to hear them now I need to clarify here that these aren't formal things that we go through um this isn't like a process or a checklist like you need to identify and and like that's not how we work we're like human beings and we're friends and this this is a collaborative process um so these are guidelines that inform the way that we work

together um so one when you're at the present Pro or the Present part of this we explain up um this means that you're explaining the pros of the solution to the problem that you've identified um basically You' fixed the the existing problem um or you've introduced something that's new and interesting two you explain down this means that you are identifying as many downsides as possible to the theory that you have um already worked through um this might include development time it's going to take too long infrastructure changes which is pretty scary um affected functionality of the other systems in the game which for something like Overland is like legit terrifying because it's like a balanced strategy game um changes to the asset pipeline which I'm not even going to get into that uh with some of the games that we've worked on uh it could take like a week to fix that sort of stuff but I mean these are the these are the downsides of making any sort of change in your development process or the

design of your game three you need to engage the team in the discussion with an open- mind and mutual respect um and this is going a little bit back to preschool but this is also being like a grown-up um people have ideas and you may not like those ideas but you really do need to hear them out and that goes both ways should we do the idea that you've proposed um are there downsides that you haven't considered because the people you work with are smart brilliant game designers and they are going to come up with things and poke holes in things that you think are Ironclad um can we tweak it to have more pros and less cons and is your idea a good fit and why now why does this method of communication work for our fi development teams now this only works because from the very Foundation of our development team we have a shared goal and the goal is that the game matters more than our egos um and basically everything else that we bring sort of from the external in the game matters and we need to be

true to what the game wants to be um so um we have a shared goal on what the tone uh of the game should be what the audience is going to be and what the actual goal from the very beginning is going to be if the team isn't on the same page when it comes to tone then you're not building the the same game you're building a different game um if you're not on the same page when it comes to audience then you're all building a different game um and if you're not on the same page when it comes your development goals you're also building a different game um engage also only works when suggestions and counter arguments are concrete um we talk about a lot of things that or we talk about things that are answerable in our discussions our development discussions and can be backed up um by side-by-side comparisons paper prototypes very strong logical arguments or observations we treat design discussions like science we um make falsifiable claims and this means that you're making claims that can be proven or

disproven and finally this only works the way that we talk to each other is um if you're able to demonstrate in clear terms for the specific game being built why things are contradictory or complimentary um talking about things that are good for game design in an abstract is super cool and you can do that over beer like later on at the bar um but that is frequently extremely counterproductive when you're trying to solve a single problem that's been identified now why why do we run our development team in this way this produces features that can include support from the whole team and everybody understands what the new features are um we also get buyin and understanding um basically onl the new features are important uh team members have a chance to contribute it contribute to this the design of the game and this one's really important for us um we've actually been asked over the years like isn't it awesome that like Adam totally hired all these like experienced people to like work on the

game so we can tell them what to do and like my brain is exploding because I'm like are you kidding we hired these people because they're brilliant and we need them to contribute to the design of the game because it's better and more amazing because they're working with us um and equally important um we can make changes and provide feedback before implementation when it is very very cheap to do so so I'm going to go through some examples real quick um well not real quick it's part of the talk um of uh some of the things like some of the ways that we've used this um specifically in the development of Overland and I'm going show you some really ugly stuff and I'm sorry there it gets uglier I promise okay so Overland has a roster so this is like a real-time strategy game that we've been building for like half my life it feels like at this point like three years uh and it's getting there it's getting so pretty and so wonderful but this is our old Rost I'm going to show you the old roster which is what you're looking at and then I'm going to show you the new roster so we had the little icons that totally

weren't selling it um they had annoying screen size problems they were super repetitive um it cluttered up the screen there was just like junk everywhere uh and it didn't solve the problem where we needed our players to grow attached to their crew we needed them to have empathy for their little dudes on the screen or dudets or doggies we totally have doggies um obviously uh and yeah totally wasn't selling it so uh this is our new Overland roster um we proposed a group photo with current player with the current player highlighted um it's turn-based game so Cletus is our highlighted player um and we talked through the pros um basically showing group togetherness and groupness a lot better and this is like down in the corner of the screen um and the cons which was seriously a lot of extra work we didn't have any I mean we had some like code that we could kind of reuse for this but like we straight up had to build this from scratch and it took a

while um but this combined ideas from Adam and Heather pen who's like a magical our art director um to produce something better than we could do individually um with really in the long run not too much investment or work um so that's like one of my first examples the next one um so in Overland as you're playing like you go on your little like 9 by9 grids and then the higher level strategy board is um or strategy level screen um is our map screen um so I'm not going to actually talk about the map screen I'm going to talk about that fire right there and you're thinking yeah okay whatever um so we got all these really really cool animations um because for the longest time like our D's just like slid around the screen and um yur our animator in La sent us all these animations and we built up the map screens to show the car would drive in it would pause it would park the passengers all of them would

get out walk over to the campfire which is like totally thematically appropriate sit down just kept going it looked awesome um it looked super cool and it was totally keeping with the Thematic um with a theme of Overland which is like your survivors on a road trip across you know post-apocalyptic America um except thank you heather as she pointed out it created legit horrible pacing you had to sit there forever and it was boring it looked awesome but it was so boring and it was like it took forever you were already done strategizing people are still moving um so she s she suggested that we should basically just jump cut it um we absolutely could not agree on this because like it's really hard to cut your babies that you think are really cool um so we're like whatever we're going to Pro program this up like it took 5 Seconds um and she was absolutely 100% right which is a theme

with Overland uh Heather's always right she really is an incredible game designer and no you can't have her not yet a nope she's ours she's ours for a little bit longer okay here's another Overland example um we had an entire cast of Overland characters which looked like this who are like super cool super iconic and they were in the game for quite a long time we spent a lot of time designing them in the first place um that it was uh super easy to produce and most importantly in any game development it was done we were done with care or like game characters um and in our the way we work if it ain't fixed don't uh touch it like it's not broken it's fine and this was 100% Adam's stance um and mine to be perfectly honest but uh these are the new Overland character models uh Heather who's is always right proposed a new direction

for the models um it took a lot of time to put the new idea in but once they were in the game it was immediately obvious um that the this was a much stronger pitch um it solved a ton of design problems that we had um and even with Adam's Adam and anti- stance on this change he had to admit vast Improvement also with him it's like let's prove Adam wrong um but yeah these took forever um to redo I mean we had to put new clothing and eyeballs and um different colors different outfits and like you couldn't tell immediately like hey that dude's the mechanic he's got the thing on his head um so it like it changed a lot of the the rules and um design discussions that we had on like sort of the iconography on the UI which we've been designing for a year so like these were super super important and it's it's you know just Heather like we're going to fix something that's not broken okay so those are some of some of the the ways that we've um used this to fix things in Overland

um okay so I'm going to tell you a little bit about what happens um when we just can't agree um which happens I mean all the time uh sometimes all the time we're pretty flexible so I don't know only 100 times a week instead of 200 um this is when we're backed up into something that is uh definitely turning into a contentious decision um um our feelings are getting super hot um people are digging in because they think their idea is best and the only way forward um and that's a really awful place to be so this is when we decide to Circle back and there are two ways that we do this and these are really really important and I'll get to the endless in a second one we postpone this means that we postpone the decision until we have more information to Circle back this means that it's not necessary to have this feature in this design discussion right now because we

can continue development without it we don't have enough information that we can come to a consensus so we we can just postpone it and circle back just make a little note we'll revisit this in like I don't know two months when we have to again the other one is intermediate Impossibles we use something called intermediate Impossibles when it is necessary to move on through a development bottleneck and I'm going to go a little bit more into that because it seems like kind of a crazy term okay so postpone I'm going to talk a little bit more about postpone um probably going to go over just what I just blurred it out at you because I went a little bit too fast this is only possible when the design decision is not bottlenecking development um and most importantly it's only possible if you have room and flexibility in your budget to postpone this um which is usually possible if it's not huge um but what happens when you actually postpone the decision ision you learn um your brain

is always redesigning this game as you're making it um because we're Indies we do iterative design nobody starts out with the design documents like this is what I make and three years later that's what happens like that just doesn't happen so your brain's always learning more about what you're actually creating as you go so each passing day you're getting more and more and more context on how you could possibly solve that problem without the contention um so the other one is intermediate Impossibles um so this is what if you can't postpone the decision what if that problem is blocking development and you can't come to a consensus and this is when you use an intermediate impossible um this is when you seriously you hack together whatever garbage solution is easiest to do to make sure that you can go from point A to point B and who cares what who cares what that middle part looks like CU you don't have enough information to fix it properly but you must continue development time is money if you're arguing over some stupid bridge that you have to get across just build the damn Bridge in any way cuz you can always rebuild it

when you know what you're building cuz you can get it are we there okay and we do this all the time and I'm going to show you some intermediate Impossibles and like how awful like two years of staring at them can possibly be okay so this is Overland basically one of the earliest digital versions of Overland and make special note of those pink monsters um so this is I don't know 20 and 14ish maybe now we needed monsters so we just hacked those suckers together in like I don't know 5 Seconds we eventually got this thing onto a 3D board and we still didn't know what kind of monsters we were going to have they didn't have really mechanics we just knew they appeared from the outside so we just brought those ugly things over um uh this method obious obviously is going to require a lot of circling back eventually these things are going to have to get out of this game um so this

is our first 3D space uh here's our next 3D space and we're seriously now 18 months into development um and this is before GDC of 2015 we put these monsters in like a hot minute before we actually put it in the mild rumpus um and this was in form this design wasn't formed by like an entire year of development um but these were super weird places holders as well this was our second intermediate impossible for our monster designs in Overland but they did get much closer to the final monster design um once we knew more about what the game was actually going to look and feel like so this is what our monsters look like today um well some of them there's a couple on the field um these have um hopefully final models animations and colors but it's entirely possible that in like 3 months Heather may come back and be like like that we might need to

fix this so these might actually be intermediate imposses I don't think so but we always leave that open that something small may change um as we learn more about Overland as we design it so within our development on Overland we still have postponed elements that aren't bottlenecks yet we have a lot of things that we've just straight up postponed until we know more about the project um but when they are bottlenecks we will hack together some sort of solution until we can fully flesh out the cont context of the right solution for example um we all have different ideas about overland's ending um and zero consensus on it there's no obvious right answer right now uh given what we know about the game um but yeah even at this point in development which we've I mean we're like three years into Overland the ending for the game is not fully fleshed out at all um so yeah it'll be a surprise to you too now um but Becca what if nothing worked what if we tried

to identify the problem we tried to develop a solution and we presented the solution to the team we can't decide what to do what do you do you need to uh sorry oops you need to lean on your leads this means that you need to learn how to trust your leads to make calls so long as you are within budget um you have an art director for a reason um you have a producer and BISD member for a reason um these are your experts lean on them learn to trust their judgment you also need to trust your team and not the hierarchy um I don't really care how many games you've shipped when we're developing and designing something like that doesn't matter I don't care about your ego I don't care how long you've been in the industry what I care about is that you have the same shared goal and are you moving to the same place now finji does this all the time um some of our most recent examples Joselyn our audio director audio

director um wants a more rhythmic soundscape and this is 100% her called to make Heather our art director wanted to redo all the color palettes um totally her call to make um we had a lot of disagreement about whether or not Overland should allow diagonal movements on the board um Heather suggested it and Adam trusted her design judgment um again because Heather's always right um and it was easy to test and she was right um and like that's uh trusting the team and not like who's the lead designer if somebody has a good idea like it doesn't matter where that idea comes from now it's important though like trust but verify that your leads are actually right this means that once your lead implements their solution discuss the strengths and the re the weaknesses as a group in the same way the same mutual respect way that you've developed your uh team in the first place for example we implemented Heather Survivor even though they seemed way too cute for

Overland um when we were initially discussing them um and we removed the campfire animation because it just didn't work and we spent a lot of time making it and then threw it away okay so finally Indies often work in a vacuum um obviously uh we forgot to or feel like we shouldn't seek outside's perspective and this can lead to uh poorly constructed ideas on what the industry actually looks like um this can also lead to poorly constructed ideas on the financial viability of our projects um also it can lead to toxic Partnerships with creative collaborators Um this can also lead to Quick burnout with project abandonment so why why do you need mentors you need them to play your prototypes you need them to look over your business plans and you need them to provide feedback on your studio practices so the Prototype viability um we worked on a game called Portico which

we did a failure workshop on a couple years ago um for over 9 months and it was fundamentally broken we misread the industry we wasted a bunch of money um and if we had taken this to our mentors earlier we could have probably saved ourselves months of development um for ptical specifically we had no strong reactions to the game play like that when we did take it to our mentors there's a general sense of like this isn't that fun um and to be perfectly honest we didn't listen listen right away we just kept going on it um so ask yourself these questions how long have you spent on a game that others told you just wasn't working um how long did you work on something that you knew wasn't working but refused to vet with someone outside yourself or your team um how much time did you waste avoiding the inevitable you need a mentor or 10 to help you vet your work before you waste months of resources um for business plans um Overland needed a ton of alpha players um and we needed to vet the alpha Early Access programs so we actually leaned on

our mentors um and did a ton of research of our mentors um some of whom are actually in this room right now um we needed to create a way to build a sustainable sustainable growth for our tiny team and get real players providing valuable feedback on our strategy game and we interviewed and researched other de interviewed and researched other devs who had run Alpha programs of varying success in our genre to find threads or an end of best practices in the current market and then um Studio practice mentors can help guide and fix the ways your team or Studio functions um they can help alleviate Partnerships that could have gone toxic um this is just basically called Pure mediation um before things go too far um mentors can also provide an outside perspective for team members to keep development teams clean with workflow struggles miscommunications design decisions honest assessment of whether you are reasonable which also is very important and not in the way that you're uh or if you're being unreasonable with the way you're interacting with your development team so I'm going tell you a quick story

actually um so we provided a mentorship to the obviously the Night in the Woods team over the last like 3 years um and they're distributed um on multiple time zones across the United States and they're basically operating solo so they had like legit workflow problems um the thing that they were doing just had Adam and I completely speechless about 18 months ago um and there was absolutely no way that that workflow problem was going to allow them to finish the game um and if they hadn't brought that problem to us like there is no way that night in the woods would have come out last week um and probably would never have come out if that hadn't been fixed um so yeah and we also um specifically with the Night in the Woods team have advised on all sorts of quality of life issues over the last three years because we don't have we have skin in the game but not that kind of skin in the game so yeah um in conclusion um these are the practices we rely on to avoid talk at conflict and engage in good

conflict um and productive arguments about the best things to do in our project the upsides in our experience this is the way of following through on the promise we make to our collaborators um we're part of a team um and it's a way of taking advantage of all the intelligent folks on your staff the downsides um it can be super timec consuming in the short term um you have to think about your design meetings with like more rigor and more thoughtful um it's also a hard system to force on to people um you really have to like lead by example it also means it can take months in order to get this machine up and running for us in the medium term um it uh Works uh and if we can't if we find a better way to do this we will absolutely switch over um all of this talk was built using this exact design process um this has helped us produce better collaborative decisions um and we can't not work this way at this point so thank you very much [Applause]

um so I knew this talk was going to be sort of long so I don't actually know how much time we don't have any time for questions but I do have a wrap-up room which I will be at for the next 45 minutes um we will go to 2018 if there's room or 2022 if there's not um so yeah if you have any questions feel free to follow me I'm also bringing Adam with me so yeah we'll both be there to take questions