No Mavericks, No Martyrs: Sustainable, Collaborative Production

[Music] thank you hi everyone and thanks for coming to know Mavericks no Martyrs sustainable collaborative Productions um if you haven't already please do silence your cell phone and I'll get started so my name is Carrie Patel I'm a game director and narrative designer at Obsidian Entertainment and I've been with the studio for eight and a half years I've worked on the pillars of Eternity series on the outer worlds and I'm currently directing a vowed now in my time in game development I've noticed a number of Trends on teams as you probably have as well so today I want to talk about how we make games and how we can improve the process of making them but first as with any good talk I want to start with a provocative question is crunch good actually so I did a little bit of research and it turns out the answer is no of course it isn't but we already know this we know it's bad for teams and it's bad for games but the

real question is if we know this why do we end up crunching anyway even when we're trying to avoid it so I'm not going to discuss crunch culture broadly because that's an enormous topic instead I want to focus on two often self-imposed team roles that can inadvertently lead a team into Crunch and a host of other problems including misdeliverables broken content and fractured relationships and these roles are Mavericks and martyrs it's important to talk about Mavericks and martyrs because they can lead to a lot of dysfunction and overwork on teams even on ostensibly healthy teams that again are trying to avoid crunch they're also incredibly common you've probably worked with several over the course of your career and you might have been one yourself I know I have they're common because they're a pervasive myths in our industry that disguise their vices as virtues and all of those myths center around one word fashion so I want to be clear I'm not against passion it's important to care about the work we do and the teams we collaborate

with many of us are very passionate that's what Drew us into the industry and that's what's kept us here but passion does a lot of heavy lifting when we talk about the way devs work and it leads us to glorify and perpetuate the roles of Mavericks and martyrs in some really destructive ways so let me start by diving into these roles and the dissonance between their myths and the reality of what they mean for teams so let's start with Mavericks Deb a is an outside the box thinker they don't let things like pipelines and best practices get in their way when they have a feature or content goal in mind they'll find a way to make it work even if their implementation is held together with silly putty and crazy glue this is a Maverick this is someone who will find a way to make something work despite tools and processes and Mavericks are often seen as being inventive self-sufficient problem solvers but the reality is that the short-term fixes hacks and workarounds they create lead to more problems than they solve so to illustrate this I'm going to tell a hypothetical story and I randomly picked

from some of the most common names in our industry so we're going to talk about Dan the Maverick scripter so we have our level planned around a handful of quests and we've scheduled the team's time around working on those quests but Dan the Maverick scripter has one extra Quest that he's really excited about and he wants to get it into the game so what happens Dan sets up and scripts the quest and because he knows the rest of the team is strapped for time he takes an initial shot at getting the other work in he writes the initial Quest Giver dialogue he's not a narrative designer but how hard can it be he tries propping out the encounter space now art doesn't have the assets he really needs but he's able to resize some and kit bash a few others and it looks pretty good he pulls in some enemies from another level he adjusts their stats and he creates a custom encounter setup to do what he wants and so at this point Dan's taken a few shortcuts and the work is a little bit unpolished but it's mostly there and this was pretty easy for Dan to do so how can it really be that much more work for the rest of the team to just go in

and finish what he's already started so I want to look at how this becomes a problem so the first problem relates to bugs and performance debt so for a very silly example let's say that we're building this scene of some sheep and one white sheepdog right so most teams have recognizable pipelines for turning ideas into placeholders into shippable work now a Maverick is often subverting these pipelines either for the sake of expediency or because they're not familiar with them and a Maverick is also much likelier to see something as close to shippable than it closer to shippable than it really is especially if that work Falls outside their personal area of expertise or their department and all of these shortcuts and the placeholder work and the kit bashing that looked good enough to Dan is not necessarily good enough for shipping your Maverick could have done any number of things they might be using a consumable as a static prop because it looks good even though now you're violating your game's internal consistency roles and you're going to confuse players they might have placed some lights that are now leaking through the level in places they might have

hacked together a an encounter or a cut scene or a scripted moment just well enough that it works 75 of the time they might have applied an unfinished texture to a creature variant any number of things but in all of these cases doing the work the right way might actually be akin to starting over in which case the initial placeholder work that the Maverick has put in hasn't actually saved time it's just masked problems and that's the other issue with hacked implementations real placeholder work whether we're talking about VFX or temp textures or temp lighting or stub writing whatever it might be is usually designed to be very obvious so that it gets replaced or removed before you ship your game but a Maverick's honest attempt at getting something in and getting it representative may be just subtle enough that you're still discovering bugs months after you thought the content was done and of course it's just as easy for the opposite to happen if the initial method for getting this content in was rushed siled work then chances are that the intent and the goals of that work were never clearly communicated and it's easy to over correct

and it's worth calling out that all of this hacked work can lead to a lot of memory and performance issues and those can be very challenging to track down especially because the burden of doing so will often fall on your tools and Tech teams who may be unaware of any shortcuts happening on the content or gameplay sides so the point is if shortcuts are if we're taking all these shortcuts just to get something into the build the team is going to have to reckon with that debt eventually and Maverick processes all but guarantee that that debt will come as costly surprises later in development and all of these bugs are going to get assigned to other devs on the team to fix and do the real work which leads to bigger problems so getting temp work to shippable means unscheduled work for the rest of the team so at this point we've added one extra piece of content that we didn't plan for and it took additional work not only from the individual driving the effort but also from other members of the team hypothetically one extra Quest can cost design time to set up and script the quest events narrative time to write any characters associated with it

combat excuse me combating systems time to set up encounters loot rewards experience scaling environment art time to set up or reconfigure any play spaces cinematics time to set up those cinematic conversations for those new NPCs you've added lighting time to highlight those NPCs in any new place spaces and account for the environment changes and of course audio and VFX support and we're talking about a quest right now but you can find the same pattern of scope increase in any kind of content or any type of feature so the point is this isn't a free extra Quest that one person has squeezed into the schedule this is something that has now become a commitment across multiple departments and accounting for all of that extra work means that we've put our plan deliverables at risk we pulled in additional devs to finish the work and we took time and focus off of the work that we were planning and this problem is very easy to lose sight of because it ends up being about all the things we didn't do but if you've ever cut one thing because something else got too big if you've ever shipped content with less polish or iteration than you intended if

you've ever seen your production slip into Alpha you've probably experienced this and the biggest problem at all of all is the false Narrative of success that develops around this it's a narrative that said that says that we succeeded because of rather than in spite of Maverick develop development processes looking back we end up talking about them is if they're the thing that made the game work and not the thing that almost sank us so I want to change gears briefly and talk about martyrs so devby is a hard worker they're not afraid to put in that 110 percent even if that extra 10 or so percent comes in during early mornings late nights and weekends at the office they give their work their all and they expect the same of their colleagues this is a martyr this is someone who will get the work done no matter what it costs now a martyr can also be a Maverick and vice versa often these habits do go hand in hand and these devs sound like they're high performers and critical team members and they may very well be but their work habits are likely doing damage over time to themselves their

teams and their projects but I know what you're probably thinking these are resourceful hard workers so what's the problem so let's take tell another story so Matt the Martyr wants his level to be the biggest and coolest in the game so he spends a lot of extra time on it he adds some Extra Spaces where the the rest of the team can play some loot some additional encounters some found storytelling maybe even room for an extra dungeon that the dungeon team can put in when they get to their B and C content and he spends some extra time some late nights some weekends at the office but he gets all the work done and now the team has a level that is bigger than what they planned on and it needs to be filled with content quests enemies loot everything and finished by Art and yeah this is maybe a little over time for some of the other departments but Matt put that work in right so now the team faces a hard decision do we tell Matt to cut that extra content back assuming that's even feasible at this point do we ship with a sparse level or do we put in the extra work needed to get it done and that's the

immediate problem but there's some bigger long-term problems that are very subtle here the first is that you get bad data so raise your hand if you've ever looked at your schedule thought back to a previous project and said we did twice as much with a smaller team back then how did we pull it off it was probably people putting an unscheduled overtime so part of the problem with this is you lose track of how long it takes to really finish something and that means that if your five-day task got finished with late nights and weekends that's extra time baked in that is then going to bacon when you're planning those tasks in the future you risk planning and scoping around assuming that you're going to get that time and perhaps even more dangerously the team loses sight of what it looks and feels like to finish content without pulling that over time this becomes a kind of muscle memory we also enter into an overtime arms race this resets the team-wide expectation around work-life balance people end up putting up with or even accepting practices that are bad for their personal well-being their productivity and their teams they do this because

they don't want to look bad to their bosses and their colleagues they don't want to let their teams down and this is especially harmful for juniors and newer team members who may be more susceptible to accepting bad habits as normal if they see them treated as such we also enter into a culture of resentment and mistrust so the work habits of Martyrs and Mavericks cast their teammates as obstacles to their goals and Ambitions they say I'm putting in the time and effort to get some more cool stuff into the game so why can't you I don't want to share this cool thing I'm working on on the side because then you're just going to tell me why I shouldn't do it by the same token teammates end up seeing Martyrs and Mavericks as unpredictable demanding and untrustworthy they say well now I'm working late or cutting something I cared about because you made extra work for me or I'm getting feedback about the quality of my work based on something you hacked in and this is obviously toxic over time this will further reduce open communication and transparency that you need to create a healthy environment and

effective problem solving on your teams the summary here is that Martyrs can be Mavericks and vice versa these habits really do go hand in hand and they can occur on any discipline on any type of content or feature because the point is that nobody in development does their work in a vacuum anything that one Dev does means work for somebody else and again the biggest problem here is the false Narrative of success when in reality we pulled this off in spite of and not because of our bad habits and careless scoping along the way and there's another less obvious problem with all of this and that's who gets to the way to be a martyr Maverick so one conversation we're having a lot right now is about the need for more diverse seniors and Leadership on our game teams so we have to be honest about whose ambition is allowed to thrive unfettered and whose is reigned in from the start when is an overachiever seen as a bold thinker or a star performer and when are they seen as naive and Reckless who shines because they get to pull in an entire team to finish and fix

their work and whose scope is constrained from the start and who do we see Rise as a result the fact is a Superstar's work especially when we're looking at something on the scale of a full deliverable not a jira task is really the result of a lot of people coming together on a larger team any area or Quest or creature you can think of is not going to be the result of just one person you have environment artists level designers narrative designers animators programmers audio designers VFX artists all coming together and putting their work together to get that content done so when we say that a Maverick or a martyr's extra work really paid off we have to be honest about who else chipped in and this isn't about hobbling strong performers this is about being intentional about how we spend the time and effort of our people and making sure that good team members get a chance to shine that all of our team members get a chance to shine it's also about making room for good team members rather than merely loud advocates ultimately we want to elevate the best performers on our teams and these are the people who are going to be Force multipliers for the

rest of the team and strong mentors for more Junior devs not the ones who pull recklessly ahead and drag the rest of the team with them so I want to propose an alternative and that's that great teams make great games not rock stars or ninjas or solo contributors I could be the best writer or artist or designer on my team but it doesn't mean anything if my work can't be used and built on by my colleagues again nothing any individual contributor does goes into a game without the collaboration of their peers great teams are happy healthy and engaged there is no virtue in late nights weekends at the office or destroyed relationships there is no virtue and burnout great teams focus on the project as a whole not on discipline siled fiefdoms not on personal work and vision at the expense of the rest of the project and the team so as directors leads and producers how do we make room for great teams to grow and thrive we must bust the myths that equate passion with overwork and aggressive

ownership and we must normalize Collective sustainable habits collaborative sustainable habits happier more stable teams can stick together and make better games when we break the cycles that lead to Mavericks and martyrs so how do we promote healthy sustainable practices that will serve our teams for the Long Haul how do we empower the entire team and how do we avoid enabling practices lead to burnout overwork and the kind of messy production that ends in a lot of production debt so again I want to be clear I'm not bagging on passion or personal investment or creative problem solving these are all critical for a team but they need to exist in a healthy sustainable Manner and they need to be deployed for the support of the team and the project not the advancement of an individual's personal goals so how do we get there first we have to be able to explain the problem to our teams in leadership and that's why I've spent so much time up to this point defining Martyrs and Mavericks people have to understand the problem before they can solve it and the fact is most people even Martyrs and

Mavericks don't actually want to work in a state of constant crunch conflict and role uncertainty it's really stressful but the Dynamics that get people there are often easy to miss so as leaders and people managers it falls on us to help people recognize and break out of these Cycles so how do we explain the problem well first again we recognize that this practice persists because of a false Narrative of success so we have to be ready to change that narrative and that means looking back at past examples and having clear data yes we love the way this area or this Quest turned out in this game but here's how long it took to do that and here's what we lost as a result it means getting into the details if we're adding this additional Quest or enlarging the map here here's what it's going to take here's where it fits into the schedule and here's what we bump or de-prioritize as a result it also means getting to the root of the behavior a lot of times Maverick and Martyr behaviors are driven by deeper rooted fears needs or goals we need to understand what those are it might be a desire for more autonomy or ownership it might be out of fear for the outcome of

the project or it might even be misalignment on what done looks like but once we understand what's driving those behaviors we can take steps to Target them in a more Tech in a more targeted manageable way we also need to Define our MVP that's our minimum viable product and we need to work towards it at every stage of production our minimum viable product is going to be the least amount of work that we need at any stage to evaluate whether we're on track or to unblock other Downstream work and an MVP focused approach is likely going to mean a more iterative process that's defined by shorter steps frequent review and simple placeholders and there are several advantages to this kind of approach the first is that we can catch a lot of scope and Direction problems really early when we still have time to Pivot or scope back it also reduces the tendency for people to over invest in the details which makes it both practically and psychologically easier to make hard decisions and cuts when we have to and it also opens the door for more cross-department collaboration and this

is really where the magic of game development comes from it's not one person putting their heads down and coming up with a perfect Flawless content plan over two weeks all by themselves it's people working together across disciplines and adding great ideas to good ideas to lead to Stellar content that brings me to the next point I highly recommend that you establish cross-disciplinary strike teams rather than discipline Silo departments this allows for a better sense of shared ownership for the feature or unit of content that your team is working on and it leads your team to look at their process and say we're all building something together rather than I do my part and then I kick it over the fence to you and I hope you know what to do with it this also makes it a lot easier to catch potential problems artists can look at a blockout or a layout and catch any tile set issues that might crop up if you have an animator on your character team they can identify whether we already have existing rigs or animations that we can share with the something new that's being proposed or make small tweaks in order to get us there so that we're saving time and Dev resources and this also Fosters a much better

sense of Fellowship on the team you're much less likely to just dump a bunch of work on somebody who you work with and interact with every day and who you really do see as part of your team than someone again who's over the fence and finally this encourages devs to be more mindful of scope and of the implications of their work which brings me to the next point we need to frame scope as a shared team responsibility not as an imposition from producers and leads scope is not a producer or a lead taking your fun away it's how we ensure that we have a completed game at the end of production and a team that's ready to work on the SQL or the DLC production processes are not there to stifle creativity they're how we turn ideas into content and how we ensure that our team's time is well spent so we want to give devs the responsibility for sticking to their scope for keeping their work on track and making decisions about their work that respect the time and schedule of their peers above all we want to avoid the Learned helplessness that comes when someone says well you gave me a week and that wasn't enough so how do we do this

at obsidian we have a philosophy we are a process we call draw Spider-Man and I want to give credit to Justin Britch our director of development for coining this explanation so draw Spider-Man is how we describe the push and pull between visions and constraints so if I tell an artist to draw Spider-Man that could mean a lot of things it could mean a really simple sketch or a very detailed portrait and it can be very hard to sync on the exact level of detail we want in something with the individual implementer especially if they're from a discipline or a background that is very different from our own so when we task out work our intended level of detail and complexity may be very different from again what the individual implementer is assuming so how do we how do we get to the bottom of that if we know the time box we can figure out what is possible with the time we have so if I say draw me the best Spider-Man you can draw in a day or show me what a block out show me a blockout that you can do in three days then we see what's achievable and then we can make other scoping decisions accordingly and this avoids

both the scope bloat that can come from an individual contributor assuming that they have to do more or create a higher level of detail or complexity and it also prevents us from accidentally pushing someone into a martyr role by demanding too much in too little time this also keep we also want to keep the team's focus on the big picture scope is not just about what we're saying no to it's also about what we allow ourselves the time to do in the future so we say we can't double scope on this one level because then we won't have any time enough for the next one which we're also excited about and finally we want to lay strong foundations by building time and flex into our schedule and communicating honestly with our teams if we want our teams to trust that they won't have to become Mavericks and martyrs in order to get a good game done then we need to show them that we know where we're going and how we're going to get there and we will probably have to message this multiple times over the course of development at a tactical level this means reality proofing our schedule building in sick time vacation time meeting time we can't assume 100

efficiency from everyone every day at a higher level it also means syncing regularly with the team about the goals and Visions for the project and what that means for the work we're doing in the day-to-day also means being ready to have real conversations about hard Cuts even if people don't agree with cut or pivot decisions it's much easier to accept them when they understand the reasons why and when they feel they've been treated with respect and ultimately we want to model the behavior we want to see from our teams that means going home on time setting strong boundaries communicating well and encouraging our teams to do the same ultimately healthy well-functioning teams are built on honesty communication and respect and that's something that we have to build and reinforce with our teams every day thank you very much and thanks [Applause] special thanks to my colleagues at obsidian and to the avowed team especially and to Brick Clifford Matt

Hansen Tony Sue and Justin Britch for their feedback on this presentation and please remember to fill out your evaluations and I can take any questions hi so thank you for the Temptations very insightful um I had like two questions first of all do you see this behavior only in larger teams or smaller teams and if the team is smaller do you see maybe less of that behavior because of the communication that is happening I think it's I guess faster or more regularly and the second question do you feel like the scale dejao Frameworks help solve some of those problems with people kind of cross-functional teams spending more time together and figuring out that you know you add in a quest kind of takes time from all the other stuff that we have to do um so for the first question um it's most of the teams I've worked at with with have been medium to larger

um so it's it's hard for me to say how this works out on smaller teams but I think you can see this happen on a team of any size like every everybody's scope aspirations are always a little bit bigger than what we have time for and I I think that's true for small projects as well as large ones um could you repeat your second question about the scaled agile methodology and cross-functional teams different production methodologies I think the what I think the biggest thing that helps is just making sure that um that teams are are you know closely collaborating that again if you have these cross-department collaborations where people have more visibility into the effects that their work have you know has on other people working with them I think that helps a lot because I think there's a lot of um there's a lot of black box mentality that can go in when you're like well this is the part I do this is the only part I see and then someone else does the rest that also helps get around the stuff that you know you don't know what you don't know and the more you're interacting a little bit with colleagues

who who can point out like hey we built this tool this way you're not supposed to be using it that way that's going to to create these bugs again getting that exposure to um to teams and other disciplines is going to help you just naturally catch that stuff a little more quickly all right thank you so much I was like oh can you hear me yeah uh that was really great talk thank you so much for giving it and uh props for the meme usage that's very good um Let me throw a hypothetical uh at you because I like the way that you were talking at the end of the talk about like okay Cuts how do we make hard Cuts how do we communicate hard Cuts how do we uh like kind of engender trust in our teams I was wondering let's say that you have somebody who is new to the team and they don't have that like learned trust yet so you come to a decision point something that they were like championing needs to be cut it's just generally the right call not a not an easy call but the right call seems like everybody's on the same page about it but this new person is new to the team

they don't have the trust how do you you will build trust with this person over time of course but how do you bridge that like trust Gap in the moment I think the best thing you can do is just be very clear and honest with them about the reasons for the cut and how we got here and what you're going to do instead of finishing that content you know so it could be well there were some very complex and risky things we wanted to try with this content and we tried them early on and we realize now that the what it's going to cost to get this finished and shippable is actually much more than we have time for so we took a big swing we took a big risk and this one didn't pay off so we have to cut our losses now it could be that you realize that um yeah I mean it really does depend on the reason but I think being very clear about that um I think that helps yeah yeah but yeah I mean it's always going to be a process especially if somebody's first experience is you know sort of seeing that cut right what what happens though

if you like you you say that but like they have not they don't have the same perspective that you do so they're a little bit like disagreeing with your interpretation of like what is true like like in the sonar that you were talking about we wanted to see if this was uh viable we knew it was risky we've decided it's not viable here are reasons why and they go I don't understand I feel like that's not true like what's your what's your how do you work through that with somebody thing you can probably do is just get into the details you know so when we say okay well again we look at the schedule and we say you know we needed to be you know locked on this content by this date we're one week away from that date and we still have a lot of bugs and a lot of open questions about this content um you know I think you have to kind of bring it down to the math like there isn't a world in which we we get that amount done in this week and so rather than continuing to hammer at something that's just not going to get done um we need to redirect our efforts and our resources and you can get into you

can get into the specifics I mean again this is a hypothetical so it's a little hard to but like yeah you can look and say like here are the big things we need to finish this might look easy to you from your perspective but this new gameplay element that we've been trying to implement this is going to require tools and Tech time that we don't have here's what the tech schedule looks like they're working on performance and optimization or you know again something else that we can't sacrifice and just breaking that down so they understand where those costs and risks are coming from you know and where why you were at the point of making this decision especially if you're trying to make it early so that you're not sinking a lot of time into something you know you're not going to be able to finish to satisfaction thank you so much um hi um first of all thank you for the great talk and another question so the Mavericks they're usually highly creative people so do you have any means to help them vent out from time to time so they're not feeling um squashed with their creativity

uh and sorry could you repeat the question one more time so the Mavericks they're highly creative and when you tell them not to do stuff yeah you have any other means uh during the work hours to help them be creative I think I try to it helps to try to redirect so you obviously don't always want to be in the position of just telling people here all the things you can't do at some point you want to tell the people here's what you can do and so that might mean looking at other examples of really strong content that either the team's already made that maybe they've made or that you've made on previous comparable games um it might mean looking at your gameplay toolbox and like understanding all the things that your game and your tools do really well and saying here are the things we can build that are awesome that we know work really well let's not focus on all the things that we we can't do let's focus on the things that we can do and I think just trying to channel that energy into something more productive rather than defeatism and sort of you know looking and saying well why can't we do this world of other

things instead of hear all the cool things we can do okay thank you and I think we are at time but I can step out to the back and continue to answer questions for anyone else who has them so thank you all very much for coming foreign [Music]