My To-Do List: Organizing a Producer's Work

[Music] okay thanks for coming to my talk my name is Bernie Yee I'd like to give a quick intro of my background and what I'm talking about today I've served as an internal producer into an internal dev teams currently I'm at oculus I've been working on the set of demos that are maybe you'll see today if you get a chance to I've worked at PopCap where I got to work on two great teams peggle two team and the plants vs. zombies 2 team before that I was at Bungie working on destiny I've done external production which is a different beast we're won't be talking about that as much today but I've been at publisher side at Atari and Sony Online I've done a bunch of startups I've tried my own startup we raised some money and didn't get escape velocity I worked for some well-funded startups some poorly funded startups I've done some business development work I was at Harmonix trying to convince the

studio to build a PC version of rock band a great idea we didn't get enough traction and I also taught game development production at Columbia University I fully convinced several of my students to get into the business to them I apologize so I was thinking about the the subject of what producers do I was building a house and you're constantly creating lists of things and thinking about whether they're worth doing or not so much of the work of a producer comes down to this list making and it seems like a very trivial task you make lists to go shopping you make lists to to take care of your kids but it occurred to me that even in that simple task the process by which you derive that list is loaded with meaning this talk is really about how you how I as a producer approach creating this to-do list this isn't a talk to tell you what should be on that list how the you should spend your time from moment to

moment we have other talks there's a there was a talk today about priority prioritization there was a talk after mine about communication all these things are very important but this is really about a frame of mind a kind of a conceptual framework about how which you should approach your work because really kind of like a Jedi Knight you got to build your own lightsaber and this is how you go do it the background story of this too is I draw a lot of parallels to sports and deliberate practice I used to race bicycles and I was not very good I've placed in a handful of races through and that was when I was much younger and had more time to Train and I had a coach who used to tell me Bernie when you're racing get to the front be in the right position watch their attacks pay attention to what wheel you're on don't ride in the gutter over and over again and because my results weren't fantastic I kind of thought this is really hard I got a chance to watch a few years later in the midst of the Armstrong doping

years televised Tour de France and they put a camera in the car where the directeur sportif the coach of the team was talking to his team on the radio and sure enough he said the same things get to the front Frankie why are you on this wheel get out of that position watch the attacks the same sort of thing that I would hear as a very mediocre bike racer and it reminded me that you have to be deliberate about what you do you have to do things consciously even professionals people are at the far end of the bell curve the top 1% of the 1% needs sort of the same reminding of basic things over and over again and if you don't do things deliberately and thoughtfully you're ultimately just a robot you're following a prescribed set of tasks and it limits your growth as a producer it limits your team I mean ultimately limits your game so it's sort of a microcosm of how you evaluate games

themselves you consciously evaluate the state of this game at any given time you should also consciously evaluate what you're doing as a producer so one thing a producer does in general is trying to get everyone on the same page at Facebook you know oculus was purchased by Facebook and and Facebook doesn't really have a producer culture I had an engineer ask me so you're the producer do you tell people what to do I in some sense I guess I do someone will ask me burning which I work on next and I'll say you should work on this thing it seems to be the highest priority but in reality I'm representing the the priorities of the project this is an important distinction producers are not managers it's not my personal authority I'm not your art director I can't tell you how you're gonna improve as an artist I can't give you creative feedback I'm certainly not gonna review any code God knows and I've also learned it's never hurt staying the obvious so let's go through the definition of what a producer does very quickly you plan

your schedule you create priorities you articulate priorities you get priorities of your team you resolve a lot of conflict whenever there's more than two people in a room sometimes two people only is all you need to create conflict people don't see eye to eye on a task the importance of a task how to solve a problem maybe there's egos involved almost always as egos involved UNEP defender of the team quite a bit you resolve you you you're the meat shield for all sorts of people outside your team that have opinions on how you should be doing your work and how your team should be doing your work what direction you're going sometimes these are valid inputs they even valid inputs and opinions can be distracting it's your job to take body blows for the team more often than not you spend a lot of time with marketing anybody play destiny or shadow of Mordor there was a huge marketing campaign around these games whether you like it

or not marketing is super important and gets the word out in a very crowded marketplace you have to have a good working relationship with them some of the less sexy things as if working with marketing there wasn't sexy least sexy enough is head counts and P&L so part of the plan that you build up front will tell you how many people you think you need to build your game how much they cost to hire and whether your game makes money or not how much how what you have to do and I think you see a lot of this on Kickstarter now where people spend donate money to Kickstarter you've raised a million dollars how come you can't deliver this game games cost a lot of money good people cost money to work and at certain places like Electronic Arts a producer can be sort of a Project Lead this is a creative vision holder creative vision creator role and I think depending on where you are the proportion by which you do these jobs vary but I would argue

that it is all these all these tasks are part of what a producer does I heard someone explained to me what they thought production was was you're juggling plates and you have to know which ones you let fall and you make those conscious decisions so when do producers get hard so small teams this is a big thing that's going on with a lot of my former colleagues now Delta pop captain Bungie there's folks are spinning off and starting their own studios they're super happy to be working with a small group of like-minded people they have history and shared communication communication is easy you know what other people are thinking you've already agreed on your values still it's hard to get five people on the same page if you've been in a relationship with someone it's hard to get two people on the same page often so five people still a challenge but the short cycle of communication they sort of trust the history that you've built up with people a lot doesn't have to be said and in theory you're comfortable enough to say important things to each

other so short cycle is a quick error correction you can get away with it so things are going great presumably you've got more money you hire more people you can do more work the scope of your game increases maybe the revenue projections of your game increases this is fantastic then you reach this point where there's I think inherent limitations to communication within the team structure when a team scales there's a few things that you can probably know about Dunbar's number 150 is the maximum number of people that you can maintain a stable social relationship with beyond that you forget who they are and you more importantly maybe lack empathy for what they are doing one of the things I learned even at Bungie arguably pound-for-pound where the most talented development studios in the absence of information people assume incompetence I don't know what they're doing they must be screwing it up there's another number that that

comes off often if you've ever tried to have a group conversation of more than five people you know what happens either someone stops speaking up or the conversation splinters because your brain only sort of we're not too far removed from primate socialization our brain can only track about five conversations that five people talking at once and once it exceeds that number you start to focus so communication breaks down this is you can next time you go to a party tonight watch it happen you probably know why you know what I'm talking about and one of the reasons for small meetings is conversations are hard after five people so people are communicating you've probably heard this features are late engineers are complaining about randomization I didn't know that we're supposed to do this this is not the highest priority designers don't see their systems live until it's too late how come the engineer didn't talk to me before you built this he totally got this wrong and the business guys would being to wonder when you're gonna ship your game this is often when a producer comes in experienced teams will hire

producer earlier before they reaches crisis State in fact one of the one of some of my colleagues formed a studio Adam Jack in Seattle and they brought on a producer before they reached this point of point of chaos because people who've been through this process know it takes energy to rally a team around product goal so the producer spends most of their time on the to-do list of the of the team in the game people call this the backlog it's really a big fancy to-do list it's a thing in Excel or hand soft or whatever you want to use but it's incredibly powerful because I think it encapsulates all the work a producer does the scheduling the prioritization the conflict resolution all of that gets wrapped up into creation of this artifact it's all the known work you know how to do this also lists represent some of the issues that you talk you hear about in game development crunch

culture we see this on a lot of listservs that I'm on people decry crunch culture and yet they play games like last of us that were built in crunch culture and they're fantastic is it good is it bad is it necessary how do you mitigate this and it comes from the list of work you generate you create a list it's a big list if the team is incapable of doing it and in under normal hours things have to change right so the the this is also an area where I think producers can really fall into a significant trap where your design by schedule if you control the schedule you control in theory priority if you control priority you control the aspects of the design you don't want to do that because you think you're being all sly and like oh I'm gonna get my thing on the list but everyone knows what you're doing and and people don't like it they want they won't understand that the process is transparent and you were your steward and a shepherd of the project and there's a time to interject your opinion so how do you sort of build a to-do list that is rational fair

transparent this is the thing that I want to talk about today how you manage your own to-do list when you create the team's list this is what allows you to be effective as a producer the backlog is your responsibility and that's the thing you most that you have to take most seriously so I think often when you start as a producer you went to an environment that has habit already in patterns so it's easy to follow the things you're supposed to do when I would got to Bungie they showed me the tools the template how they like to track their work and you just follow it for a while you it's new to you you'll probably have to figure it out and it varies from Studio to studio like what a studio but what a an executive producer does at PopCap is very different than what executive producer does it Bunji so it's simpler to make that transition you'd have some acclamation time but when you settle in you need to think

about why you're doing these things you don't follow your process blindly you think about why you're going through all these steps there's a constant evaluation of this why are you building a burndown chart it takes time you have to collect the data you've got to crunch the numbers you got to talk about it you've got to react to it why do you need to plan down to a really granular level how important is this what is it trying to solve so my talk is Starr built into three things useful cliches these sort of guiding principles that I've heard that have affected the way I think about production the things I do that try to make sense of the cliches and make them actionable and things I've read that have really also profoundly affected the way I think about producing teams so the cliche is a really useful starting point my dirty

little secret is I went to law school and I know it's funny to have a business guys a producer but I was a nerd before that there were there are things we talked about in law school about the community of people that enforce laws you have police officers you have lawyers you have judges and each of them approaches their problem they're asked they're their problem set in this continuum of law enforcement in a different way police officers generally default to controlling a situation they don't care who did what they don't care if you're guilty or innocent it's not the time they want to get control and find out who's involved lawyers come in after that usually we ask a lot of questions we want to analyze the situation we ask hard questions we're rewarded for asking hard questions we want understand both sides we will understand all the possibilities and the judges take all of it and make a decision they're deciding they're deciders they hear the facts this is how you do it now I say this because it sort of is my own bias about how I view production I was a lawyer so I like to ask questions I like to understand why

things work and I think by asking those questions that reminds us of the essential reasons for what we are doing and why we're doing it so my first quote is my first cliche I think is from General slash President Eisenhower plans are worthless but planning is everything my second quote George Patton General George Patton a good plan violently executed now is better than a perfect plan next she also was quoted saying a good solution applied with vigor now is better than perfect solution apply ten minutes later I think it says probably something about me that the first two people I quoted were generals it probably fits my myers-briggs profile there was little more touchy-feely Richard Carlson wrote a book are thinking the 70s or 80s don't sweat the small stuff and it's all small stuff I think this is really powerful I disagree that it's not all small stuff because your game has a ship and it's not built on small stuff but this is an important

thing to remember don't sweat the small stuff Robert Greenleaf also wrote a self-help book and he brought the term servant leader back into some modern usage the servant leader is servant first this reminds me constantly that producers are overhead you are a support function like QA like your office manager I used to say that I only have influence in so far as my leads on my team invested me with influence bad games come from bad communication I actually had an argument about this during a job interview with a head of production at a studio it is a producer centric view of the problem of let's not ship bad games I think an engineer would approach this problem differently I think a design order purchase would explain this differently but I believe that this is defendable as the root cause of why games are bad if you assume the teams are generally competent and ambitious and everyone wants to do the right thing for their project so we have these cliches or

these these truisms there I think of them as fundamental principles how do you translate this into organizing your day so let's start with my favorite one plans are worthless what planning is everything this is your most important job this is the most probably time-consuming of your jobs we should do it every Wednesday or Thursday and PBZ to the leads would read it because I dragged them in for hours and and walk through the work very important I mean it is the most important thing to do and yet by definition the end result the artifact you generate is is sort of futility it's like you Sisyphus rolling the rock up the hill because the painful truth is you throw away the plan you build this plan you work for a couple weeks or three weeks and you realize you didn't achieve your plan I tend to pretty philosophical about these things because it's the only way that I can stop myself from grinding my teeth at night I think about monks

who are making you know they take colored sand and make the intricate patterns like sand mandalas they spend all this energy and they create this thing of beauty and the wind comes and it blows it away why is this true because very rarely despite your best efforts does even two weeks go exactly according to plan lots happen right you know I mean everyone here has seen it found work emergencies people get sick people finish it faster than they thought they would it takes longer dependencies outside your team are affecting you these happen and I think the more you are willing to let it go for less bound by your your plan you were if you repeat this pattern plan execute throw away plan execute throw away you do this predictably and consistently that's your process people talk about production process a lot that's your process the the low-side is is its lead to the typical question

what's the best process we all want to know what the most efficient way of solving problems are there's a lot of nuance to these things Waterfall scrum lean Kanban all these things are true and useful do people know the difference between a complicated problem and a complex problem so this is important thing to remember these things are different complicated problems are things with lots of moving parts let me give you an example putting together a car is a complicated problem you put out a lot of stuff you give me the tool you give you the manual I have no idea how to do it that being said none nothing in that process is unknown we know it all like there is a book there is a way to do it someone does it some machines do it every day complicated problem a complex problem is to quote Rumsfeld it's the unknown unknowns you're trying to solve things you don't you know yeah you don't know the answer to and I think that that's a thing you you want to keep in mind the difference

between complicated problems and complex problems and think about your best process that being said this question I believe is a red herring the question isn't what the best process is necessarily it's why do you have a process at all the the the process of that I think about is a structure you can rely on things what you can rely on when things get crazy they deliver goals to you that you can think about and I think again they got by the sports story I had a friend of mine used to race bikes and he was very good and he was in Philadelphia and Julius Erving the famous basketball player used to have this thing for athletes and his basketball court unsurprisingly and he would shoot three-pointers all day I mean anyone who was old enough to remember dr. J he couldn't hit three-pointers during games but all day he was hitting it from from downtown and my friend the bike racer I was like hey you're so good how come you don't do this in a game and he said you tried doing this with Larry Bird in your Jersey it's hard but the reason why he practiced it was to do it under pressure so he could take the shot if he wanted

to and that's the sort of deliberate practice part about and and what process is designed you repeat it you do it and when things get hairy you rely on it so I think the answer the real answer to this question is the best processes the among the team buys into I think it's fair to say that developers are generally suspicious of process they see it as a set of rules that gets in the way of work they want to start typing they want start making the art they wants to make in the game they see meetings they see stand-ups they see the arguments between teams team members and it drives them crazy your job is to get them to believe in the process even if it isn't the one you think should work because you may be wrong actually and when you have its process - the team buys in - even if it's waterfall and you think it's not going to work you have a starting point and the starting point is what you need for iteration you can iterate based on your own experiences in the cut and the sort of character of the team and their own temperament but you

need a starting point the thing I tend to do is make a lot of suggestions hey I think we should try to do it this way and if the team doesn't want to do it you let them feel the pain of the decisions so it puts a little bit of a short-term deliverables at risk but I think it's a well worth it let's say your team doesn't track work as granular as you want they don't want to do stand-ups every day can we do every other day what happens you know when something variably happens on the day's you don't meet and things get dropped and missed and then the team will be much more likely to hear your suggestions when they know there's a problem they want the solution and you should be able to provide them suggestions I actually is inside I have a Pina but the best process unsurprisingly I think it's the one that aligns closest with game development and complex problems consistent we evaluation is really important because we're trying to build something that's fun and no one can really define fun until you play it I think you want protect the team from meddling this is that everybody's a

designer syndrome and I think the thing that does this most is agile and scrum for these two reasons interactions and individuals over processing tools and responding to change over following a plan this reminds me not to be rigid about the process it I think it aligns mostly with most well with how games are made although not perfectly I think games has this constant pressure of delivering a promise feature set on a schedule hard deadlines and unmovable dates and agile is really about potentially skirting around some of that and scrum has that you know once your sprint begins don't in inject new work and that is an easy way to keep people from meddling with the team's work so Jason was a former a colleague of mine at Harmonix new said this which I really appreciate there is no process which cannot be made ineffective by following it too closely producers myself included tend to hold on to their process which can be a good thing I think you want to

perpetuate good habits in times of stress but this is also a dangerous thing when the process is no longer working and you're holding on to it because it's your process you're the producer you should own the process and you can look at even some of the message boards on agile and scrum and these zealots who dismiss alterations to the one true way even though their whole manifest to be flexible you can't hold on to your process too tightly so this leads to this idea of weary evaluation we refactoring this happens to your game all the time to do this properly for a game you need a plan a backlog you need to do the work you need to think about how you succeeded against your plan I apply this to myself in a thing I started doing relatively recently and I keep a diary now a production diary of my personal thoughts I remember reading someone talking about

this on Facebook another producer who talked about how Trappist monks used to record their most important decisions of the day and why they made those decisions that keep the sort of diary of decision-making and I don't have the discipline of a Trappist monk but I try to keep a log now I have a little OneNote tab it says my diary and I put things in there that that hit me mistakes I've made in real time so there's a work went on and oculus we were given a lot of tight deadlines and public shows we scoped a bunch of work it seemed like too much work to me and it seemed vague but one other thing that's true about oculus is full of smart people you know what am I gonna to I mean not that I tell Mike a brash that he's wrong pulled smart people maybe they can do the work they've shipped big games they've done this before Mike I write they believe it I guess I should go along with it and it turns out that it had to do was too much work in it there was a lot of hidden stuff that came back and bit us in the ass and I went back to my diary and I'm like trust your instincts asked asked the questions and I think we're a younger I would have

read that to believe push back really hard at the time and maybe I tend to do that too much but I think you there's a way to have approached that problem differently ask questions figure out what work is if there's a question if if I'm on I'm fun unsettled about something explore it the worst thing that happens is I look like an idiot and like oh that's hobbyist Bernie this is super easy to do look this this and this great the best thing could happen is hey there's a lot of work here we hadn't thought about maybe we should consider so I write the stuff in my diary and I remember it and I still talk about today so once you write something it's it's it it stays with you differently so don't sweat the small stuff now this is not a an excuse not to be detail-oriented I think it's a fundamental entry condition of a producer to be detail-oriented you have

to understand all the details before you start dropping them you have to know what the small stuff is you have to know what the big stuff is and the small stuff for things like process specifics we've been talking about this a little detail plans and detail plans are really tempting because it gives you this illusion of control and knowledge I find these guys work down to the hour this is gonna be great attention of granularity do you believe how accurate you are the truth is you know you know this plan is not going to work it's never worked so where's your ROI where do you cut your losses the big stuff is this stuff you want to sweat good habits how the team responds to crises how how communication works on your team how accountable your team is to each other how critical you can be to each other about the work and progress and how your course correct this is all the big stuff and this is stuff you should sweat so how do you tell the difference it

occurred to me I was at Bungie and a bunch is very data-driven sort of a quantitative date of German culture is that we were in fact scientists we collect data on the state of the project at any given time data is very useful we talked about how it could avoid crunch and and choose the right set of work and I think a lot of places get caught up in measuring quantitative data burn down charts how fast are you fixing your bugs how fast are you finishing these features what percentage of Utah fishin see does your icees work at some some places track some sort of multiplier you're a point eight zero point seven five leads are point four because they've got to manage people and there's an essential truth in their leads probably can't be counted on for I see work the same way that I see Ken because he's been time managing so you know they're gonna be less efficient on a project I worked on people were talking about time estimation two hours four hours yeah it's a two-hour task now

it's a 4-hour task I will put down two hours because you think you're working on it you should know better these are all I think the the the important details that can be seductively misleading what are you measuring work efficiency is only one thing people morale faith and decisions how do you put that in the Excel spreadsheet so job to measure it so you're gonna have to figure that out but the I would argue that the failure from these unmeasurable qualitative things like faith and belief in a project or a feature can overwhelm any any granular planning errors you check I'll give you an example a studio had Specht out a feature past concept went to production it was a very expensive asset production pipeline green all the way check it's good we're on target reach the end see the final thing and the creative

leadership was like this is socks this is no good we're gonna go we gotta throw it all away so yes the producer on the project things were going well like we hit our milestones but the producer centric lens of that I would use to say the producer did not or was not empowered to raise all the qualitative issues that they had found because if you'd found this earlier in our but the probably findable way before it actually hits a real production we would have not spent millions of dollars on this particular feature so science is a good metaphor we have theories which are operating assumptions based on data it's a theory of evolution it's a theory of gravity we don't need to know all the details to know that this is not this is an accurate theory I'm gonna go back to the point of backlog being the known work being a hundred percent accurate knowing all the

work is impossible well there's one way to know all what exactly what work is in any given period it's to actually do the work so chasing accuracy at some point gives diminishing returns I accept that my goal is not to define all the work but do enough to give the team confidence to act and this leads into my next cliche a good plan violently executed now is better than the perfect plan next week another one I think another good cliche which I almost uses don't let the perfect be the enemy of the good I had a friend a friend of mine a colleague who just recently left the studio that was known for a very flat management structure to Amazon game studios and he finds it actually quite gratifying he says that they have this thing called biased towards action which I really like the idea that you want to act you don't want to think too much and that's why I think you need to embrace uncertainty don't wait for a plan to be perfect it doesn't mean don't be

rigorous you can define the amount of rigor you want to any given plan but don't wait for that perfect plan you embrace the uncertainty in planning you have to be comfortable with the fact that you're dealing with complex problems that don't have a clear solution yet I'm gonna quote another former pb2 colleague of mine our lead designer and I squeeze them out of schedule once and he said to me Bernie you're forcing me to get it right the first time and he turned around and he walked away it wasn't mad at me I don't know I don't think and and I remember that vividly I mean of all in all the moments of working on PBZ - that's one of them I realized that I was limiting his effectiveness as a designer I was forcing him to be conservative I was forcing him to get something to ship and while I think he understood that we were on a tight schedule and that has that happens that shouldn't be my default you

have to embrace the uncertainty of that process the hardest problems you face will have uncertain answers that are not scheduled and you'll have to embrace the sort of duality of a scheduled and unscheduled will work that is really kind of what makes making games hard and what make what makes making games great this little brings to the the next cliche about servant leadership this falls into the idea that uncertainty means as a producer you don't have to have all the answers and the irony is even if you do have the answers sometimes when you dictate them to the team you'll have sabotage the outcome your team should derive the answers themselves while this was brought up in a sort of self-help book in the seventies it has its origin and the Tate touching and I'll read you the translation that I find really useful the highest type of ruler is one whose existence that people are barely aware next comes the one whom they love in

this spot and praise next comes one whom they fear and next comes one whom they despise and defy probably a lot of producers fall into the last two categories fear despise defy I hope I get the fear and love and praise I don't think I've reached any of the higher levels of this but this is true so everyone here the chicken you know the chicken Pig project-management story to joke right well so I remember doing an interview at a studio and some of the feedback that came back to me was Bernie talks about him and the team almost as separate things a lot and it concerned them because you know you're you'd be on the team why do you consider yourself separate that's how it perceived and and I I stand by that this is the joke

so producers or chickens we lay the eggs but our skin isn't on the line you're involved in it you're part of the outcome there's no question that your your contribution is in the shipping product but your you're not the bacon people are doing the typing and doing the Cintiq stuff they're doing that they're make their the bacon they're the pigs in this and that's why I think it's actually really important to resist the urge to prescribe action so when I go to my day I think about how I I want to frame these issues for people I try to present data and options and I may have the right option and you think I'm saving everyone time like we could all talk about this we just do the thing that I know is right but the team will remember not necessarily the outcome but they'll remember that it was your option and not their option I don't do this very well all the time but people in audience probably know that but there was a thing I did once that was really proud of we work on PVC - when we had a pretty big milestone coming up and we'd

planned all this work and it was really important not to miss a feature because it's a and we've got to hit these things and and it's important I'm not going to trivialize it by saying it's just da we we have to keep to a schedule we hit a date and we put up on almost like 2x the work of the hours available or something like that and we had to get it done and I we put up the cards on the board we put up the time estimates I ran through the math with everyone it's like 35 people sitting in the big team area I'm like okay we have all this work and we hold of time and then I stopped talking and it was really uncomfortable I stood there I felt like I'm hours but it was you know probably 10 seconds and I think the team was expecting the oh my god Bernie's good tell us a crunch she's gonna go get pies for everybody or whatever it is and and and make us work through the weekend I didn't say anything because it really was so far beyond the realm of what I thought was even feasible to ask for I didn't say anything and I remember Joe solla one of our engineers probably one of our real leaders on that engineering team came up

and took a card down and said what does this really mean and the designer started talking and they started breaking it up I mean it's some of the some of the issues were we didn't think a lot of his work was parallelizable on a team but Joe took it down and he applied more rigor to it than I would have and probably more than you would normally want in a planning process because we had this problem and all the engineers would have build up and they started talking to these processes they started cake ripping up the cards and writing different ones and they started load-balancing their work and I think it was a sprint where we hit our goals we didn't finish all the work but at the end we were happy with what we did I wish I'd done that more often and that's why I think it's useful to remind myself of this so the end state of your production values is this sort of idea that if you resolve the conflicts and you get people on the same page and you have clear priorities these are the things were doing on there and a daily basis it's a little scary for your job security the best producers want to ups elite themselves they want to get their

team into a state where they don't have problems and don't need you it's a little unsettling things can go well I mean people talk about production and all these horror stories in general I thought PBZ for instance and things went pretty well we we had a plan we executed to it we dodged some bullets we we shipped a game and that we were proud of so things can go well and when things go well I think this is actually true for producers you feel kind of useless you feel kind of unproductive everyone's banging away their stuff they're happy even when things are are problematic and there's a plan they're executing on it executing on it you kind of sit back and you know you play the build and you talk to folks you feel like you're not being you're not checking anything to perforce therefore you're not useful you'll have a slate I think my current boss Laura fiers tells me that there's an optimum line of efficiency for producers and a good producer will always veer towards the pushy ineffective pushy and effective and when she told me that I liked I felt like a weight was lifted

off me because I feel that way so my point my my advice here is to resist the urge to meddle don't ask too many questions when things are going well go home you know if you're a good producer you're probably there late you should go home and I also remind you that watching and listening is actually doing something it's passive its watchful but it is it is still doing something don't worry when things go well they only go well for so long okay I think this is my last my last cliche that games from bad comes from bad communication so I had this interview with a friend of mine now I had a production at a big studio and we talked about this and I think he health communication was a soft skill some people understand the difference between soft skills hard skills is sort of the technical aspects of being a producer you know create the work you're gonna track the work I'm gonna check it off you're gonna check in with people you're gonna see what the risks are

these are all expressible I get arguably an Excel spreadsheet the soft skills stuff is how you deal with people and how you talk to them and how you understand what they really are feeling and I believe this is a false dichotomy actually I disagree with him then and I he still gave me a job offer which is good but um and I disagree from now because as I understand the hard skills it's all about communication right that the task list that your your check ins your worksheets how much hours you've allocated what your you know what your overage is these are all about communicating problems to people that in theory can do something about it all the soft skills stuff is about communication to is its understanding are you bought in its featured you understood have any questions do have any doubts about what we're doing I say that every team has an or you know somebody who's super negative and I'm going wrong and that's my favorite person on the team because in 70% of what that person is saying is is usually just sort of awareness and 30% is on my god he's the canary in the coal mine I must listen to

him so I take on the I hear although the the paranoia and fear and I picked the things out of it that I think are worth following up and I follow up on them so when you're the end of my talk there are things that I think people want to do about learning about production it's unfortunate because there are you know that I use the baseball or the cycling analogy and these are areas where you get to practice a shit-ton before you go out on the field and do it you know you have a job you don't get a chance to practice any of this you're on the field every day and you have to figure out how to learn about your craft so books you might be tempted to read and I think they're all worth reading you probably read them mythical man-month and peoplesoft is another one i learned things like how interruptions break productivity and set you back hours potentially for a small interruption rapid development agile game development scrum these are all useful books dynamics of software development these are all worth reading and you probably know them let me suggest other books

which i think are probably more useful these four books have have profoundly affected the way I think about my work and I struggle to put them into practice science a fear by Daniel Gardner is about book about cognitive bias it's about how we make shitty decisions when we think we're making good ones the two obvious ones - cognitive biases or confirmation bias people here and they take data that reaffirms their worldview and they reject data that contradicts their worldview and as I said about befriending the ER on my team I want to hear the contradictions to the worldview if I think things are going well and I'm kind of the least domain expert of all the different different disciplines on the team if I think things are going well I want to hear that stuff the other one is if those were parents the availability heuristic is another cognitive bias when you hear about a child kidnapping you think oh my god my kid is going to be kidnapped because these events are so powerful it excuse

your sense of probability and likelihood the second book is a book called numeracy it talks about how as a society we are mathematically illiterate and I don't want to undersell the value of production data quantitative production data is super useful and understanding numbers is super useful and paulus talks about two examples which really struck in my head he draws up he takes a student's I chose a time line on our blackboard he says a number line zero or zero a billion draw where a million is most people put it like a third of the way there because they don't know I mean numbers that's why I have scientific notation people don't can't understand numbers the other really great example that he talks about is the the three Doors goat probability problem so three doors two doors have goats one door is a car you pick a door all right to see you choose door 1 the game show host says okay I'm going to flip over one of these that's a goat flips over real estate or 3 do you change what's your probability you have

two closed doors what's your probability do you change your choice or do you keep it the same the answer is you of course you change your choice because now the probability has changed the probability of your first choice is your 33 percent right the other two doors or sixty-six percent accuracy you've already immolated eliminated one of them so it's 60% 66% likely that the second door is the car and only 33 percent likely that the first door is the car it's completely counterintuitive I was a pretty good math student as a kid couldn't figure this out like that's 5050 how can that be but if you actually run through simulations of this he's exactly right sixty-six percent and that's a significant difference in in probability the third book is don't think of an elephant by George Lake off it's a left-leaning democrat strip strategy book and if your politics don't align that way you should bite your lip and read it anyway it's about how the Republican Party in the in the eighties reinvented their brand and framed issues

in a different way to make it popular for people compassionate conservatism thousand points of light all this stuff and this is the canonical example is like do you want to save thirty three percent of people or you want to let sixty six percent of the people die I want to save thirty three percent of the people right it's how you frame that question even though they're functionally the same same outcome different framing thanks for the feedback by Stone and keen is a book I just started reading because I think you are servant leader how you receive feedback is really critical you will get feedback from all your leads and your team some of it will be valid some of them would not be valid and feedback I mean people have a hard time unit even accepting good feedback you know no is nothing really I'm in negative feedback is even harder because you're usually put on the defensive I'm guilty of that sometimes I think we all are but how you

receive it is critical in in growing as a producer and how you push back as critter helping a person giving feedback grow it's an art it's something to think about and I think this is all these are all well worth reading someone else was suggested predictably irrational which is a book that allow for you to play people love read because people make all sorts of weird behavioral economics decisions when purchasing free-to-play goods but I haven't finished it so um I didn't put on the list but it's also worth reading so I'll sum up saying production is sort of this invisible craft right I was at a game board night with some valve people and they're like I'm a programmer of course you are what what are you you know what do you what do you do Bernie I'm like I'm a producer they all took one step back like oh so it's pretty fair to say I think that that there we laughed about it and production really varies you know by discipline you've been art producer may be different the design producer it varies my project team the pz2 team was

different in the Peggle to team destiny is different than then halo and named by studio right producer sort of go into a studio with no portfolio so one of the people actually hired me at PopCap was here and he could only well I had nothing to show him I if you're an artist you know you have very concrete things to show off you look at a portfolio one of the great things about the team I'm working on now is I'm learning a lot about what makes a good animator it is when they pointed out as very obvious what makes a good animator engineers also maybe not have code samples but they can walk through technical Sol's they can talk about systems they authored or claim they authored on games and and designer stuff that can do the same thing you go in with that with nothing and that's something you have to you have to live with and embrace that every team is a time you have to prove yourself don't forget that so I want to thank people for the feedback all the teams have worked on especially in the last few

years at PopCap and Bungie have taught me innumerable things about production I've learned more in the last three years then I have the rest of the time in the game industry Richard had me give a talk at PAX Brian Laura are people I work with now and they really talk they give me feedback on this talk I ran this through with Mike so Dhin and mark Scouter good I've stolen ideas from all of you and that's okay because I've credited you and to you thank you I the act of actually writing this talk has reminded me the things I need to remember we all get caught up in how we build games and hitting deadlines and we don't think enough about what we're doing and why we're doing it I read somewhere that the art of the act of talking about a problem and then actually writing it down changes the neurochemical out outcome of your brain and it impacts your memory differently and the after writing this talk has helped me redefine some of the things that I've been thinking about so thank you for coming that's it so I've time for questions

and won't have any questions you come talk to me afterwards yeah sure sure yeah I think it's always really good I think that's an area actually I sometimes so the question is what are positive meddling when your team hits a milestone they've ground through something hard do you want a medal of course I don't I wouldn't call that meddling I think that that's rewarding people and recognizing their effort meddling I think is is is too many cooks in the kitchen sort of thing right but the idea to let the team work and know when to back off and it's hard because I would imagine most

producers here are pretty assertive and they want to help fix things and we're problem solvers and we want to get in there and prove that we're worth the head count that's the kind of meddling I'm talking about I think rewarding a team and it's actually something I think I wish I were better at and I've had managers who have been really good at recognizing work PopCap used to have a thing where they would give a $100 gift certificate to people who really shown exceptional leadership and effort and you could nominate anybody on the team for that so those are things that I think a really valuable in a team culture people like to be thanked they'd like to be recognized they don't need money or bonuses all that is good just the recognition in front of your team is great I we used to do a sprint demo at PVCC - and we used to at the end of the week every two weeks we'd get everyone in front of the monitors and we'd run through every one everyone worked on and I was worried that people would see me think it was cheesy but after everyone's demo they would clap and I think people were really into it like they were really proud of their work even the kind of emergently

engineers like yeah but they loved it like they'd show off their work so I think a recognition is super important any other questions yes sort of get wrapped up with the role of team leader and I was just wondering how you felt the sort of in-depth or almost excessive domain knowledge of some areas sort of interact with that role it's interesting I when I got to PBZ - there are two people I want her in the trust of right away it was Ally designer and lead engine here I don't want to say that no one else was important they were all important I love you all my children but those are the two people I want to earn the trust of right away because that was the person who told us what we were doing to do and how we were gonna do it so in that sense being a leader really

means about earning their trust and letting you letting them trust you to speak for them on small teams I think that's equally true and you have to be comfortable with the fact that you don't have domain knowledge over everything I mean I had opinions about design and sometimes I even had the relevant insights about engineering but they were I'm clearly neither of those things so on small teams or large teams you still have to you have still have to earn that trust people will look at you as an authority figure because you're the sort of repository of this backlog you have a list you in theory are thinking about dates and all the things that the team shouldn't be worried about Jason booth said also never do something that you can let a producer do which is which is true actually so even on small teams I think that's even small teams require even more because there's there's more multiple is that that's true and I think

that's also one of the reasons why it's important to build relationships with multiple leads on the team I had none I have none of those backgrounds I mean I was a programmer as a kid and and did none of you know I drew a little bit but I'm not an artist I'm not a programmer I did a little testing but I'm not a QA guy so I was pretty neutral and I was very utilitarian about the relationships I needed to rely on first if you're an artist and you're a producer I think that's a that's a bias that you have to worry you have to work against your own cognitive bias of I tend to see things in my own worldview and you have to work to make sure you hear things that are not in your worldview so having a relationship between yourself and disciplines that aren't in your wheelhouse is probably extra for them so if that's your case it's been I'd tell that person who spent a

lot of time with the design and engineering leads yes any other questions yes sir I had a question just with your background and working with experienced developers you know guys that are working gaming three four you know ten years or something taking their feedback with how you're running your process on a specific project and you know they might have a lot of opinions and how they want to run the project but they don't really want to take the time away from their work to like some of the meetings and stuff like that just curious about your experience with situations that's the view is good from the cheap seats problem I think it's important to to be gracefully accepting of that feedback understand that there are things that they think are maybe not addressed by what you're doing maybe their solution isn't the right solution and that's the part about accepting feedback that is really personal because it feels like your domain is being encroached on I mean I got into an

argument in public on one of my dev teams with an engineer who argued with me about a process and I regret doing it in public I mean that was not a cool thing and I spend a lot of time with him trying to figure out what his main concerns were and its main concerns where I don't like being told what to do and when to do it so if I understood so he understood that I had a much better working relationship with him so it's often not the main thing that they're talking about like hey you should do it this way you should get it the underlying issue underlying issue was they didn't want to be scheduled so they were put on work that wasn't his mission critical and that worked out okay but I understood that they didn't like being held accountable to schedules yes hi I was wondering if you have any tips for and when we get into crunch mode I find sometimes team members can get Debbie tips for managing crunch mode and keeping your team motivated so I think the the thing we did when we crunched on

on bbc2 I remember in fact our lead producers in the room we went in a room and we we really went over all the war and we spend a lot of time cutting things and it was really actually useful for me to have someone above me to come and say nope is that really important like I was so close to the work I had a hard time letting go of things and that happens also so we spent a lot of time Mohan and Alan and I going through a list of work and really whittling it down to the point where everyone was really unhappy you know Mohan walked out of there being harsh and we cut all this stuff and this would have been great so um you know they said in law like a good settlement is where both parties walk away and happy like we really cut stuff down and only then do we bring the whole team in to look at the work and some of the work people refuse to let go of things that were cut some developers just took it personally and said I'm gonna do it anyway that happened a few times on our team so I think you you have to let them understand the goal the deadlines and

that you as leadership have done everything you can to trim the work down to a manageable point anything else like you can pull chairs off of a you can pull legs off a chair but when you hit three you can't really take a leg away so we were down to three legs this is the last stable thing we have if they trust you've done that and you crunch I think the team feels a lot better and I think the difference between a crunch and a death march is a crunch has a targeted goal like I want to finish these three things a death march is is sort of interminable I'm gonna work until I fall over and that drives people crazy I think when people have clear goals that they can get to that's achievable not impossible the team is much more likely to rally around that than just work you know don't you know the EA spouse thing leave that you know 11 p.m. or 9:00 to 11:00 or your core hours or something that stuff is is is really morale breaking I think the good crunches is team generated we're gonna do this I can't refuse to let the game ship without these things we're gonna

take it on externally driven crunch is really hard to mitigate the morale impact you can lessen it but it's hard to mitigate that impact yeah wondering if you could explain a little bit how you find that fine line of balancing your concerns with what they're saying which is probably very real with them bringing the entire team down because like one of the things I had learned throughout my personal experience in animation and games is that negativity can be a real yeah your team but at the same time you want to pay attention to that because a lot of those fears are very real a lot of things we talk about is on our team leads especially should never be negative in public we often talk and to each other about oh my god this is terrible I can't believe we're doing this thing but you can't present those doubts to the team because the team needs to be focused and locked down I think that your is it's one of those

it's dark episode with the empath used to take on the pain of the other person and let them go take their pain away and and take it in I think that that's the thing you've got to do with these yours you've got it they've got to know that they can come to you this is the therapists role of being a producer talk to you about their concerns and their fears your job is to not fan them but to think about them and listen to them I mean the act of listening and taking them seriously is a super valuable and ultimately it's it's a thing for you to go through and see well what did these fears are founded and in general I give wide latitude to the domain expertise of people if a tech artist who's got to implement all the stuff coming together is concerned about something I'm gonna be concerned about it because that's their work on the line they're there they're the pig quite literally and there you know audio is like that too they come at the end and they see everything so that's how I would deal with it anyway I'm getting a time cut you come talk to me afterwards thanks

again for coming I really appreciate it [Applause] you