Anti-Crunch: Patterns and Practices

[Music] thank you everyone for being here today and we're going to be talking about crunch uh what it is how it happens and things we can do as individuals and teams to help prevent it my name is Chris Cobb I'm CTO for pragma platform and I've been in game for in games for a number of years now pragma we're creating a backend game engine which is basically services and tools to help you ship online multiplayer games our team have worked at Big Publishers and Studios as well as smaller Indie shops so I just want to share stories about uh what we've done in the past to create a sustainable work environment and do that while doing what we love which is shipping games uh this talks for anyone who works in games whether you're leading a studio or a team or you're leading from the front you know as an individual contributor which is where I've spent most of my time

in the industry uh before we begin I just want to give a very special thank you to Hana zti Hana is our lead uh Tech writer and she did a bunch of work tirelessly to help prepare this talk so thank you Hana all right so for our agenda this afternoon we're just going to do quick definitions and cover some distinctions about the ways that you know crunch can happen kind of some of the different causes uh we're going to do a bit of a case study talk about a large project that I worked on at a big studio and kind of the personal experiences I had there the good times the bad and what we can kind of take out of that and I do want to say like I think that this is possible it's something that I've lived and experienced and I think it's really uh valuable so I'm going to talk a little bit about what we're doing at pragma in terms of our culture to try to embed this into how we work every day uh before we dive in I just want to say you know first summarize our goal or at least what our goal should be games

which is you know ship something that's delightful and amazing to players that we're proud of as a team in a sustainable and healthy way and we have to work on purpose to prevent crunch because it's not enough to just like observe this is a problem in our industry and hope for the best so two things I specifically hope you can take away today are that you know it takes hard work to create a healthy culture this does not come for free at all uh there's a book called the advantage by Pat Lon and he talks about investing first in your culture and putting your priority there especially as a leadership team and understanding that the rest will follow and it's possible you can do it uh I do want to say up front I don't think I have all the answers I I don't want to pretend to and I understand that I've benefited from privilege and I know that not everyone's situation is the same uh this is not an easy topic and I don't want to send a message that says otherwise uh I do want to acknowledge that at the outset and appreciate that we all have a unique circumstance uh I also want to say that it matters it's

important and you know I don't feel necessarily qualified to talk about this but at the same time I think it's important that we start having these conversations and so we're going to talk about it today uh what we can do as a community as as and an industry so that's why we're here all right so at its most basic we might say that in order to hit a deadline developers are required to work beyond the limits of what's healthy or sustainable uh people are risking their health and well-being to hit a deadline or date and we're going to kind of explore two main causes so we have got overt crunch mandated by leadership I think that's the thing we end up talking about a lot but I also want to talk about accidental crunch which is a little bit harder to Define but I'm talking about when well-intentioned folks adopt unhealthy behaviors whether that's from misguided ideals around passion or commitment levels or frankly sometimes it's irresponsible management and Leadership uh both can be equally destructive to teams and to our health and wellbeing

so uh a couple years back I was having lunch with some friends they all came from the same Studio very famous Studio renowned for some of the best games that we know of uh but they're also renowned for having a pretty awful crunch culture so I asked them about it and said you know what were the Dynamics there was this like mandated crunch like what was happening and what they described was that you know as is common in you know traditional publishing a date and budget were picked at the outset and that thing never changed uh we all know that game development is super hard and we're iterating and creatively trying to learn and adapt and discover the fun and find these things but they had virtually no production process there wasn't a lot of actual management going on and what that you know meant was folks were kind of left to figure out on their own what to work on and so I asked kind of what felt like an obvious follow-up question which was you guys ever throw any work away and they're like oh all the time like sometimes like six months of work would just get torpedoed you know kind of in a driveby and so you know they continued later in the project the studio head might drive by in nights and weekends and keep track of who's in their seats and who's not uh so you know the point

of this and and ultimately broadcasting to the company what the expectations were and what the commitment level was being required of the team uh so the point of this is that overt crunch is very real uh anyone who's trying to say otherwise or dismiss it is you know needs a reality check ultimately uh especially if we're talking from Studio heads and Executives uh but I don't want to spend an hour just complaining up here I don't think that's going to help or fix anything so I do want to focus on practical things we can do as individuals on our teams to help make things better so we're going to talk about the Dynamics between these different causes for crunch uh and kind of dive into that in the case study one idea I do want to introduce is called win-win or No Deal comes from the seven habits of highly effective people and our goal is to find a winwin outcome um the studio is happy and so are we we're able to live lives as developers that are sustainable for us and and we can you know it's a really simple concept but it is actually really

powerful uh you know often times when we talk about compromise it quickly can turn into a win- lose circumstance where one side or the other are experiencing you know a problem of some kind and I think we're all in games because we're passionate we want to make stuff we want to Delight players but we have a unique circumstance so I don't think there is a universal win that we can all Define and agree on uh but it's really critical for you individually to to understand what it takes for you uh to be in a winning situation and the alternative is No Deal uh I don't make mean to make this sound easy I appreciate that we can't all just like Rage Quit our jobs because we're mad about what's going on uh but at the same time it's really important to understand that you know there basically to to find that individual win and really seek that out um this has really benefited me in my personal life so to tell a quick story my first startup was in educational games it's something I'm still very passionate about we didn't have a plan I just quit my job gave it a I had a few friends that joined me and

uh we started fundraising and received a term sheet it was really exciting but we started negotiating the contract and it was uh really difficult and it became apparent that our investor had different you know incompatible needs uh between us and our our team and so we were struggling to find that win-win circumstance uh for us you know we wanted a certain amount of creative control and freedom in what we were going to work on for the investor they wanted to protect their investment they were going to outlay millions of dollars and trust us to build it so something but ultimately we couldn't find a circumstance in which both parties felt safe and it was like the hardest thing in the world I promised to walk away from the chance to work on something that I was so passionate about uh but we kind of stuck to this framework of win-win or No Deal and ultimately had to step down from that and there wasn't blame on either side it wasn't about you know one person being right or wrong it was just that in that circumstance we couldn't find a situation that worked for both of us so this was one of the hardest choices I've ever made but this framework has been a really useful thing for me to remind myself I need to find a

win winning circumstance for myself and and hope that the other party can too so having touched on some overt crunch ideas just briefly I do want to talk about the more subtle signs of a crunch culture uh first I do want to say it can be just as destructive you know I don't want to be um I think the overt crunch is the one we focus a lot on and I think it matters and we need to to to work on that but I've also seen situations in which it wasn't a mandate from leadership but still saw destructive behaviors in and around uh the teams I've been a part of so I do want to spend time there because there's a whole lot we can do individually to to do better there um this this idea was seated from an experience I had early in my career where I was working on a great team uh morale was high and you know it's early evening one night engineer on the team was kind of in the zone he just kind of jamming away and one of our colleagues teammates came along and it's like hey man don't burn out you know clock out take care of yourself and this is totally reasonable thing to say

fast forward 6 months and we started coming up against the deadline of this really large project and that engineer was feeling pressure from the schedule he started raising this in team meetings like hey I'm really getting nervous about the scope of what's Happening you know he's worried about getting crunched and that same colleague that encouraged him to take care of himself said hey you know don't worry about it I'll just make a grocery run I'll get snacks we'll load you up so that you can kind of stay here heads down and focused and this really struck me uh you know with the best of intentions our teammate was enabling an unhealthy choice for for the team and for this person in in particular and it raises the question like are we going to advocate for healthy decisions just during the good times or can we do it during the difficult times as well you know nobody was being ill willed in this circumstance but it is up to us as individuals to look out for one another and take care of each other and ultimately you know I think that it takes some personal courage uh to speak up and say hey wait a minute why is it that months ago we are encouraging one

another to to keep balanced and stay healthy but now that there's some pressure we're suddenly you know creating enabling behaviors and so that's kind of the idea that I do want to spend some time exploring and talk about the management and Leadership side and and how do we run our teams so let's launch into the main part of the talk uh it's a breakdown for a project I work on called team Builder and we're going to talk about the tension between the avert and accidental pressures and then specific processes like how this team ran and operated in a way that ultimately I was really proud of uh I I want to say you know this word agile has been around for 20 plus years I think it's lost a lot of its meaning at this point and we all say you know agile is great but you know or we tried agile but we just move too quickly to make it work or you know agile is too restrictive and flex you know not flexible enough for our team or sometimes people say oh we do Agile you know hard stop but they're still over budget they're still stressed you know we're still getting crunched at the end of our project so I just want to say at the outset like process should serve the

team not the team serving the process which means like people should be thankful for the activities we you're doing uh one thing we do at pragma is frequently ask people is the time we're spending in meetings useful uh and if we're all just like you know ripping our hair out in in conversations that are not productive or health helpful it's just a huge waste of time and you know another thought I want to throw out probably breaking the rules of giving a talk but I want to say you might be doing it wrong um what I mean is that there's like really complex math behind estimation and planning and projections and teams will often times adopt a process that kind of looks okay on the surface but once you dig in you'll find out that it actually violates these underlying principles and ultimately the result is that we have estimations and dates that don't work they don't matter it feels like a waste of time and nobody really gives any um you know and then our projects become late and over budget uh morale is poor and you know results in crunch so uh Team Builder it was a project we worked on as part of legal Legend and we had a couple goals at the

outset uh the first was to eliminate a negative experiences when forming teams League of Legends is 5v5 competitive game we'd stick five strangers together give them 60 seconds to agree on what position roles people would play often times you get in a fight with your teammates before the game even started and then you're playing this like competitive 40-minute PVP match it it was really rough and we recognized that we were not giving players a shot at uh you know working together as a team uh we also wanted to give a lot more control over their game experience give them tools to express the style of game they want to play and the the experience that they want it was about 18 8 to 15 members uh throughout the project uh this was cross discipline between engineering design ux QA art production and the rest uh there were more than 150 people involved in getting this thing out the door we worked across about 20 different product in publishing and feature teams uh to get everything done it was a very large scale thing and ultimately it was about 15 months from concept to launch it

scaled to support a massive number of players and we ultimately were able to avoid crunching uh in this project uh we shipped without player facing bugs something that the team was really proud about we had happy players uh you know we received high ratings on the user experience and the actual you know feature and at a time when most features came with thousands upon thousands of player support ticket requests complaining about bugs and problems and issues we only got a handful and most of them were to say thank you than you for the feature uh so what we're going to do is break down how this team ran uh explore the mechanics of how the team operated I want to talk about the good times and the bad it was not smooth sailing even though you know I was very excited about the result and hopefully there's something practical you can take away so and take back to your teams so at the outside of the project uh I was asked to give a gut check estimate was told this was not a formal commitment and we did some story mapping we had a design doc that we reviewed as

a team and we broke some stuff out and we said you know we think this is about a six-month effort we then spent the next 3 months just trying to get an internal test environment we had a reboot and false alarm on our client technology that caused us like a multi-week rewrite so in no time at all we were already approaching our six-month Mark and suddenly the tone changed we started being asked you know why aren't you done yet what are you going to do to fix this uh this was a pretty scary moment I I hadn't been at the company very long and you know I got this secondhand message that said well leadership says your team had better crunch because how else are you going to get this done so I went home talked to my wife we had actually just moved across the country had young kids at home I was really scared and you know the conversation I had was like hey are you okay moving back home cuz like this may not work out uh I had made a commitment to my family about the boundaries of kind of my work life and that wasn't something I was ready to to compromise on that time but I was scared I was very scared um so our team kind of rounded up back of the office and we put

together kind of everything we had so we brought back to stakeholders the schedule and the timeline we had built we showed our velocity and the progress the team was making uh we had a running version of the feature always available so we could boot it up and show everything that was working and there were pieces that were already online and functional but clearly we weren't done yet and you know we had projections that were useful we actually at that point in the project were able to say okay we're not done yet but we do see ourselves Landing based on everything we know you know at this period of time 9 months later and importantly we had enough data and information at that point to make that prediction in a way that was actually powered by data which meant we actually knew how fast we moved as a team and it was really interesting because in this circumstance when we showed real useful data we had a working version of the feature uh things settled down uh in terms of the stakeholder kind of pressures um they had the confidence to see that we did have a plan and ultimately kind of the appeal I made was like if you need somebody who can go faster I don't know how to help you in this you know because I think we're doing everything we can sustainably but

we do have a plan and I think we can deliver and so once they heard that message and saw that we had real substance behind our plans you know they actually started supporting our team uh in in this circumstance being disciplined in our process and our planning gave us the ability to push back and um we actually got a different message that came down the pipe later that said hey if anyone's time trying to Crunch your team that's unacceptable and I'm want to be clear I know that this is not the circumstance all of us have lived uh so I'm not saying that this is somehow a magic you know Silver Bullet that's going to fix everything but in this circumstance it was really interesting to see that once we were able to create some confidence within the stakeholder team some of that pressure was was alleviated all right so we're going to basically pose a question this would be like a starting point to have a conversation between yourself your team and we're going to kind of propose that and then I'm going to break down what we were doing as a team to kind of address this idea uh on the project

so first is the question do you have realistic estimates and I think this probably strikes a might might might feel a little sarcastic uh but it's not um I think that most of us deal with estimates that are basically useless you put a date on it and either you just blow by that date and it doesn't mean anything or it's weaponized right and suddenly you're being held to you know your feet to the fire uh but estimates are really important if we're going to manage budgets right and we don't always talk about the money involved in games but it is true that you know it costs money to build games and so there somebody has to be tracking the budget make sure we don't run out of cash I think a lot of us don't know what estimates are for right we just said it it's like either they're useless and they're just stale sitting in Jer somewhere or uh they're weaponized and used against us so in our case we're able to produce estimates that actually let us predict 9 months in the future and stick to landing and we did so without crunching at the end so how did we produce those useful estimates

uh the first thing that is really really critical to understand is estimates are not a commitment you're asking somebody to predict the future of something that is complex games are just incredibly complex as we all know it's technology it's servers it's clients it's Graphics it's 3D it's art it's animation it's narrative like it's all of it right it takes so much to create games and that's hard so estimates are not meant to be a commitment to when the work is done they're meant to represent an average if we did 100 stories that are about this difficult what is the middle point on the graph of how long it takes and this is gets into some of that complex math I will have resources at the end of stuff to kind of check out it gets pretty wonky and math heavy but if you want to understand the underlying reason why there's a fundamental difference between understanding that this is on a a bell curve of averages it it's useful to know um you could also just trust me and just kind of stick to it but uh but it's it's tough so let's use three days as our example as as we see up here and it's

important to recognize sometimes it'll just take a day you know it always feels like you get lucky when when it takes less time um but you know sometimes it'll take five days and that's okay um in fact it's not just okay it's actually expected like mathematically we expect variation in how long these things take and so that's got to be part of our process and you know another thing to consider though is that you could just throw away estimates alt together and just say yeah the game's done when it's done um but that gets really hard so we do have this bell curve right three 3 days is our average if you start getting up to day 10 that is a time to check in and say wait a minute we're now three times longer than we thought it would take and it's worth having a conversation at that point and say wait did we just load up on six new features and that we shoved into this after we did the planning uh that's something you have to be really careful and disciplined about as a team I'd say scope creep causes a huge a huge amount of uh challenges sometimes it's just discovered complexity the task was actually harder than we thought it was and that's okay to understand but now we have to check in because what was

valuable to us as a 3-day story may not be worth it if it's going to be 30 days because there's so many other features we could be building so checking in you have to watch how far away from the average you're getting and there is a moment where you do need to have a discussion and sometimes you do need to Pivot or make changes uh so you know and this happened to my team not long ago we made a two-point story it was meant to be like unblock us in one or two days because we had this really complex feature we wanted to work on later but we didn't have time for it so we said let's just unlock our and then we'll get back to it later well some somehow 4 weeks passed and we still weren't done and we didn't really check in at that 10-day moment or at some point on the journey and because of that we kind of let this thing run too long and of course there was like massive amounts of scope creep we had basically shoved all those complex features that we were trying to wait on had gotten added back in and um you know and it was significantly complex like we had some tech debt we didn't account for and all the rest uh that I think we're all accustomed to but my point being that while we're not not treating estimates as commitments and trying to hold people

to it uh you know hold people's feet to the fire at the same time you do need to watch and once you get out of bounds like you should check back in and and make some adjustments all right so I think this is how most of us plan you put the features on a list often times we stick a date on them and we say okay we'll do them 1 2 3 4 5 you might look at the end of that that estimation and say okay the Project's going to take six weeks long um this this doesn't work at all I think all of us do this and I promise you it won't work I mean I think we've all experienced it it never works this way just think about it because you're putting a fixed date on a schedule and you're saying it will get done in two days let's just pretend the very first feature you work on takes three days your entire schedule's busted every single date on your entire calendar is wrong and you're going to go rebuild it if you try to maintain this thing you're going to be rebuilding your schedule multiple times a week this is an effective tool for planning and delivering so you know this spiral is out of control the other thing is it puts your team on the back everyone feels like they're late and behind

schedule on the third day of the project right um because when you use these fixed dates it makes it feel like something's broken when it takes longer but we know it's going to take longer right that's what we all live every day now this is a little bit of a weird graph don't try too hard to parse it it's just we're putting these overlapping bell curves right the averages and there's a couple really interesting things to observe about this because on the on the one hand we still have a list of features that we want to build and we still have you know a some kind of ultimate like we'll get it done eventually um but the important thing to understand is like this does not predict whether feature one or two gets done first in fact it literally doesn't even predict when any of the features get done in in the individual right and there's this really interesting property that says every single estimate for every single story can be wrong like we just don't know it's we're predicting the future but all you have to do is measure how much work gets done each iteration and what I mean to say is like you'll get some work done some of those stories will clear but you're not

predicting order and you're not holding somebody's feet to the fire just because the one thing they thought would only take a day turned out to take three now what's amazing about this then is you can actually measure progress you can say well we always get five to six things done every iteration sometimes it was the one that carried over from last time sometimes it was something that came in at the last minute but the team was excited and just chased it down and so you can actually create real durable valuable useful uh velocity that helps you predict how long it takes but what you're not doing is pinning everyone to an individual completion time on an individual task uh there's another consideration when we're talking about estimation and planning and it's called The Cone of uncertainty when an idea is brand new you don't know a lot about it and making firm commitments at that point is risky because frankly you're going to learn a lot about your game and your features as you go so what I like to do is separate we call it a low resolution estimate and a high resolution estimate the first time an idea comes up just throw out a number if you have two or three people

who are like subject matter experts just let them put a number on it without too much deliberation you don't want to spend time planning for something that might be months away from being worked on but when you're a couple iterations away you know it's going to get worked on in the next few weeks that's the point where you want to start breaking it down in more detail and what's valuable about that is you've learned a bunch over the last weeks months and so by the time this particular story gets you know close to the top of the backlog that's the time to break it down in detail and agree what's in what's out what's in scope what are the completion criteria right what are our requirements so the idea then is that you put a number on everything that comes into the backlog but don't spend a ton of time on the stuff that's months away it's just a waste of time let's talk backlog for a minute um I don't know backlogs are kind of terrifying in my experience often times like 75% of it is like I don't even know where any of these things came from like the number of times I've checked out J ticket and I'm like who wrote this it was me like it happens all the time maybe I shouldn't confess that I don't know um but backlogs again they take

work to manage and so there's a couple ideas the first is you do want all the known work you have to be in the backlog somewhere but we just talked about the cone of uncertainty so if stuff's like a ways out you should just have a big chunky like sentence that describes some big group of features right an epic or something and you should put a big number on it that's kind of in the ballpark and just leave it alone what you shouldn't do is fill up your backlog with you know 50 or 75% kind of noise which was like one specific Edge case for one specific feature that we decided to defer and it's been 6 months if you can't in your head like predict working on the thing within the next like six months or so probably just delete it or kind of group it back up into some epic because what's going to happen is if you open up your backlog and half of the stuff in there is kind of irrelevant or hard to you know really grock then it's just going to feel like a mess so we have to maintain a backlog the other thing is that we want a stable backlog in the sense that we've got a prioritized list of work to do but it's a super Dynamic list so being stable

should not mean uh static right because literally all of games is about discovering right we're trying to find fun things you you might spend a bunch of time working on something realize it's not working and you're going to have to move on um so when we talk about maintaining the backlog the thing is going to be evolving and changing all the time but just keep it clean and tidy if stuff's too far out either delete it or roll it into one of these epics so that you've got some some sanity for me my sense check is if I crack open the backlog I should be able to browse and everything should resonate I should be like okay these these are all things that are understandable like they're in the context of what we're working on and if I start seeing a large amount of just kind of junk or noise uh then we got to clean it up uh this one is a little bit technical a consistent measure of estimation now people have used you know t-shirt sizes Fibonacci there's all sorts of different Frameworks um Fibonacci does have some really nice characteristics uh the nice thing is that those smaller numbers at the beginning one two three five they're kind of high detail so you have a little

bit of separation between how hard something is but then they kind of scale up you know you get to 8 13 20 the whole point is that the larger the work is the less precise it is right we don't have a 20 and a 21 and a 22 it's just like H it's about 20 and then we go to 40 and 100 and infinity so I do like Fibonacci but the critical thing is if you're trying to use your uh you know if you're trying to build a process that lets you predict when you're going to be done just stick to one measure don't change it every couple months because people have decided oh if we change to Ideal you know work hours that'll be a better system you want to be really consistent the other one this is a huge thing to to watch out for do not change the original estimate after you've done the work we already agreed that estimates are going to be an average completion time so when that thing that you thought would take 3 days takes a week and a half don't bump the number up and this it's a hard one to explain but basically what you're doing is turning your backlog full of estimation into that fixed schedule right if you change the number after the

fact you've actually erased the the estimate and what happens then is that your future estimates won't work basically it's it's a lot um yeah I'll point you at the resources at the end of the talk but just trust me that if you're backfitting your numbers after the work gets done they're not going to be predictive anymore and that means your schedule won't work so just keep the estimates as they were you will often times though find that you know scope creep has happened so you break out a new story and you know put put it back on the backlog so there's a lot of opportunity for you to account for that work um but don't just change the numbers the last piece uh you know I know we spent a lot of time on estimation but I do think that this gets to that responsible leadership and management the reason this stuff matters is that if we put ourselves on a good footing in terms of how our team runs it gives us so much better chance to kind of close in on on Landing our launch without accumulating all this pressure and stress and hidden work that we don't find out until you know a month before release so the last piece is discovered

work and this is the idea that when you're trying to solve one problem you'll find two more probably more true in games than anything else as far as I know uh this is called discovered work and it's really really key if you're trying to predict when your your uh Milestone is going to be complete and let's imagine your team does 20 story points every iteration and you've got 100 points left and you think Tada it'll take us five iterations you have to know exactly how many story points are being generated every iteration right because you're going to be adding new stuff to the backlog so if you're completing 20 but discovering 10 new points then every iteration that passes is going to be accumulating new work and I'd say this is probably the most common mistake I've seen when people are trying to build these road maps these projections is that they're not factoring in the average amount of discovered work that they have each time uh each iteration and this is a really powerful tool also to measure your team's discipline when when your project is branded new you're going to have so much Discovery often times I think you

have as much Discovery as you're getting work done so like at the beginning of a project you're not even getting closer to release because like the team is figuring everything out you're learning and so what you'll see is like well we got 20 points of work done but we discovered 20 new points and what has to happen as you approach your deadline as you approach your Milestone is you have to start saying no so that discovered work needs to decrease over time so your Discovery measurement needs to decline as you get closer and closer Milestone that's the team one learning amongst each other you know this is the feature we're building and learning how to kind of say no and be clear and it's also just demonstrating discipline that if we always you know add new features we'll never finish um I do want to talk a little bit about team composition in stable teams uh it's huge value that we have at pragma is Long Live teams which is like keep teams together uh I would say most Studios talk about this but then you look at what they do and what happens is you know every couple weeks they're like but I need a ux designer and so they like go grabb one and rip them out of

the you know the group or the team they're working on um I think we all understand or at least you know if you follow like any competitive sport you you know that the best teams in the world are not composed of the five players with the highest stats never works that way teams are built out of our relationships and our Dynamics with one another like it's it's about the personalities and the strengths and weaknesses we have and so you're only going to get that experience as a studio if you let your teams gel and build a chemistry together so the other thing that happens oftentimes on the side of estimation is you might have like open head count for you know a few new Engineers or or artists and it's really tempting to use those re like use those individuals that don't exist yet in your projection of how long the Project's going to take so it's like crucial no matter how hard you're trying to hire you need to be really disciplined about not trying to incorporate your open head count as though they're going to actively you know support finishing the Milestone uh in particular we we all know how hard hiring is it takes a huge

amount of time if a team is like fully loaded trying to hire in my experience that can take 20 to 30% hit to the team's productivity so you're actually going slower as you attempt to higher uh not to mention onboarding we also know that it takes months often times to to get up to speed so if you're bringing new people on the project you're you're going to go slower your team is onboarding those new folks and teaching them so you know your experts are not going to be going as fast and long term of course you're going to get payoff because you've got a new team member but you'll be slower uh in the short term so please be aware that definitely do not incorporate open head count into your prediction on how quickly things will get get done all right so here's the big recap of all the things we're trying to think about with estimation and planning and we'll kind of speed up from here but this one is just kind of near and dear to really doing a doing a great job operating our team day to-day and unfortunately my notes are not written correctly so I'm going to lean in a little bit here so so we're talking about you know estimates are averages and not

commitments we're talking about uh not changing our numbers after the fact we have stable Long Live teams uh we we all the known work everything we understand has to get done is accounted for but you know only high resolution estimates on the on the stuff we're about to work on uh we're going to maintain a relevant prioritized backlog and we're going to measure that discovered work easy all right so we're going to move on to a few other topics and uh the first one is about knowledge silos you know I'd say every game team I've worked with says like oh we don't want to have silos right but in practice it's like oops like you know one person on the team knows this area and they're the only one who can work on it um you know when we talk about maintaining a healthy work life balance if your team is going to be held hostage when one person is missing it creates a lot of pressure for people not to take time off right um it it's scary to take you know PTO if you're the one person who knows something critical and it can create a

lot of trouble I think across your team and it creates really imbalanced situations where it's hard to operate as a team and instead we become this like group of individuals so um I inherited a legacy matchmaking system it was really complex gnarly code base and this thing had been entirely siloed only one engineer worked on it at a time they usually they'd own it for a handful of months before passing it off but there was no knowledge transfer there was no cross training and it was a super complex code base very difficult to understand so we had this feature that if a player came back after like 6 months uh we wanted to um give them a break like we don't want to give them really tough you know sweaty matches because we want to let them get back in it's unlikely that their skill rating is actually as high as whatever number we have for them so we had this nice feature that would give you a little bit of discount to your rating as you came back in and it would work for a while but we saw this weird side effect where you have some easier matches to kind of ease back in and then bam you get kind of slammed with like

really tough matches and you go on a big losing streak and most players would just give up at that point leave uh and by the way so this was happening during the team Builder project so we had to maintain the old system as we were trying to build some of the newer features so basically nobody on our team could change this code base without breaking it I I literally mean 10 out of 10 people attempted to go in and make changes all of us broke it so it was a really tough situation and what happened then was we kind of neglected trying to address this issue because it was so complex and hard and ultimately it just meant that we were causing this problem for months longer than we should have because this silog codebase made it really difficult for anyone to work in and ultimately what had happened was there were basically two copies of the calculation logic and so we had fixed the part where we gave you the discount on getting your match but when we came to upgrade updating your skill rating we didn't run that same calculation what happens then is every win you got against an easier opponent we were still bumping your skill level higher and higher so by the time we take away the discount suddenly you're actually like you know 100 points more skilled in

theory than you were before you left which is not reality and then we would just punish those players unfortunately and cause a lot of pain and so you know in this case we created a real problem for our players because we had this silid code base that was really complex and you know it it changed how we thought about it for the team Builder project so one practice we use as a team is called pair programming and you know this kind of engineering specific but it's an unusual practice I get that not a ton of teams use it but it was born out of the desire to say what if we took a good idea and then took it to an extreme in this case we all tend to agree on the engineering side that code reviews are good um and it said what if we did them constantly and what's really interesting about this idea is that when you have two brains solving the same problem obviously the siloing is you know eliminated by default it was actually a really powerful thing when I moved on from this team that I was part of for for a lot of years um it was really reassuring to me to know that there was not a single thing in the in the entire system that only I knew about right and it made it feel a lot safer to move on to my next team because we had

that coverage and expertise built in the other thing is we ship less bugs you know obviously we're not primarily focused on quality here um but quality affects our lives a lot with respect to Crunch right um often times we get into the hardening phase on a milestone or you know project and then suddenly it's like oh wow you know everything's broken and then we're kind of jammed at the end because we're trying to fix all these things and so it also increases your quality in a really positive way so we are I guess we are going to talk about quality after all um Quality as you go so you know I would say that um something I think I've observed and others have too is that QA can get a pretty you know treated pretty poorly uh in how we run things sometimes uh you know we have a team called quality assurance sometimes they're they're siloed as a group and they get brought in late in a project and they're told like assure quality make sure it's great you know but at that point they weren't part of the product development

and they didn't have a seat at the table when we're planning things and when we were creating you know these ideas and so ultimately they're often times in a situation where they just point at something and say that's broken that's broken that's broken which is a really disempowering place to be and ultimately what happens then is we're discovering all of these quality issues right at the end and nobody budgeted the extra six months we needed to polish the 6 months worth of features we just built and so they we end up with this absolute pressure at the end of a project so one thing we talk about is a whole team right so it's one thing to say we want logging Li teams another thing to say that we want everybody at the table at the outset so we had QA embedded as part of our team during the kickoff they participated in that original mapping they participated in the design review and the plan so that incorporating how we were going to test and make sure this thing was actually ready was built into the team and this was a really really powerful thing that um you know helped us it meant that we didn't have the same kind of surprises that often times we

encounter so you know another angle to take on it would be you know do you catch errors as you go or do you kind of shunt them to the side and say I'll deal with that later um one practice we use is called test driven development again it's so pretty frequently talked about thing um but it's a really interesting idea what you're doing is you're writing Co you're writing a test that says hey you know I'm going to give a player a discount if they haven't been back for 6 months and you run a test and it fails because you haven't written that feature yet and then you start coding and trying to write the feature and what's really powerful about this technique is that you're thinking through how to deliver the feature from the get-go and you have this really interesting Suite of tests that help your team and cover you you can run that test a thousand times before you go live so if you come back to make a different change to your system later youve got this regression Suite that's really interesting and really powerful um so just bringing it all back I think that what we're looking out for is the 8020 rule that says you know we think 80% of the features are done but then

somehow like we get hit you know on the wrong side of this equation and there's like the other 80% we didn't account for and when we start talking about embedding quality as you go I think that's how you can account for like hey once we say the features done we got to move on and work on the next feature and we're not afraid that we're going to get jammed at the end with all of these things that didn't get accounted for throughout development continuous integration and delivery I think the word continuous Integra ation right now most people think of it as like oh it's Jenkins or team City and those are Technologies and they're useful ones but the idea is basically like we just have to ship a single video game right and so what happens oftentimes is teams want like people want a little sandbox to work in and they're like hey I want to be able to work without you know stepping on my colleagues toes my teammates toes and what happens today at least is we get into these like feature branches and that could be a useful tool to experiment but you have to ask yourself the question of like how long is it going to take after the feature is done to get into the actual build and

what you'll find as your team grows and gets bigger you'll have people out in the woods for longer and longer teams can be out for weeks and months in fact the most extreme story I've ever heard was a team that did feature development for about six months and then spent two and a half years integrating those features in it was and it was just like a crazy Knife Fight of like politics about who was allowed to put their code in first it was just the most wild story I've ever heard and so it's really important to think about if we're just building one game how do we work day today in a manner that lets us put new code in the system and and add features and this applies to Art and animation and you know game behaviors all the different things that go into it now so there's this idea called trunk-based development which is just like we all put our code in and we put our art in and our Assets in now a lot of us I think are used to that being a very unsafe thing it's a very scary Prospect and so the idea is well if I just have my sandbox on the side I can work on it and when it's ready I can bring it in but there's a lot of challenges with that in particular the the you know 2

and a half years of integration cost apparently for that one team um but it's more than that though uh the question is can we build something as a team together basically can I add a new feature to the game that isn't going to break everything it actually makes you think in a different way you know if I'm going to prototype a new character and you know I'm using like temp models and temp animation temp assets have we built tools so that that's safe to do can I like add that in you know through configuration and through data as a designer and can that be done in a way that's not going to immediately crash the game for everyone can I turn it off and on right feature toggles are a really powerful tool because if you can basically make your new features exist without causing harm then they can be present and the people working on them can look and and see them but you're not delaying all of that complexity of like how does this actually get into the game and so again there's a whole Suite of things to think about here but just the high level idea is we're building one video game let's learn how we can add new stuff to our game every day without um breaking it and it changes your

mindset and you can think in a way that says like I know how to do this all right so basically we broke down a handful of questions I think these are fine starting points again some of this could be self assessment where you're at as a team and it could also be a starting point for a conversation and we're going to look at how we do our estimation we're going to prevent knowledge silos in how we work as a team and we're going to build quality in as we go and we're going to build one video game together and figure out ways to add to the game uh in a way that's not destructive I do want to say that this is possible it's really hard I mean games are a really brutal industry and frankly we've lost a lot of great folks who have you know become burned out and left um but I do want to say that you know for myself I've had some great experiences in my career and some scary ones um but it is important for us to you know say that we can do this uh we can build sustainable environments and and ship awesome games I do want to talk

a little bit about how we're trying to embed this in our day-to-day culture uh in terms of how we work as a team uh I do want to say that value statements can be like really Hollow and empty um as we started pragma I was pretty reticent to have the conversation about values because you know it's you see these lists Integrity communication respect Excellence it's like yeah of course I want those things but that's kind of what I just expect like those should be table Stakes that's not you know very special and you know uh Netflix had a culture deck and in it they put up those exact culture words and then the next slide points out that that was that was the cultural State values of Enron which was this company that famously defrauded a ton of people so when we talk about values I think the best way to do it or at least the way that's effective um you know for us is talk about behaviors you can you know if you said are we excellent I'm like I don't know I hope so it's really hard to assess that um so we try to Define our values as statements of behavior right which is like we do this or we prefer to do it this way over that way

that way we can check in um these are all aspirational right we're not going to nail it you know the on our first try um so that's just a little bit of framing around values uh we so you know the theme is customer Triumph again this is for us we make tools for game developers so it's you know we're ultimately I hope benefiting players um but you know that's just a a a bland statement um but we talk about a few different behaviors underneath that um the first is we'll prior I a customer need over a theoretically perfect system if you've ever worked with any Engineers some really like to come up with the grand perfect plan of the most beautiful technology that has ever existed in all man you know all of history and the problem with that is it's hard to create and it's really not very practical so in our case we have trade-offs to make because we're trying to make a product that's useful for lots of game studios but at the end of the day we say we're going to prefer to make it work for this one game ahead of trying to create something that's the thetically ideal and that's something practical we can measure because we get to talk to our

Studios and say Hey you know are you getting what you need and you know we had a circumstance in which we were trying to create this nice API and we had this for crafting and it was basically like okay we came up with a few basic crafting scenarios and we built a nice little feature to to power that kind of system and then uh you know one of our Studios came back and like yeah but we have this very specific thing that our crafting wants to do and you know a couple members of the team we were like well could we just like tell them to work around it and figure it out themselves because like we had this beautiful like nice little system but we came back to this value and said no we got to unlock what they need and so in that case we came up with a plan where we had this like powerful version of crafting that was kind of it'll let you do anything and it takes a little bit more work from the studio but then we kept our like simple crafting system there so that it would be more data driven and easy for um for the basic cases so in this case we kind of found a compromise where we want still want to make great things that we're proud of but ultimately we have to measure like are we solving a real problem and it's yeah uh the connection to Crunch of course is that we don't also want to just spin our

Wheels building a bunch of features that nobody ever wants or uses uh part of the reason as a company we started with a few Studios as partners was that I wasn't excited about building technology for three years and then hoping somebody would would like it quality at speed uh the trade-off between speed and quality is very real um you know it's interesting I think there's two kind of profiles for for engineers and one might be like the cowboy coder that just like you know slaps things in really fast and they're just going you know shooting from the hip and then we got all these like problematic ideas around that um but the important things is like speed and just moving fast and then we got these like architecture astronauts who just want to plan and plan and plan right and this comply to game designers as well um you know somehow there's like brilliant ideas but we never built the game and so we're talking about trying to create a balance of like we want to work on features like on the first day we want to start working and start building at the same time we do want to work with discipline and make sure that we're building in quality we're reducing silos and we're integrating all our work

together uh into one basically everything that we went through as part of the like the team Builder process review so at the end of the day basically what we're trying to express here is that we want to strike a balance because we do want to move fast right we want to iterate we want to create we want to make new things but we also have to keep in mind that we need to make sure that when we build something it's done in the sense that we can actually ship it you know it's easy to call a feature done and say it kind of works as long as you don't look too closely and suddenly youve got like months and months worth of hardening and and Bug fixing and stuff right at the end of your deadline right nobody ever builds that into the schedule unlock teams this is probably the most difficult one but I think really really key and the idea is that you know we want to we would rather a team build their own solution for a problem than we would getting tied up in bureaucracy it can be so difficult if you're at a bigger Studio or publisher when it feels as though you can't get your work done without being on like six different committees and negotiating with like 10 or 20 other teams to kind

of like get priority and get the tools you need and so we really talk a lot about if we're going to embody a culture in which we are trying to work together and build something healthy we need to create an environment that feels safe for people to solve their own problems and again and it you know this happens in games like you can have issues with this like uh League of Legends had like four different systems for measuring time which made the game extremely complex to like operate and run because we didn't know what happened worlds and I think it was season 2 Worlds like the game kept crashing in production in like the world championship games and we just couldn't stop it so there are real problems that can happen if you create a lot of technical debt and messes but at the same time if you're working on a team you just need to be free to solve your own problems so we absolutely want people to get together and create shared Solutions but we're not going to put up a lot of artificial boundaries and barriers um our hope is that building up a you know a team of high morale and ownership uh and help people you know feel like they have control of their Destiny and and create an environment we

all want to show up every day and work on hard problems together so this is just the final bits and you know uh we did talk about having Long Live teams and not treating people as resources that we Shuffle around uh you know one thing we do in terms of Team stability is we actually give people the chance to create their own names uh I worked on a lot of teams where we had to be named after the feature we worked on and as soon as our team shipped the feature then our name got changed I was like how do you have an identity if your name changes all the time uh it it's just really interesting so it's a small thing but I think it kind of reflects that value of saying like no your group you know a lot of us have picked uh uh different gods from uh I mean we were all playing Hades at the time so a lot of people picked different you know but importantly there arbitrary names they don't mean anything other than just that that's the name of the team it's really fun uh we also we do not do individual performance reviews um this is like sacred for most companies but there's a lot of harm that can come from it and at the end end of the day it's like we as a business we want to know that we have healthy teams and so we can look at the

team and say are they shipping are they delivering are they doing what they need to do and we can trust them to self-manage if somebody on the team is struggling we hope that they get coaching and development um but at the end of the day we can just say you know we expect the team to to deliver and do great things and we'll let them manage themselves it's really empowering we think and we hope you know we do have a flexible PTO this is one thing that comes up though is like hey maybe people people feel afraid again some of that gets into the siloing stuff we talked about um but my co-founder and I we do take time off and we put it on the company calendar we let that be visible to people so that they can see it's it's safe to take time uh you know we do remote work it's hard though because I think being in person can be really valuable too so we actually try to be really encouraging if if people want to get together and work in person we absolutely support that but we're remote first because of the flexibility it provides and the fact that we've obviously been in pandemic but we're trying to embrace that and really invest in the tools like you know Discord has one really great feature which is you have persistent voice channels and so it actually is a fundamental difference if people are already in channels throughout the workday then dropping in is not all this friction and slack of like oh should we

make a call should we make a call Zoom Google Hangouts like slack calls you know so there's small things that we try to do but it tries to make it feel like there's some actual presence you know we're remote but we try to make it so that communicating is as frictionless as we can get it sustainable hours you know I mean at the end of the day we just have to make a decision about what we're doing I think games are so so complex there's a lot of domains in which working hard just produces more output in games we can literally destroy value right if you break a bunch of things create crashes you can take whole teams offline we recognize that when you're doing really complex you know work it's worth protecting People's Health so that they can actually continue building over time and not creating huge problems that end up becoming something we have to chase and catch up with um here's a list of resources you know uh these just are scratching the surface there's fantastic books and talks out there about a lot of these ideas agile processes uh organizational health and I

highly encourage you to invest in the leadership and communication stuff because it can be really useful to learn how to be an effective Communicator as part of your teams uh so absolutely you know just spend time learning and growing in these different areas uh this does conclude the talk I really appreciate everyone for taking the time to be here uh we do have booth at the Expo so we'd love you to stop by and say hi um I will be at Alco 305 here in the South Hall for 15 to 20 minutes afterwards so uh please come by and talk more um thank you very much and that's [Applause] it we've got about six minutes for questions if anyone uh I think we've got a mic up here looks like we got one on either side um hello uh you were talking about PIR programming and I was wondering how do you do that when and you are working from home yeah pair programming from

home yeah yeah it's a lot harder um I mean we do use a bunch we've tried a lot of different screen sharing Technologies but there are some that are dedicated for just screen sharing if you're using a video call feature to do a screen share they're not very well optimized and so there's a few tools out there you know there's one called pop and droo there's team viewer um but I would look for the ones that are very specifically meant for doing screen share and not the ones that are just general like video chat apps um it is tough but other than that it's just being on that Discord call and then using the the screen sharing tools okay thanks yes one another quickly um how do you ask your your co-workers to pair program with you without making them feel like um like they don't know what they are doing or like a burden to you or maybe you being a bden to them yeah that that's a great question and um yeah it's a lot to sit down next to somebody and work together every day there's a lot of social pressure and we

try to make that I mean one we're very vocal about that culture upfront just hoping that people are willing to give it a try and we try to set that expectation and make people feel safe um in practice I mean obviously again some of that comes to having the humility and just being kind to people um if if people give it a chance often times you'll find that like oh there's no mystery everybody else is also you know scratching their head and making mistakes and so if people give it a chance often sometimes I think they can see and learn that it's okay to not know the answer and actually it's a really fun problem solving to actually do it side by side um but there is a real hurdle of getting people to start and so the best you can do is just kind of invite that and and ask people to give it a shot and and you do want to make it as safe as you can um you know SP cycling through you know if you're pairing with the same person for weeks or months that can be really tough so also having a little bit of a schedule can can help too okay thank you hi this is a great talk uh on the pair programming since we're going off that how often do you pair program like

do they do it all the time or you do a start of a feature and then kind of break off yeah our team is quite extreme so we basically will pair um more or less full-time um but I don't think teams have to go to that length to get value from it I do think at the outset of establishing New Foundations and patterns can be a really great thing you know there's this idea of mobbing where you actually have more than two people working on a problem I think that that's a very hard thing to sustain because it's hard to pay attention if you're not you know in it uh but when you're setting up you know breaking new ground that can be a great time to kind of try to get everyone on the same page from the outset so I think that that is a great place to start hi great talk um I had a question about the scheduling so you had a slide where you're like forget this this doesn't work you don't have Story one story two you have overlapping stories and so my question about that is how can you plan that sort of schedule with

dependencies yeah so this is something that there's like pure agile theory that says like just don't have dependencies which is ridiculous like it just doesn't happen that way um so you know I mean one way to think about that is you're probably going to have a through line of who's working on what and so that sequencing is is going to be somewhat natural in the sense that clearly like if one thing has to come before the next um you know especially again we have that pairing thing but we will try to have through line meaning like one person might stay on and they have pairs like rotating in and out and so at the end of the day um you know you get into certain theories where they get into swim lanes and it's like oh we have all these different threads of execution at once I the only caution about going really hard on that front is that that very quickly turns into very siloed work where everybody has one assignment on their own lane and then everything's just going at its own different pace so um it's reasonable to think about swim Lanes in terms of like okay but there is a through line of this kind of shared thing with dependency but I would say that try to make that a

little bit more the exception in the sense you still want it feel like the whole team is solving the main priorities together and then if you have to deal with I basically it's just saying yeah you will have that be aware of it try not to get yourself in a circumstance if you can where you've got like three hard dependency separate threads because then it gets really siloed so I don't know if that helps all the way but I appreciate it thank you thank you hi I really enjoy the talk talk I I run a startup um with several people working alongside me on a a game we've been working on for a few years and we have kind of developed a crunch culture just because we have such a lack of resources that it feels like every update really is important we don't have any you know backing or anything so it's super big I mean I'm as the Director of the whole project I'm obviously responsible for this sort of culture but I wonder is there a balance cuz there are some times where it's like no this is a really critical time like you might need to come in on a weekend and work and I mean is some of that acceptable or

yeah I mean again I think we all do this cuz we love it and if I said that I never like worked late in my career I think that that would be pretty pretty false um I think the question there are two things that you have to account for as a team which one is sustainability which is like this may work may work for six months or a year but our people slowly getting burned out to the point where they're ultimately going to have to quit or leave the project or move on and so you really have to weigh that so the question like are you genuinely pushing in a moment and in a time where it's just like hey you know this is key to to what we're doing um because there have been times where I've been in the room with folks under some kind of Crisis and there can be some camaraderie built but if you're trying to sustain that every day I think it's really tough um one thing you know I was actually talking to um somebody on the plane over to GDC and he asked about like publisher pressure and he's like well what if they cancel your team and your Project's done and so you know one one thought there is that you have to have a steady state so that you can push when you need to and you hope that pushing becomes an opt-in

part of a passionate team choosing to do so with intentionality and a plan right I've seen teams that are just like well we're going to go you know eight or nine hours a day they're not pushing crazy on hours but they're like locked in they're like we're going to schedule lunch very precisely and we're going to be here in our seats like committed and even that can actually be hard to sustain but you can get a lot from being more kind of disciplined in the moment but if you don't have any pressure release then you're I think ultimately it's just going to be rough and so I don't know how useful that advice is but I would just say of course there will be a time in a moment where you're like well but I got to get this thing done but really ask yourself is this an exception and are the people who are there do they have the capacity to to try to make this thing come to life because they want to make it real and they've had the safety and the you know with with the day-to-day thank you thanks for the talk um I would I had a couple question questions one of them is regarding the discovery work so you mentioned that when reaching a deadline

um you should basically have less than less Discovery work so should you go to like a nice to have backlog or something yeah absolutely right and that gets like games are so creative so it's like sometimes the funnest things happen because somebody put it in there because they were just really excited about it and so I think having that kind of nice to have there will be moments in time again some of this gets to dependencies sometimes you got really critical stuff that's kind of is single threaded you can't work on it in parallel and so that you know there's an opportunity to pull in some less lower priority work that just polishes things out and makes it nice to have so you know I think it's critical to have a prioritized backlog you have to know what's most important in order but that doesn't mean you're not going to go deeper in the list and pull something up because it happens to fit who's available at the moment or what you know um so it's it's a dynamic thing so absolutely um sometimes those become graveyards and that's okay like accept that those things are probably not going to get done but sometimes there is those like really interesting little you know nice to have that people

will just put in because they've got you know time in between larger efforts okay and then the next question is regarding pair programming um do you me like do you mean actual like streaming one dude typing and the other one looking at it or is it more like a code review like I I'll submit this PR I'll work on this feature or this TCH Doc in which we'll plan together and then uh proceed to build it together yeah so I mean we do like full pair programming in which we actually are coding together and switching between who's kind of driving um obviously having that whiteboard session doing some planning together can still be totally effective so right we do some of that as well um so it it just kind of depends I think what you don't get though when you do a review or a whiteboard sketch is that you don't get two experts in the system you're still going to have that knowledge silos so you know it is a trade-off again I'm not being hyper prescriptive and saying you have to do it this way but par truly doing the work together is the way that you walk away with two experts um and doing those collaborations and code

reviews again can help they can create some knowledge sharing so they're absolutely useful as well thank you thank you for the talk um at the very end you were talking about some of the cultural um I guess statements you're talking that your company's been going through but you didn't talk about the process of developing those as like just like how did you structure those conversations and those organization points to like decide oh this point needs to be refined or this point is missing the general goal of this uh cultural statement yeah I I don't think I listed it in the um resources but the book I mentioned at the outset Pat lon's Uh the advantage it's actually a super practical framework for Building Company culture and it gives you some very nice advice about like here you know like go do it like this and so they there's some different activities that you know none of them are crazy but it's like we all got in a room we all kind of put together our own cluster of ideas and conversations and then talked about it as a leadership group it has to be

living so we have a literal Google doc with our it's called the company Playbook and those values are in there and we change them right and we talk about them and we uh we do a weekly all hands and I will kind of spend some time with the team saying like oh here's what I observed this week like hey we saw that some folks helped this game studio and kind of went above and beyond we're like hey that's the customer success so talking about it every week makes it way more real than most of what I've experienced which is we have these four bullet points that we write down once nobody ever looks at them again um so that can be really helpful yeah that's the thing we're really hoping to avoid moving forward so thank you for sharing that yeah the weekly um yeah all hands has been a really cool way to talk about it and sometimes we do talk about it in the in the negative like oh we said we do it like this but you know the unlock teams is hard right because we want coordination too yeah thank you thank you thanks for the talk uh I'll ask you something how to avoid knowledge silos in leadership positions and in places you and also when you are for example like I've seen many companies especially

smaller ones in which litter Crunch and so that the production team won't have to crunch so how to share this with the team without it being a burden to anyone involved in the process yeah I think that this is probably like the hairiest part of the conversation that you know we don't go deep on and yeah there's a couple different things that I'll think about and part of it too is now that I've I'm a lot further away right I'm not writing code every day um the two things I keep in mind are you know across your leadership team one you do have to have intentional processes and plans like we have to get together and talk about things but of course you know I think we all have some kind of meetings um there's a couple things so one there is this idea of like what if you paired on other stuff too which is an interesting one I can't say I've ever totally tried that um but you can but it is like how we're trying to build our cultural statements and values so we do try to you know we do two-day offsites with the leadership team to really sit down and talk at length about what's important for the business and how do we run our teams and who needs help and support and I know that none of those

are very like tactically valuable so I guess when we bring it back to running a team and then maybe leadership not being connected to that what I will say and it kind of came up in the story about the the crunch conversation at the outset of the team Builder project was if you're a leader and you can't see the team working every day there is a lot of fear that a leader is going to have because they can't watch the team running and operating and so there is a lot of work you can do if especially if you're a front lead try to make the team's efforts and experiments and iterations visible and that takes extra work so I'm not going to say that like that comes for free but I will say I've seen it both you know we now have like VCS and investors and like we have a board member who shows up once every three months they can't see what's happening at the company so there's real work you can do to try to make the teams work visible and I do think that that can create a lot more safety and Trust I mean a lot of us have lived the bad publisher relationship where the publisher shows up once every 3 months six months and they're just like show me all those features you committed to and you're like we're trying to build a video game and it can get really difficult so I do think not easy but you

put time and energy and making th your work visible even the failed experiments right even the stuff that didn't work because then it makes it a little bit more real thank you all right I think we're over time so let's uh do this as the last one thanks Chris uh so I was hoping you could talk uh one more time about the uh keeping teams together and some of the teams switching points that you made so in some of my recent experience um we have had some some team switching and that's been largely based on uh like moving from Milestone to Milestone or feature to feature and those have kind of required different resources or or different groupings of of you know people together I was wondering you know from your perspective is that always a a flaw in the planning or is that a necessary kind of just step in the development phase yeah I think that's a great call out because first of all like you know there especially there are certain roles that are probably you don't have a full-time need for that

person on the team every day um so I I guess I shouldn't try to make it sound like hyper prescriptive where like teams never change and we're growing as a company so our teams have to change because quite literally if we bring on no more people you know we can see the side of the size of what makes a a healthy team so they're two things that I've seen work reasonably well you know we had Motion Graphics and UI and some of those um creative roles that support specific parts of a project those tend to be more shared resource but the way you approach that can vastly change how that Dynamic Works what I've seen work very poorly is that person is assigned to four jobs at once and they're just like ripping their hair out running across building to team to team trying to do everything at once so that would be a very poor structure for that what we would always like to do and prefer is like you embed the person on the team and they may not be that long liveed team member based on the nature of the work they're doing but they can still show up and be present you know if you're in office physically they should be located with the team if you've got that if they're not whatever the team's rituals are they should be a part of

that for the time that they're there and of course you know you talk about like yeah but we got too many things to do um but at some level if you ask somebody to split their time across too many things at once you know so it's like maybe somebody could split across two teams but even that if they're going to every planning ritual and everything that gets exhausting so 100% you're going to your teams will change composition and maybe the next initiative you just need a different makeup of people but you want to be making small changes to the composition to make it work um and it also changes how you look for people we do really prioritize generalists who aren't afraid to work across boundaries you know they may not be the most efficient if they're not a deep expert but if they're comfortable just solving problems it does let you keep your teams more intact thanks Chris yeah well thank you so much again I appreciate everyone taking the time to be here thank you [Music]