[Music] makes noise and reply to the survey when you get it in the mail wow that's super loud all right I'm gonna talk about technical direction um some of you may have heard that if we say that if you're expecting programming talk you will be disappointed because that's not at all what we'll be talking about today so my name is Mike Acton I'm the intern director at insomniac games you can tweet me there Mike underscore Acton so what am I talking about why am I talking about this I'm not going to be really saying anything new there's you know I don't know of a real breakthrough in you know technical leadership will work human communication that's happened and say the last you
know five thousand years so I'll really only be talking from my experience and my perspective on the problems so this is this is what I've learned and the things that that I think are important so what is my experience in this particular case I've been the Indian director at insomniac games for a little more than 10 years which I think is long enough to have both have seen the problems try to tackle them and seen them through to the end which means that I've seen the results of the things that I've done I've seen the mistakes that I've made I've seen the impact of what I've done I've been able to see how I've you know how all that stuff easy they're falling apart or worked or not so I think that's valuable experience I've had to live with those decisions so why you know why am I talking about this I think is this a very hard subject to talk about I don't know you know in terms of us sitting here and discussing this topic I don't know where if we're
on the same page when we mean leadership on mean technical direction well you know when we're talking about teams so it's hard to even have the sort of the same the a shared vocabulary on the subject and there's a lot of things that are you know that I might say that it sound like cliches assume you know super obvious you know you should you should spend time with your team you should have one-on-ones like this is all stuff I think everybody knows but the gap between knowing something and the practice of doing it every day is often very very wide and that's partially when we talk about is just that practice that day-to-day practice this is the stuff that I've learned and sort of dealing with that gap between obvious and practice is what really what I want to talk about so when I proposed this talk last year one of the pieces of feedback that I got from the GDC committed GDC committee is when you often often when you talk about leadership you're not giving a clear takeaway the audience wants something clear to take away from
your talk here you go here's your easy to remember take away from my talk today hex nine nine nine nine nine zero moving on so what does it mean for what does it mean to me to manage technical direction in an unnecessary form we will say the five C's confidence costs commitment conflict cooperation and all those things depend on context so I'll be talking about you know how I'm what what it means to me to manage each one of these things in terms of context this is really what I want to talk about and that's I wanted to start with providing an example of what I mean by each one of these things what does confidence mean to me what does cost mean to me I want to talk about the risk profile and how I evaluate that what about each one of
these things is hard for me personally what may be hard for you is different and what I focus on in terms of training each one of these things so let's get right into it so we'll go through the examples of each one of these what it means to me and my personal rules of thumb confidence so in terms of confidence what I mean is you've certainly heard this at some point in your career somebody has said p.m. or the producer or somebody or my manager is making unrealistic schedules and it's been really upset about that I wanna talk about visuals and how I view them schedules the only thing that schedules are for is about building confidence that's the purpose of a schedule schedules are one tool to build confidence so what we do what we need to be doing is focusing on managing confidence not managing a schedule the only reason I make a schedule the only reason that I am asked for a schedule if
I'm dealing with a publisher or whatever is that somebody somewhere can have confidence that we can build the thing that we say that we're going to build that's the purpose of the schedule that's the tool so instead of focusing edge ool focus on confidence where are you not confident where are where are you confident what do you need to do to be confident one of the things that helps me to build confidence is what I call the 8050 rule which is if you are not 80% of the way done if you do not feel like you are 80% of the way done when you have used 50 percent of your resources you are way behind and I find this true the vast majority of the time and it's super helpful to you know in terms of practice for me talking about cost you almost certainly said or heard somebody say you can't know how long it's going to take a solve a problem that you haven't solved before so we can't possibly estimate the cost of solving this I'd like to suggest that
it's not the that's so much the problem it's the value if you don't know how much it's worth solving knowing how much it's going to cost to solve is not a meaningful number so you have to start here you want to start by sitting down with any particular problem that you want to solve and say how much is this worth solving if I spent two weeks on it would it be worth solving if I had to spend two years on it if I spent five years on if it took me 20 man years to solve this problem would it still be worth it whatever it is that's the where you have to start with or the cost is completely meaningless so along those lines you need you know I feel it it's important to have a cost profile for things like development versus research in general so for me for instance right now at the point in time it's about an 80/20 mix you have about 80 percent focus on development about 20% focused on research or and by research I mean problems in which you don't you don't know what the cost what the value or
cost profile is you're saying I don't maybe this is going to be valuable I don't know we're just going to explore this space and about 20% of your time mix in with various individuals or various projects spent on those kinds of problems in terms of development problems I feel it's important to have a rule of thumb on what your expected return is so for me that rule of thumb is 5 to 1 if we invest a day into a development problem I expect five days in return and that may be five days of production time that may five days of that individuals time saved through maintenance over the course of the next two years whatever but a five to one you know a five to one return is a good rule of thumb for me building versus buy this is all sort of always the perennial question and not just on the sort of engine scale but on the you know the individual the individual systems or individual feature scale how do you
decide when you're gonna build or when you're gonna buy and I suggest that this is always going to come up you're always going to have to deal with this question so you should have a function for dealing with this question it's not going to be surprised that at some point you're going to have to answer this question so for me function is about answering the question of whether or not we can create as a team a competitive advantage by knowing our context better than anyone else I think you know we look at ourselves as an engine team and as a tools team what we should be able to do is solve all problems better than anyone else we know what our production teams are doing we know al-qaida's games that we're making we know our studio better than anyone else and in fact if we cannot solve all problems better than you could solve them by taking something the shelf that's generic and doesn't have that content context we up like that that is we should have that competitive advantage right but look in terms of your studio and your problems like could I create a competitive advantage by knowing my studio better or
knowing our problem better if I can't do it then yeah buy it that's the point that's that's that's where the value is commitment so what I mean by this is starting with like somebody asked what can we do X whatever the X is and you'll you have either said or heard somebody said well it depends it depends on what the arts do but Art's doing animations doing you know all these there's a lot of variables it totally depends on all this stuff or you may answer well anything is possible right and I want to point out that there are always lots of eight variables like you will never ever be dealing with the problem weather isn't lots of variables so that's not an excuse to hedge you you cannot hedge in terms of or I find that it's it's problematic to hedge you know people don't want a probability table they don't want to say all right what's a percentage chance of each one of these options happening and sort of go through a probability cloud to figure out whether or not they should be they
should be responded they just want to know what they can plan around so you give them as a director your best guess right and you say this is what's going to happen it's understood that there's a lot of variables you do not have to excuse that every single time you speak but you want to ask yourself in terms of those probability tables in terms of that probability cloud what are you willing to stake your reputation and your job on because every single thing that you say every time you say every time I say we this will happen you're staking your reputation on that thing happening so be confident to going back to schedules figuring out a way to increase and improve your confidence is the thing that you're focusing on and I find it helpful to ask this question what would you be proud to say you did five years from now thinking forward you know these are the things that I want to do these are the things that are important to me these are the things I'm willing to stake my reputation on because this is what I really want to accomplish and to ask the same things of your team right also know that choices aren't for you're going to make a decision and that
decision is gonna stick but choices lasts way longer than you hope they will last and I think I found that 10 years is a pretty good bet you make a fundamental choice and it's gonna get spread around and it's gonna get into the code it's gonna get in the data and it's gonna have tools or whatever you're gonna build stuff on top of it okay there's no way you're gonna unravel it like whatever you're gonna do you're gonna live with that choice for ten years on a tray you're right some things last a little longer some things you can rewrite and fix but the ramifications of choices lasts way longer than you hope they will but they aren't forever right you're not you know you have all within that ten years you should have a chance to fix it if you screw it up conflict so it's hard to talk about conflict these days without talking about uber right so the question you can start with asking yourself is how do you not be like the uber and that's a question that I've you know been asking myself over the last few weeks right is you have this sort of
very toxic environment and you do not want to replicate that in your and but or at least would be personally that's not an environment that I want to replicate that's not the kind of thing that I'm looking for or let's say on a much smaller scale you have this kind of response where you know you have an individual that just doesn't want to work with somebody else because they you know they feel that they're just too abrasive or just not working well together so how do you deal with these kinds of situations or how do you deal with these conflicts how do I deal with it so for me it's important to put process in place to protect people on my team from my personal biases when they can when they conflict with my values ultimately my values are or what's going to be driving my team as a technical director listen these are my values this is this is how is how it's going to be but when things that I do conflict with my values I want some process to stop me
from doing that so I have I put things in place like you know the the leads are in charge of telling me when this is not working and they can basically outvote things like hiring practices right when my bias is showing through and I'm saying like this is not you know I don't think this is the right person but they're saying no you're wrong this is the right person put that process in place or that I don't think this person is ready to be a senior engine programmer and they're gonna tell me no you're wrong because of this and they have the opportunity to out vote me in that process I also feel like in order to solve for this kind of thing I need to represent the company well I'm in order to do that I need to know what the company stands for uh you know I think in in terms of you know if we're gonna sort of harken back to where it's the same sort of thing what are the values at the company what is it that I'm trying to represent and for insomniac in particular one of the things that's important to us is this phrase to be a force for good and so I have to think
about this when I think about the process I'm putting in place for my own team and in terms of the smaller conflicts it's important for me to remind myself that if there are you know if someone thinks there's a problem think with it there's a k imagine there's a K there someone thinks there's a problem there is a problem it is a real problem even if it's just a perception problem and I put Justin post there because that's a real problem and it's something that has to be dealt with immediately so anytime somebody says there's a problem you don't dismiss it just because they're technically wrong they you know they said that this person did this and I feel bad about it that person actually didn't do that it's not you know it doesn't matter it doesn't matter that the reality is different it matters that they feel a certain way and that they're having trouble with that and that needs to be resolved a question often comes up and I think in terms of technical action you need to answer this about what is accountability you lots of
people say people need to be more accountable okay well what do you mean by that I don't I don't know we should fire somebody so as a technical director right you need to have an answer for what accountability means to you and for me it means you have to be prepared to accept the cost to fix mistakes that affect other so when you make a mistake and then fix somebody else affects other people the studio whatever what's the cost you're going to pay for that and that may be the time I'm going to spend to unravel this and fix this and to work with people to make sure that it doesn't happen again whatever there is a cost and I'm willing to pay it in terms of conflict one of the things to watch out for constantly I find what I call conflict cockroaches these sort of insidious stubborn and very very hard to kill conflicts when someone you have people just sniping at each other over time or people just you
know being may be passive aggressive over email when you see these sort of small things this is the point in time when you really have to jump in and you have to kill it at its root as fast as possible or it's only going to get worse and is only going to last even longer cooperation so you may have heard or said it's just not working because they're not using the tool or engine or system correctly or I had to rewrite it because they couldn't tell me what they wanted stuff like that so I know that people will often say surprise it's good like we want to Oh we you know we want to over-deliver so we want to offer a surprise I'm gonna say and I'm here to say that in my experience surprise is very bad surprise the enemy you want things to be as boring as possible you want it to be clear you want it to be obvious and evident what you're doing you want to communicate you want people
you want people to know what's happening so every day I'm focused on trying to find a way to make something even more boring to find a way to look to eliminate surprise that's no button you know nobody can say I didn't know that that was happening there's still but no matter what you cannot eliminate surprise like there's always going to be things that people don't know there's always gonna be things that didn't work out communication pathways that you didn't you know you didn't know about whatever but just that constant vigilance and looking for ways to eliminate surprise I personally find helpful approach one of one of the big lessons I learned and say over the last 10 years is that about 80% of the thing is selling the thing it's not doing the thing it's not working on it's not building the feature it's selling the feature and by that I mean you know working with the team - you know that this is the right thing that we should be doing working with the production team - you know that they understand how it works that they want to use it I
think you know that that it will be built into the design that you can design around it whatever the situation is you know you spend most of your time you're gonna you spend most of your time selling the things that either you're going to be doing or you already have done and I think it's important to when you're doing this is to one know what people say they want which is not the same thing as what they want but they should you should absolutely know what they say they want and you should be able to paint a picture of the future so you say this is what it's going to look like when we can do this thing you should be able to articulate that and that hopes people to see where this is going in terms of the super boring and making things super boring I find it helpful to have a quarterly - yearly and five yearly roadmap at least a sketch out for people to know where things broadly are going I've also found it in
terms of cooperation super useful for every feature to have a user side champion so when you're building somebody building something find somebody who's among the people that will use it that will champion for that while you're building it while you know you can work with them while you're building it and then will go out and help other people learn that thing but always have a champion for the thing that you're building and again you can't over deliver in the scenario right there's your Olympic completely eliminating surprise you're working with somebody who will be will be the primary user of the thing that you that you're developing but you're going to be developing the correct thing because you're working with them so let's talk about risk profile and this is all about how I approach trade-offs in general for confidence so the question is okay if you have too much confidence what happens if you have too much confidence you're not doing anything interesting I can I know how to do all the things all these things that
we're doing in terms of real confidence not fake confidence right and I'm actually confident that we can do all these things so if I'm confident 100% we can absolutely do this we can do it in time we can do it on budget you're not doing anything interesting because the only way you have that level of confidence is you've done all this before and if you have too little confidence I'm not sure that we can do any of this then you're not getting you're not gonna be getting anything done in that process so how do you strike that balance how do I strike that balance so for me it's about three things one is like I said having my Rd profile so how much how much I'm focused on things where I know the cost value is worthwhile and how much am I focused on the things where I just don't know what the value is so for me that's about 8020 right now for others and might be different mix the second thing is shifting things to learning opportunities so finding things where some an individual is very supremely confident and the thing that they're working on and finding somebody who would be much less confident in the same task and giving them that so shifting
the the confidence profile down just by giving to somebody else was a chance to learn that thing which then opens up the first person to do something more potentially more interesting or something new and a focus on for monetization which is to say that find the things that we're always confident that we can do and let's get them completely off the table let's stop working on them forever if we're always confident it's always it's essentially wrote at that point then let's give this completely off the table let's figure out how we can get get rid of this from our profile so that may be okay we're going to buy middleware for this because we never we never want to deal with this again or it may be that we're just going to you know build this into a sandbox system that doesn't have a lot of dependencies it's essentially bullet proof for the next two years or whatever we never have to got it whatever the plan is what's the cost risk profile so in terms of you know we're spending too much money
you're obviously losing money you're not spending enough money you're losing an opportunity to make things better now granted I'm kind of making up the part where I have more money than I know how to spend that's non-experience that I've ever actually had but I assumed when I was making these that somebody maybe somewhere had had that experience so in terms of balancing cost what are the things that I find most useful one is triage and that's focus on everything on triage everything that comes across my desk everything that comes on the team that I'm aware of everything goes to retrieve process which is to look at it and decide you know is first of all is this worth solving at all and that's often not true great it's often true that you don't want to see you don't need to solve a problem somebody may say look this is sort of annoying if I you know if I have to go through these three clicks let's say a tool I have to go through these three clicks and it would be really great if I could only do two okay and we say great you do that
process once a week and you and three other people do that process once a week we could save you approximately two seconds and so if we add that up and over the course of the next five years we could save five minutes so unless we can make that bug unless we can solve that issue in less than one minute which seems super unlikely we're just not going to do it right that's the sort of process of thinking through things when we do triage or it may be just how much it's worth compared comparatively to other things right we have all these things that are higher value we're gonna this is going to fall this is gonna fall the floor and this is harder I think then people think the ability to say no we're not going to do this because we have other things that are more valuable is hard it's hard to say and it's hard to hear but it's absolutely necessary if you want to get the right stuff done another high-value item I
find process I find in balancing cost is in measuring the user experience so measure workflows measure what how long people spend doing things that you know give to give you a sense of what the value and costs of various things in production are what's worth solving well it's also super valuable for me in terms of just as I mentioned before just a ruthless editing and sort of saying this is not going to happen we need to get rid of this this it needs to be off the table we need to you know we need we always absolutely do need to do this and as I said that's really hard right people have a hard time hearing that and how to give that feedback to people to say no we're not going to fix the feature that you are really excited about because to be honest that whenever somebody submits an issue is important to them right it's always important to them or they wouldn't have submitted it in the first place and so they out they do want it solved and they're committed you know they have an investment at this point in that problem so you don't want
to dismiss it out of hand and you don't want them to feel like you know they wasted their effort in terms of submitting an issue so you do need to figure out how to how to communicate them that to them well but at the same time it does need to be cut commitment so if you over commit right you have your you're likely to burn yourself out or if you're not successful in your over commitment you're just going to be a long-term failure and whatever it is that you're trying to do if you under commit no one can work with you right because they don't know what you're going to do you're not committing to anything they have no idea how to work with you or they're going to fill the gap of the things that you're not committing to with their own implicit promises they're gonna say since you didn't say anything I'm just going to assume you're gonna do all the things that I think you you know that you're going to do which is often dangerous assumption right so how do i balance these two things one for me I much as
possible to about steady pressure on the team constant steady pressure not waves of pressure and that comes back down to that 8050 rule right just sort of constantly re-evaluating things we at the right stage are we spending enough time are you know are we where we think we should be letting the team team drive their commitments so this is about every individual on team saying what it is that you want to commit to what is it that you you feel that you can commit to and having that be driven and not be given to the team but still going through that process and reviewing all those commitments and being able to ultimately vetoing them if they don't work for either our direction or what's you are either that or a direction or a cost value ratio or whatever but having all those always be driven up on the team and the third thing that I find most helpful is always from my point of view providing problem and the value to solving that problem to the team and
never just the solution never just do this task but here's the problem that we want to solve and here's the value for solving it so it's worth solving it if we can solve it in less than two weeks it's worth solving if we can solve it in less than a month it's not worth solving it if it takes it longer than that so you know if you can come up with a solution in that space great if you can't we're gonna put it aside conflict so too much conflict right you have a toxic environment nobody can work with each other everybody hates each other not enough conflict you have no creative energy and no critical review everybody trying to be super nice to each other walking on eggshells and you can't you're not actually getting any critical critical review and the first time you hear about a problem is probably going to be on neo gas somewhere after you shift the game so how do i balance try to balance these two one I tried to survey the team constantly as often as I possibly can how do you know what do you
think how what how are you feeling what are the issues that you're dealing with that's both literal surveys so emails and things like that and in one-on-ones just keep constantly questioning what the environment is like and what you're dealing with the second thing that I find helpful is intra team so inside of our team review trying to get the team comfortable as much as possible with reviewing each other inside the team so that maybe mean on smaller groups dealing with Changmin Oh change lists on smaller groups and talking about their their designs and being super comfortable and being honest about those things or it may be in a broader sense it's for the whole core team is standing up once a week and doing a change this review in front of the whole team and having people be able to hear and talk about other people's work every week a third thing that I think is critical for at least for our team is having an untold unfiltered feedback firehose from the whole studio this is what everybody
thinks of everything that we're doing that's not always good right I'll tell you right now like in reality like there's stuff that people really don't like about what about the choices we make in about the things that we do and their frustrations and you know maybe bugs and the tools or whatever but that that fire hose is totally unfiltered everybody can see it and everybody can get comfortable with the fact that in fact we want all that feedback we want to know what people feel and what they're thinking and that's super helpful for us as a team and I think it helps you will relate to the rest of production cooperation too much cooperation and what you know you end up with design my committee and I know some people think that's probably a good thing but I'm not in that camp not enough cooperation and you have a bunch of pieces that don't fit together right you have a bunch of people building independent things they don't fit they're not working together so how do I
try to balance these things one is the practice of leadership and I think that's not just sort of that in terms of technical direction right it's not just the lead of the team but it's everyone on the team everyone on the team in my opinion needs to be a leader you need to be leading something so focusing on that as a practice what is it that you think is important what is it that you are champ you know being the champion of on our team from the most union programmer into the most senior programmer everyone needs to be leading something so from my point of view for every feature we have both the champion for and a champion of every feature somebody on our really wants to do this in something they found somebody in production who really wants it ideally and they can help work together to see it through all the way to the end into use in terms of cooperation as much as possible and while again this may seem super obvious I try to work backward from the
production schedule so and that may not just mean our game schedule right so I look at I can but it does often I look at the game and say what is the game one more accomplish win and so how you know how can we provide the right thing for the game at the appropriate time so the better schedule out the game is the better that I can schedule and it's often true that those things change over time so I adapt but it's also other production schedules so looking at say hardware releases and new consoles and whatever you just there's always some sort of synchronization points that you need to be working from and just paying attention to those things in the in the future over the next year the next two years the next five years what are these points that are going to happen that I need to deal with and start working backward from them now I wouldn't talk about the things that are hard for me in this spectrum and so what are my weaknesses in each one of these areas and how do I try to shore them up so in terms of building in terms of being
confident about the production and what we're doing for me the thing that's hardest is the scale of communication and by that I mean we can you know when you look across the studio I want every single person in the studio to have confidence in what we're doing to be able to say yes I believe that they can get done what they say they can get done but the problem with that is that every single person how do you give that person in confidence is unique to every single person you know the you know this one animator with this much experience with you know these particular systems is wants to have different information than this environment artist over here and so figuring out how to scale communication appropriately and how to get the individuals confident is hard for me personally so what I do so the one thing that I do is make sure that the leads on my team know the messaging these are the things that I think are important for people to know so that when they're out and about and
they're talking to various teams that they can communicate those things and they often do that better than I do so having uh you know having people prepared to give the same message that I would give but in a way that's better than I might give it helps me too so delegation basically helps me to shore up some of the my weaknesses there it's also I found in practice that it's way easier for people to react so if I say you know should we talk about this design now people are going to say yeah I'm really busy I can't really talk about that design now maybe next week and the next week comes lie and say should we talk about this design now no look at demo I bet this thing's I can't really talk about the design now maybe next week right that happens and people are really busy but if I say here's the design or we're going to do X this is what we're gonna do I say that people all of a sudden like no you can't do X I got this like I'm gonna stop right now I'm gonna talk about this right so I found that if you make commitments loud and early people are much more willing
to talk about those things because they'll see clearly concretely what it is that affects them so it's not a trick as much as it is the reality right the reality of the situation you want to be close you want to be loud and you want to be early so people have the chance to react and just all the one-on-ones so talking to everyone on my team as much as possible to share the messages of what I think is important but also across other teams I spend time on one-on-one with other people in other departments just try to spread the the individual messages as much as I possibly can what's hard for me in terms of cost for me the hardest thing are subjective measures of value how much is one millisecond of time worth in the game if you know if we spent a week to reach you know to reduce GPU by one millisecond would that be worth it if we spent five weeks to do is we've done six months doing it would it be worth it that figuring out what that number is in terms of how much is a millisecond worth is really hard
for me personally and in terms of individual frustration right I'm just frustrated I just you know I I I'm frustrated by this the extra third clicks that I have to do for no good reason right it doesn't cost us anything really in terms of workflow but I'm just frustrated by it so how much is that frustration really worth solving for so how do I battle this personally I start with again lots of surveys always asking questions send these out to production sends out to our team just keep constantly query about how how they feel about things and then I can sort of trying to turn the subjective measure into an objective measure well the general feeling has been this for a while but now it's getting worse so we should probably do something about that but I think the broadest approaches that I have for this or one is just to block out time and say here's here's a bunch of time we have for low-hanging fruit it's just like here's you know we're gonna spend two weeks on this stuff that
was essentially low value but is super super frustrating for people so how we can get this stuff off the table and a similar block of time for things like optimization like let's just make it as fast as we can in the next two weeks or whatever commitment what's hard for me in terms of commitment I think we would all agree that autonomy is important it's important for people on the team your whole team to be as autonomous as possible but the problem is you have people you almost certainly have people who will burnt themselves out given the opportunity and you will have people that will probably over commit given the opportunity will say oh well you know somebody will ask them can you do this thing let's say yeah that's probably easy we can probably do that so you have to I feel I find that you do have to manage that autonomy so for me the things that you know and I find that
difficult and the things that I do to balance that or one I strongly encourage time off as much as possible so try to get people to take vacations that's hard that's often harder than you would but you just keep encouraging people it's your time and okay I'm gonna take a second to rant here real quick on our software that we use which I won't call by name for managing vacation requests one of the things that it has are exactly that it says vacation requests right that that language pisses me off because it's not a requesting you're not you're not if not a request but it's your time it's already your time you already earned it it's in your pile you're not you're informing me that you're you you're going to take in vacation I assume that you are going to handle all the year or professional you're an adult you're going to handle all the issues related to not being here you're gonna make sure things are done that people know that you're not gonna be there we can talk about whether or
not this is a good time whatever but you're not requesting it's already yours so that's just the language behind that is super annoying anyway I had nothing to do with anything we don't want to it's important in the terms I don't want heroism on the team I don't want I don't want the guy going in at the last minute and spending all the hours trying to get this this gold disk out the door that's exactly the process that I do not want on the team again back to surprise that's a surprising result and I would like that too I would like things to be as boring as possible and every time that that happens it represents a mistake for our team it represents something that went horribly wrong so every time that this happens that's how it has to be represented I have to be talking about the team what went horribly wrong that you had to be doing this and represent it as a problem to be solved it's not look how you know thank you for doing well yes thank you but it's not look how great a job you did it's something went horribly wrong and you were forced to do such a great
job in order to solve for it so the language around this is really important and you know talking people about constantly talking people about examples of implied promises people it's not always obvious to people when they imply something and when they say something like oh that might be easy not realizing that as soon as you say that somebody's going to assume that you're going to do it and or you say yeah you know we could probably do that is the same saying I absolutely will do that and I will do it right now and it'll be on your plate but you know on your desk by tomorrow whatever so just constantly looking at what people are saying and letting them know when they are in fact implying things that they may not have realized what's hard for me in terms of conflict I it's fair for me to say that I'm not naturally a warm person my first my instinct which my daughter will happily tell you my first instinct is to say suck it up I absolutely know that my
first instinct is almost always wrong so this is a battle that I personally have to fight constantly so what do I do one I think it's just time it's time with a team it's time with individuals it's time for them you know to know that and build that trust that they believe that I actually do care ultimately over time people hopefully see that I do actually care and I actually do want to make things better and want to make a difference to them personally and I stop myself from saying anything before I ask if that person is looking for suggestions or advice right sometimes people just want to rant sometimes people just want to get stuff off of their chest is there anything you know are you looking for anything from me in this right before I say anything certainly before I say suck it up and I remind you both to myself and to other people that perception problems are real problems if somebody feels like this is a problem it is in fact a real problem
and that constant reminder to me that that is true is helpful cooperation it's true I think in our studio and probably true in most studios that the next thing is always the most important thing ever this is the most important demo we have ever done ever that's always true that's in the behind true by necessity right and it shouldn't be true it should be no hopefully you're not saying yeah that good whatever we did two years ago that was the most important thing this is way less valuable than whatever we were doing two years ago like that's kind of dumb hopefully it's always ratcheting up it's always the most important thing right but you can't crank it beyond eleven like you're always at eleven like that that doesn't it's not a meaningful statement right so in terms of dealing with that timing and dealing with that issue from for me I find best practices personally is one to stay out of the way of whatever the next thing is as much as
possible so especially in term you know in our particular case in terms of an engine team like prep people get that skid let's get whatever they need they're there in front of them so they have a chance to solve those problems that they want to solve but don't get in the way people are under a lot of pressure to do whatever it is that they're trying whatever the next big thing is don't make it harder I also find it super super helpful to build reference targets again you know it seems really obvious but it's easy to forget not just art reference targets either but also things like audio reference targets what do you want this to sound like before we begin building this let me see what you want this to sound like so we can all hear it we can see how this is supposed to react always as much as possible to build reference targets and having dedicated Sur dedicated resources to immediate concerns so resources that are absolutely dedicated to whatever it is that's happening right now this minute this issue somebody's going to jump on that and not spread that across the
whole team training so what do I want to make sure the team knows and all these in all these individual areas so in terms of confidence the thing that I think is most important for that for my team to know is how to pitch again I think that 80% of the thing is selling the things so knowing how to pitch an idea is super super important so I can I can answer the question of what do I personally need to know in order to be most confident and this is the thing that I want to teach the team and I think these things should be included in any pitch you want to paint a picture of where it is that you're trying to go I want to be able to imagine that future you want to identify the cost the value you want to identify if if it's there whatever the opportunities to learn are we're doing this partially because we will learn these other things and super super importantly what's the strategy for transition if you're if you're
pitching a change we're gonna do we I want to do this thing that we're you know differently from what I'm doing now great how we're gonna get from where we are now to that and often that cost is much bigger than the doing the thing in the first place or whatever you're doing now that transition is the super expensive and lengthy process often and that's an important part of the pitch cost what I want to chain the team in terms of cost dealing with cost value metrics even if this is at a very high level back of the napkin kind of approach you should be able to articulate what the return on investment is for you whatever it is that you're proposing and that may be in general high-level terms but the things that you should be able to point out are the development cost this is how long it takes to do the maintenance cost is how much maintenance I think this will take in overtime the cost the cost of entry this is just doing this because it's the
bar like we need to hit this bar and that's a this is most often true in terms of say graphics or something like that we just need to hit this bar and then we'll talk about what's above and beyond that bar efficiency return so again I'm doing a feature here and I'm trying to make production more efficient so what's my return there player value alpha we're talking about less often but it still comes up that we're talking about this is just going to be cool for the player so what's that value can we identify it and learning value for the team as I mentioned you know we're doing this partially because we're going to be able to learn about this other thing commitment so there's this this very webby kind of appropriate for San Francisco phrase right Minimum Viable Product which is not a phrase we use internally to the team but the conceptually I think that we have this kind of thing which is just to be clear
concretely on what you're actually providing minimally right what is it you're promising do you want to be able to say concretely you will be able to do this right that and that's what you're promising will happen you want to separate that as sort of would be nice things from the absolute guarantees that you're trying to make as part of the pitch so these things should be part of your commitment right you want to propose say clearly what those concrete changes are what are you going to be able to do that you can't do now state those clearly state the problem and the part of the problem that you've solved I've this is the problem that I'm trying to solve this is the part of that problem that I solved but also be super super clear about what you're not solve what you haven't provided I haven't solved this part of the problem yet we'll get to that or I'm not providing this feature x y&z we'll get to that later or not but if you don't state clearly what you're not providing people often and infer that it's going to be there so is it as important to say what you're not providing as it is is stating
what you have what you are conflict for me the most important part in terms of training related to conflict is setting clear expectations in terms of values and one of the things that comes up especially when this is when this hits home for somebody individually is you know someone might say I don't want to change my personality right this is you know I'm just like that I don't want to change my personality but it's for for me it's not about changing your personality right that's not the issue here nobody's asking anyone to change their personality but it's about the realization that you need to be effective and to be effective you need to communicate well and you need to communicate and repeat in a way that's effective for each person but it's also about what's right like and the fact is you say well you know who's to say what's right I'm just say what's right that ultimately right my values are driving what what that's this team is
and I am saying that these are the values that are important to us so yeah fair or not I do get to say what's right and these are the that important to me and I think that the time for say corporate neutrality is over right we are where our ultimate ly taking sides where we're saying these are the things that are important to us as a company these are the things that are important to us as teams and those values help to drive the people that we work with it helps to drive the things that we do staying wills values super clearly and making sure that everybody's on the same page with them is important so the things that you know that should be part of setting their values one what being able to say what do you believe these are the things that I believe I often find it useful to connect to news and current events this is what's happening here's an example of what I'm talking about so that people who just over time get a sense of those values because just saying something like people are
important that connecting that to their to the reality of what you mean to it is very difficult constantly setting part of the sort of review process and the one-on-one process that that you know you're comparing those values and your expectations and how people you know how people met those expectations over time as part of your review process and part of your one-on-one process is important and whenever there is a conflict small or large knowing who will take action next is an important part of the process immediately who will do something about this cooperation for me the thing that I want to teach most to the team about cooperation is just being chant you know being able to champion a solution which means say being willing to say that I'm going to lead in this area being willing to say that I want to make this I want to make this happen and follow through from end to end and that's nice not once the features out
you're out but working with production working with the game making sure that the thing that you imagine the future that you imagined would happen happens I mean you keep babysitting this thing as long as it takes to know that to see that feature happen and I find it helpful practice to give for everyone including myself to find other people to sign off on that process to say if you're building something for animators fine animators that are going to be willing to sign off on whether or not you met the those expectations and don't let yourself off the hook until they're willing to sign off on it so the things that should be part of championing solutions one are being able to articulate how the studio or game or whatever it is that you're trying to accomplish will be radically different sort of the part of that telling painting that picture of the future articulating why this is important to you personally I think is important to say I want to change this because it's meaningful to me because whatever and knowing how to gather support I think this is important part
of the training process like how do you get other people involved you can never do things in you know you're not doing things in a vacuum you doing things with the team for a team so how do you gather support especially if you're not the lead on that team right how do you get other people to know what it is and I think part of that is that being being able to pitch properly helps to gather support so to review these are the things that I find most important to deal with in terms of technical direction that's managing cost managing confidence managing commitment managing conflict imagine cooperation the things that I've talked about here are the context behind those things the things that I think drive those individual things I did mention that I had an easy-to-remember take away nine nine nine nine nine zero if you remember we have which giving a surprise
training thank you I'll take questions if you have [Applause] okay I guess we're done what do you think about work-life balance for yourself and then how do you think about it for other people on the team as well the question is what do I think about work-life balance for myself and what do I think about that you talked a little bit about it in terms of vacation but like more on a daily basis what kind of hours do you expect from yourself and then other people on the team so okay what kind of hours would expect for
myself and for other people on the team I mean I think that the the expectation is that what we're talking the expectation is that I'm working with adults professional people professional adults right that's the base expectation I'm not counting hours I don't care what we're talking about our problems you know here's the problem are you willing to commit to it how much are you willing commit that sort of thing we're talking about these things right so I don't want people to burnout right I don't want people there all night every night that's not thing that I want right so again we're looking to say you need to take time off you need to go home you need to deal with those things but I'm also not counting hours right I think fundamentally the question is the answer is about just treating everybody like adults and talking about the problems and solutions and letting them work those details out for themselves that's not a detail that I you know that that's not a problem that I need to be solved I'm not for an it neither forcing them to this day or you know worrying about it unless I see a problem with them stay
there too long right does that answer your question like I mean I realize it's a tricky kind of space don't want people to crunch like I mean if that's the bottom line the question that you want to ask like no yeah crunch is bad we don't want to do that so I guess I guess one thing I've seen on my team is like one person that worked way less hours then on other people definitely got stuff done but I think overall culture was like I don't know how I felt about it and that person left and I like the culture better without that but again you know if it's a high performer maybe it just live with so one person got stuff all this one person got stuff was getting stuff done and a high performer and worked slightly less than everybody else and that was a yeah it's more like he would hit a hundred percent and everybody else was knocking at 110 to 120 percent all the time and so yes it was solid all the
time but compared to the rest of the team including myself so he was so you have a guy who's knocking out a hundred percent and another guy's for doing 100 and I think for 110 or 120 percent ninety day and that's a problem first our attendees are kind of up yeah but I think again this is about this isn't about time right and if it's about time you were wrong it's not about time what it is about the commitments that your pet team is making and with the expectations that you're setting it's like this is this is what I think this is what I think that we need to commit to this is what this is the expectations I have for the problems that we're willing to solve if he's not meeting those expectations you're not solving hard enough problems you're not solving problems you know in terms of cost value you're not providing enough value over over time here that's fine that's a separate question that question is about are you solving the problems that we need you to solve and are you solving them in a way that's valuable for us right it's worth doing if you can solve this within two weeks
great I don't care if you spend three hours a day doing it if you've solved it in a way that's valuable to me we've already talked about the ROI like that's cool if you're not having those conversations if you're not talking about expecto expectations in terms of value and you're counting hours you're just doing it wrong okay out of your 10 years have you had people that stuck with you and how did you deal with fatigue or like renewing their experience in him if I I had people that sorry what that you know stuck around with you for that ten years sure do I have people that stuck with me for that whole 10 years yeah we have people on the team for sure that people haven't seen that have been there the whole time yeah and how did you deal with fatigue or you know renewing their experience or keeping it the fresh all right how do I keep how do I help them keep things fresh and yeah exactly sure I think that's individual right but often you'll find that again sort of that commoditization process or the
process of something a little tuna tea so you take something that they have invested in like okay look you've been working on this you've been working on collision for two years right or three years or whatever this has been your baby this entire time you know what it's time to give this to somebody else so you can focus on a new problem and that transition is super super hard right people get super invested in the problem space and maybe you know maybe their debt they want to dedicate their they want to dedicate their whole future to that and they want to say look no this is the domain that I want to be expert in great and then we can focus a just keep focusing them being an expert in that domain but often it's I have been working on some area and I want to work with something fresh and renew and whatever and so we help them transition so I mean I think that we have a group of really dedicated people and professionals who really are you know they are focused themselves on training and growing and learning new things like that's not something I have to drive because they're all curious fundamentally curious in growing people
right but helping them to stake us be able to take a step back so they don't get overwhelmed by these things that they've been working for so long on and giving it an opport and that opportunity somebody else is important does that answer your question yes thank you all right sorry I didn't see that they had hi I have two questions the first one is about the size of your team how many engine engineers and you have in insomniac and what is the split like tools around your core all right so how big is it's even what's the split so the short answer is we have proximately 20 people on the team we've had approximately 20 people on the team for 10 years we don't change size hopefully just get better it's just Engine team right just well it's just the engine team yeah but engine also includes tools and yeah right so we're divided into five groups with
approximately three or four people or of five people on each group depending okay and the second one is so I'm sure you encountered problems like that you have some legacy big something that developed for years and you really want to rewrite it to make it simpler to support better but it really doesn't work the rule like five to one and but at the same time you have one two engineers constantly distracting on fixing something in this like legacy system what do you do in this case if a legacy code that you want to ultimately get rid of and it's really hard to see the value in the practical value in doing that right yeah so I think that we're you're looking for is the practical where you're still if there isn't in fact no practical value and doing that you don't do it full stop stop stop thinking about it this is not going this is never going to happen we're gonna live with this forever like ultimately you were gonna wait for some
other excuse that forces you to do it and that will eventually happen or you say there is a value we just having a hard time articulating it it just may be this sort of constant maintenance costs right over time and things are getting harder and harder to change and harder and harder to fix and so at that point you can evaluate it you can say look over the course of the next five years this is going to be impossible for us to work with so we need a strategy out from under this and that happens and we have you know we had to have so our two years strategy for getting out from under these particular things or five-year strategy from getting out from under these particular things so you just create a long term roadmap you don't stop and say how are we gonna do this right now you point you paint a picture for the future and then you build a roadmap for that right it doesn't have to have them today yeah so we're out of time but I will be outside thank you you you
Auto-generated captions from YouTube — names and numbers may be misheard.
Distilling the key insights…
Game Developers Conference · 2026
Jason Schreier · 2026
Comments