Game Dev Teams Are Broken. Here's the Structure That Actually Works.

Hey Chris, thanks for joining. Before we jump in, I just wanted for our audience to kind of talk about a little bit of your background and then it'd be great to go into your post, which I thought was fantastic and had a lot of great lessons in terms of game development. But, um, just kind of going over your background, which I think is pretty impressive. I'll just go over really quickly, but production manager at Microsoft on Xbox, senior producer at Mojang, director of live and product at Relic, and by the way, I was at Sega before, so I I know some of those Relic guys, head of product at Offworld Industries, head of interactive at Misfits Gaming Group, and most recently principal producer at Hypixel Studios. So, I think it's fair to say you've got a fair amount of production experience, and I'm so glad that you've joined me today. But what I really wanted to talk with you about and for our audience is this post that you recently published on Medium called Structure Teams to Win. And I thought it'd be awesome to have a discussion about that post and to go

into a little bit more depth about what that post is all about. And just to set the context for our audience, let me just read a little bit of the first part of your post and then let's jump right into it. Okay. So, I'm going to read from your post. Let me know if this sounds familiar. Centralized design teams turn out untenable or disconnected paper designs. Engineering receives rough specs and overengineer solutions that don't meet the real need. Art departments generate assets without support or validation, leading to waste, endless iteration, or performance issues once they land in game. QA gets tossed broken builds with unclear test requirements producing swavs of bugs that may or may not be useful. The list goes on. So let me pause right there and let me also just just to frame the discussion for our audience maybe I could try to uh just give a highle overview in terms of like some of the key points of your post and then it'd be great to jump into it. But

if I were to summarize your post at a high level, the way that I interpreted it was so shifting team structures from something you call craftbased teams to outcome teams. So you're trying to optimize for product and the organization specifically. Then you also want to restructure teams for size and composition to be more effective and you actually advocate a lot for cross-disciplinary teams. There's also a set of principles that you think that teams should follow that you believe are common in successful teams. You also then talk about a set of specific challenges that you think that teams should be aware of. And then you end with a specific example for a double A co-op shooter organizational structure that just selfishly I'm I'm very interested in as as somebody who's working on that. But let let me kind of pause right there and hand it over to you. But did I get that roughly right or is there anything else that I that we should talk about during our discussion today?
No, that was excellent. I I think I

would just add that I didn't I didn't capture every craft or discipline in games. There's plenty that also have their own
uh maybe horror stories of of being in uh tough uh organizational structures. But um this was just a prompt for um I see you and I hear you and I was trying to figure out a better way as an organization and as a future industry. How do we operate better? So that was kind of the impetus for all of this,
right? Um,
and then before we dive into a lot of the the context and a lot of the the lessons and things like that, I also wanted to just also understand you know your motivation. Why did you write this post? And you know what was what was kind of why why did you feel compelled to write about this topic which I just just to be clear I think I think was really really awesome and an important uh important topics to be discussed in our industry.
Well yeah no that's a great question. So so I was I was curious to see how many bullets I could put in an article. That was 39.

So I I I will have future articles in the future and I'll try to reduce the amount amount of bullets. No, the the the motivation behind it really was I've seen so much friction in game development before. I've seen continual trains of articles about um you know this studio shut down or there's a failure on this game or what have you and so many times I've seen different teams from friends that I've talked to to organizations that I've joined where there's so much friction that's getting in the way of great people and it's just so much of the root cause is is a bad structure. Um and then a tendency is as sometimes as leaders is we focus on the symptoms and not the root cause which is our structure. So um I'd go back and say again it's usually not about the talent. It's usually about alignment and clarity and making sure that the team uh has has the clarity needed to function well and the least amount of o overhead as possible. So um team design in my opinion is the foundation for pretty much everything else. And as leaders in uh game development, I think uh it it's on us to to address those problems versus the more fun problems, which is

like what's the cool new feature or hotness I can add to my game,
right? And and just to pull on this thread a little bit more, I completely agree with you because when you look at the current macro of our industry today, what we're seeing is huge competition, right? We're seeing so many we're seeing one a glut of product and because we are living in an attention economy. We've got so many things vying for players attention and we're seeing like some of these former models and the way that game development has been done for years just blindly followed without really trying to adapt for the new environment in which we're operating in. And so I think it's it's it's a little bit egotistical in in my opinion to think that we should not really be having more introspection about how we operate and how do we optimize and to your point about the importance of leadership and the importance of really thinking about how do we do this right I don't know if you've read extreme own ownership by Jaco Willink but one of the things that

he talks about is uh teamboat six right that they had these Navy Seal Seal guys racing boats and then they took a last place team and a first place team and they just switched the the leads on on those boats and then the last place team became the first place team. So just an example of how if you take the right approach that you could potentially dramatically impact the outcome or the potential to have a successful outcome. And so that's why I really actually, you know, I really liked your article and it'd be great to kind of um go into depth about this, but let let's take like some of these issues from the from the top. And so maybe we can start with this notion of craft craft based teams to outcome based teams. Can you talk a little bit more about what you mean by that? And and obviously I'll I'll put a link to your your post for people to go into a lot more depth on that.
Awesome. Um, yeah. So, I use craft based, but there's you could say cross functional, you could say cross-d discipline. I like craft specific more

to games because I I believe are more games are art and and so I like the idea of craft. Um, that said, uh, this is common across industries that are doing more agile kind of game development or have been influenced in some way by like scrum um or plenty of other uh kind of publications. So I think another recommendation that that you've actually elevated before in prior uh podcasts was team of teams and it was so interesting to read that book and hear the uh the similarities between how a squad or you know fire team in the military is crossunctional cross-discipline craft cross um and we should I think based on so much of the learnings and and uh best practices that have been very positive in outcomes is that those teams work better and so how can we apply that to games? Um I I think part of this is not only that their composition but the fact that they need a very clear charter on what is their mission like why do they exist what are they working towards um in in many cases a team might be composed of maybe the right people but maybe they don't know exactly what

they're working towards and does that lad pause you right there just for our audience and so
uh could you give us an example for like a specific team what would like a team specific specific objective look like for for you?
One that I've seen uh uh work well is so here's an example. So, and I' I've worked on multiple games now with procedurally generated worlds. So, um I think there's an example here where you could say a team focused on procedural worlds. So, an outcome being um you know, every new world seed feels fresh. It's readable. It's performant. uh traversal and discovery naturally like you know surfaces your points of interest and resources and risks and um that's the goal of that team. So they're trying to build a new world seed constantly generated and something new and fresh. Um there's also easy ways that you can ladder this up to uh product expectations. So um and actually design expectations. So for example, one

that we we had captured before was uh like biome novelty per you know minutes or hour. So you could have an actual KPI against as a player I want to experience something new in a certain time duration. And so that gives a clarity to the team on the procedural worlds team
um of what they need to build and and hopefully that team has then been constructed with a designer engineers they've got you artists they've got everything that they need to go win in that mission. um versus what is more common which would be that you'd have disciplinebased silos where each that outcome that you're you're striving for has to be then kind of delegated and tasked out between monolithic different silos. So and the handoffs the the games of telephone the loss of fidelity of the intent gets lost between each one of them and usually the partnership's not close enough to win in what we're asking them to do.
Right. And and maybe if I can just jump in here a little bit as well. I I think like what you're talking about is kind

of a it's a powerful concept, but I do think that um it's underestimated how important having a very specific goal is, but it's it's kind of like the notion of having a northstar KPI in live ops, right? Like because the team is really oriented around something very specific. It's not like the goal being, hey, let's make a successful game. Then all sorts of people can be doing all sorts of things, right? And I've also talked about
what I believe the the coming like really important basis of competition for teams in the future is going to be product velocity but without that specific more specific goal you could have you won't be vector aligned right and so you could have all these guys doing different things but it's like okay what is the specific thing that we're trying to accomplish or what is the biggest fire the biggest problem that we're trying to resolve so again I you know not not to uh derail your your you know what you're talking about but but I I just I just really wanted to

tell you that I resonate with what you're saying and I think it's a very important concept.
Awesome. I I I do want to to layer in here is that when I try to if you're looking at the article, if you're looking at the the organizational design that I came up with, I try to keep teams somewhat um or kind of the the teams their composition uh
and their outcome that they're chasing somewhat immutable. I I shouldn't say immutable is it means that they can never change. But what I'm trying to to kind of convey here is um what we don't want to do is continually change the goalpost for a team trying to deliver. So if they're outcome is more broad and you know that's a huge component of your game. You know you'll need enemies or you'll need a meta or you'll need combat or you'll need something that will be sustained where they can gain excellence in their area, a better understanding. they'll get a better relationship between their teams and they won't have to continually to repeat the storming forming norming performing cycle. So when I when I come up with some of these um ideas around how do you anchor a

group of people around an outcome you try to keep it something that you're very confident in around you're going to ship this to and likely live operator. So I want to call that
and maybe I can also follow up on this point too because I I think what you're saying is actually aligned with the concept of scrum, right? Because when you think about a sprint, a a sprint should resolve into a PSPI, a potentially shippable product increment. So if you're in a sprint and you're just continuously changing, oh, we're going to do this. Oh no, we're going to do this. you just have confusion versus and I've seen so many times
you end a sprint and you don't properly retro or reflect upon okay what do we have now what information does that give us and then we reorient around what's the next mission or things like that so again I just wanted to there's a reason why I really liked your your post Chris so so so anyway please continue um and I I would say maybe the next point we I I do want to touch upon is like the team composition and size. But do do you have

any other points in terms of the outcome based teams?
I just want I think I would want to leave this to hopefully so it resonates with people who might be skeptical is that um like maybe a sports analogy which I'm not going to give us but I mean it could be football or soccer or what have you. Just imagine though if it's American football having or fielding a team that's just quarterbacks would absolutely get wrecked in in any kind of competition. So arming a team with the right people with the right skill sets to go win in their mission is critical. So I I just would I would try to hit that home that that the team composition not only uh the humans that make it up and do they get along well with each other but also their skills they can bring to the table. Can they actually execute in what you're asking them to do? If if the answer is yes, then I think you've done a really good job in terms of trying to or organize a team.
Yeah, I I totally agree. And to your point about really trying to understand what do you need? Like what roles do you need? And I like that analogy of of sports because often times and you know I'm a big college football fan but like

you know so often people orient too much on the skill position like the quarterback or the wide receiver whatever and it's like guys it's the lines right the offensive line or the defensive line. You don't have that you're you're host. You can have the world's greatest you can have Tom Brady but you you have a bad off offensive line. You're you're done.
That's right.
All right. So, so maybe now talking about and I do think that this is where from a macro perspective as budgets have gotten bigger, it is what we've seen there's been a huge orientation around like like production quality and graphical fidelity and things like that and we have seen bigger and bigger teams and so maybe you could talk about this notion about team size and team composition. Could you talk about that a little bit?
Yeah. So, so I I think uh well, what constitutes a team I think is is anything greater than three people together, right? So, if you if you have uh more than three people, probably even two, you call it a team, but three or plus is is a probably a good starting point. Um but where you start seeing um

some substantial uh communication overhead is when you have more than 12. I'd say my sweet spot I I would recommend is three to nine individuals, but sometimes you need to add a couple additional more. Uh but there's some there's some good graphs you like go Google and go see like if you even try to draw the communication lines between 12 people it's just an enormous amount of touch points that an individual on a team has to go navigate if you're expected to go coordinate or collaborate with the other people on your team. So keeping your team smaller and especially when you're more outcome based is uh they can build more substantial relationships trusting relationships and uh and be able to work more effectively together with less communication overhead. So, I kind of lean on that that team size. So, they can be smaller, more nimble, and more trusting in terms of working together. Um, but I I think I've seen this kind of uh affect more things than just, you know, your communication overhead. It could be something like your meetings can be extremely difficult to to manage or make

meaningful if you have too many people in them. Um, so if if you're trying to do a standup or you're trying to do a retro or what, if you have too many people in there, it can be really hard to be constructive. So, um, also I I I do try to weigh and consider individuals who might not be so extroverted that they will punch through people talking and try to have their voice heard, right?
The more people you have, the the less that you're going to hear from some of the more quieter voices that have a ton of value to add. So, I I' I'd say when when building out an organization, not just the team, try to scale horizontally and not, you know, not pile more and more people on and try not to do more vertical if you can. Um, but try to keep that sweet spot of I'd say 3 to 9, 3 to 12 people uh in a team,
right? And I I I like this call out because even for me, I have noticed over the last call it two years where I think that there was been a failure on my part where we've had somebody who actually left our team and then we're like, "Oh, this person left the team. We should try we'll try to hire someone else to

replace them." But then it's like, wait a minute, the team's actually producing more now. They're moving faster now. Okay, there's something we did wrong or we didn't fundamentally understand about the team structure or the outputs of the specific team members because we subtracted but then we added and so what what happened there? So that was clearly a leadership failure or a failure for me in terms of trying to understand, wait a minute, you know, there there we we had too many quarterbacks or something along those lines. But
but so may maybe we could also dive into this a little bit more when you do think about a specific team oriented around an outcome to your point of may outcome for procedural content or things like that. How do you think about this? So, not only the team size, but then what does that team how is that team composed? How do you think about that?
So, I I think of just trying to balance,

right? Try try to have balance and then the skills needed to to win in their outcome. Um I think if we tried to to break down so the balance I kind of I I I share is that and I don't want to go down the EI DEI route but I'd say is like I've seen um some personalities or individuals struggle to connect or uh you might have conflict and trying to resolve those or either try to reposition people onto different teams where they they are more compatible is really important really just for the people that you have on the team. Um but then also try to have different perspectives on the same team. So I I have uh I have stories or people where where I've seen a team was composed of say all all male and it was just it was it was all male and then when you added a couple different perspectives to that team the dynamic completely shifted and you started getting some really interesting perspectives. So I' I'd say the the composition of the team really try to think of balance when you're when you're looking at uh the team that you've constructed and then also what is the target demographic you're trying to address. So so if you if you can build a team that is more representative of your

audience that's a big win. Another comp component of this that I'd say for composition um is I've seen so many times where say you have um a creative or artsheavy um outcome that you're looking for. So say you're trying to generate a bunch of skins uh or say you're trying to generate rewards for post post sale content or postale monetization content. Um
uh in many cases you have just artists output out outputting content, right? So they'll they'll build assets and they won't have support from say even technical art or say an engineering engineer and you'll run into all of these downstream second factor third factor problems where uh they're constantly breaking the build or their assets are too large or um or um the tooling is so heavy or so constrained that they can't actually output as much content as they could. The moment you start having those other disciplines to support each other, they know exactly who to go to. They'd have an engineer at their disposal. they have a a technical artist to support them. Suddenly their output can drastically improve. So again

that balance component of if they have everything they need to win in their outcome or or their role or their expectation, you should see some substantial uh uh uh velocity improvements. Um so I think I covered most of what we wanted to cover.
And maybe I can also just jump in here a little bit as well to just provide my own
lessons from my own mistakes, right? Because I've made so many over the last five years. But so one of the things that that you mentioned in terms of like the the team structure and composition. Uh one mistake that we have made was for example we had a separate product manager that was kind of um overseeing or working with design team and then with engineering. And one of the things that we've done recently is have the same product manager that that actually works with both teams. And so then what had happened is that the communications overhead dramatically reduced. And what we used to have was design would throw a spec over to engineering. Engineering would do some stuff. Things would get

kind of tossed over the fence without enough context and with a lot of this overhead where now that we've got kind of like the same person. It's we're seeing a lot faster velocity. we're seeing less overhead, less necessary meetings and things of that nature. And then the second I think nuance here would be where as I mentioned before where I've noticed that we've had addition by subtraction then it's like really thinking about okay if this team's objective is X what do we actually need? What kind of to your point what kind of people and what do we need to be good at to be able to deliver that the best? And I think there has been too little introspection about um your your concept of composition. So there's a team size aspect of it and then on on the composition side, what do we actually need? Right. We we need we need better alignment. We need a good this or that, right? And so I I really

do think that that your point on both of those aspects of really critically thinking about the team is very important.
Agreed. Agreed. And with that, if you don't have any other comments on that part, I'd really love to now go to your point on a set of principles, right? And there were a lot of them. So maybe we don't go over all of the principles that you mentioned, but
if you could point out a few of the principles that you think are important and that you can
that you can discuss here and and again I'll have a link to your full post so people can go through all of them, but I thought you had a lot of great ones, but if you can pick a few, what do you think are some of the key principles that game development leaders and people on a team should really be aware of when when they're when they're trying to optimize for success? So the first one I I I I want to hit home because I've seen this too many times now is uh in in sometime I know I

know probably this audience listening is is more product and orientation maybe um so maybe this is crazy to you but in many organizations I've joined there isn't a clear product vision so there isn't a clear uh written shared
I don't know what you're talking about Chris
regularly provided reminder of what the heck we're building and for and who it's for. So I' I've joined or
yeah just just sorry just to be clear I I've made that mistake many times and and the thing is I keep repeating that mistake. So so so so please continue.
Okay. So so I' I've joined organizations where uh we're trying to build a game. Sure it's it's crossplatform but one of those platforms is mobile. Um well when you're building mobile you need to have design considerations
right
baked in much earlier. So keep that front and center. If that's an expectation of your team you could outsource that and that that maybe it's not a problem. But if you're trying to own a particular platform, a demographic, an age, that needs to be captured and echoed through the whole organization and then also echoed in your organizational structure. So if

you're looking at trying to do um you're trying to tailor towards more, you know, 9 to 12 audience kind of 9 to 12 year olds, um that needs to show up in your designs. That needs to show up in in what you're making and to keep the team accountable. I've seen so many times where um that has not been the case and we build a game that that doesn't actually service the audience that we're shooting for, right? And that that can latter beyond this. So, so not just like who who's it what's the, you know, the product spec, but it's more like um it's also helpful to know what the actual vision is and to repeat it constantly. So, I'd recommend you're doing it, I don't know, monthly, weekly, as much as often as often as possible where you really know and your audience knows, especially your organization, what exactly you're building for. um so they can build the right thing that you're expecting. This is all part of trying to drive alignment with all the people that are building your game without having to tell them what to do. If they know what they're building for and why they're building it, they should start making their own decisions in the right way that ladder to what you you expect. But

if it's only in your head um or or only in several people's heads, it's it's not going to ladder down, right? So I'd start I'd start with that. It needs to be super clear. Um, I've seen so many times where teams deviate or they're building something or as you have these more autonomous teams uh operating separately, if they don't have an aligned vision or aligned product definition, um, they're going to build a different game. So, you might have 10 different teams building 10 different games. So,
100% agree on that. And this also goes back to that concept of product velocity, right? The more you have that well articulated vision, the more vector aligned every team is against that. So, yeah, definitely want to um let you know I completely agree with that.
Awesome. Um and what I don't mean to say here is that you can't change it. So as as you learn new things as part of the some of the principles I've listed is like it's really important to iterate and inspect and adapt. Um this should also happen for your product vision and all of that any decision made regarding affecting it should also be rippled out

to the whole team. Everybody needs to know what's going on. Um I think in team of teams they talk about shared consciousness. It's which is I just I'm usually going a shared understanding but really the idea that the whole organization understands what the leader's intent is um and they'll hopefully march to it. you might have some other problems with that, but if you don't convey what you're looking for, you have you have no hope in them doing what you expect for them to hit your expectations, right? So, um, and I I keep saying you I I guess I'm not talking directly at you, Joe, or the listener.
It all applies,
but yeah. So, that that's kind of one of the biggest ones I wanted to hit home um because I've seen it so often. So,
right,
I I I could layer into the kind of the next one. I know when I've proposed um organizational structures that are outcome oriented and more scrum or uh you know cross-d discipline in nature cross you know cross craft in nature there's an an inherent or kind of a immediate rejection that okay you're

going to take our engineers and split them off you're going to take our designers and they're not going to be you know coordinating to together how how are artists going to have any kind of oversight in terms of what the art director's vision is and um I want to hit home that when you do these kinds of pods or or craft based teams. You still need guilds. You you still need your craft leaders to be front and center on their crafts. So, you should still be doing PR, you know, reviews. You should be doing um art asset reviews. You should still have regular check-ins, discussions, knowledge sharing across your disciplines where they can benefit. Um so um I I I want to touch on this because I know there's a resistance that oh if we get rid of our discipline silos that we're going to lose uh that knowledge base the understanding expertise in our particular uh disciplines and that's not the intent you should still try to retain that through some system of of connection like a guild. Um
right and Chris just just just to kind of pause you real real quick. And so when when you think about like the potential organizational structure or

the mental model that you think about when you think about outcome based teams and guild leadership, are are you thinking about kind of a structure that's kind of matrix in nature where you've got pods that kind of go horizontally, but then you also have like discipline leads or guild leads that kind of cut vertically essentially.
That's right. That's exactly right. Great. Yeah. Thank you. Yeah, that's that's exactly what I'm and matric matrix based organizations can get very complicated, but that's there's only two I hope there's only two axes there. I think I hope it I hope it's just discipline and just and then your outcome based teams, but I'm sure it can get more complicated than that. But yes,
um yeah, so I wanted to call that one out as well because that usually get there's a lot of resistance there. Uh and and there still is craft need, craft guidance, craft management that should still exist across all teams. Um I I'd also want to to feed into this uh knowledge sharing even across g you know guilds and crafts. So if you have an opportunity to share um uh record um

invite anybody who's interested in terms of if you're doing a weekly design check-in if other you other crafts are interested they can benefit from from overhearing what other disciplines are facing. So, um, you you can you can elevate that shared consciousness by having more open and honest conversations, uh, more transparency, and then also overlap between disciplines if they're interested and want to hear more. Um, all right. I think I I think I would probably wrap that piece up around guilds, cross discipline, having your own uh, kind of matrix organization in that regard.
That was a good one, too.
Awesome.
You only have really good points here. So, yeah, keep rolling. Keep going.
All right. Um, so I I want to touch on autonomy, which is which is scary as a a leader and I've also had my own failures of of not or overstepping my leadership bounds and not trusting a team. So I think uh kind of stepping back and going what is our job if you're in if you're more senior roles um uh we're really

shepherds and gardeners of our organization. So um if you can uh give a clear product intent, you have clarity on uh teams, their roles, their outcomes that are expected of them and clear expectations, your job is to make sure you have the right people on those on those teams to then go execute against what you need. Um what it isn't or what I wouldn't re recommend is that you try to dictate almost everything to those teams. You try to empower them. You've given them every resource they need to win. Let them run and let them learn and and fail. Um, and uh, but also trust and verify. So, still verify how they're going. You still need regular check-ins, but try to give them as much autonomy in their space as possible. Um, and what you'll see is so go back to the football analogy. If if the head coach had to make all the calls in the middle of a game, it would be the slowest game and the most ineffective way to to run a team. So, you need to trust the players on the field to go win in their game. That doesn't mean that uh you're totally checked out. You're still there. You're still coordinating. You're still giving guidance. There's still strategy. Uh,

but there's uh you're letting the team play. You're letting them run.
I think like this is one of the I I would say like this this concept that you're talking about is probably one of the hardest parts because I for me I think there's so much situational context in this, right? In terms of okay, is the team junior or are they senior? Are do you have alignment? Do you not have alignment? And then and to some degree some leaders give so much autonomy that some of these people or these teams are the way that I've described it. I don't know if this is a a good analogy, but kind of like islands that just kind of float off and and they're like you don't and so the the point that you you raised about trust but verify I I also call it the observer effect where
you have some level of like understanding are we achieving the goals? Are we getting there? And so so so yeah to your point you don't want a completely micro
but there needs to be some macro alignment and there I do think that

there needs to be some checks that are situ situationally constructed because you could have a team that's senior that's completely great and so long as you're like highly aligned they just get stuff done. Like in as an example, we recently hired an art director who is so good and the only thing like I'm I'm even telling him I want to be less involved, right? Like like you're so much better than me at at at art. Like like sure you Yeah. He keeps sending me stuff, but I'm just like man this stuff is awesome. And and then there are
other teams where the people are so junior that they need more micro. And so like I I would say like the balance between macro and micro does need to be a little bit aligned. But to your point more generally as the teams get better and better so long as you've got like that alignment on vision and like the macro is aligned I I think all the micro like the ideal scenario is you are completely hands off on the micro.

Yes. Yep. Which I I haven't entire I've never I don't think I've ever seen that. So so I don't think you're ever entirely hand hands off but so so I'd recommend two things. One is actually kind of piggybacking off of what you mentioned was if you have a lot of junior individuals on a team, that goes back to balance. You might want to rebalance that team to have a little bit more senior leadership or just just senior individuals that can help keep them on the rail. So, you don't have to. Um, so so if you can delegate some of that power down to individuals that you trust, that's also a way to to to build some balance into the team. Um, but sometimes you can't do that either. And so I've also had to be more involved when needed. So I I it's a
it's an inspect and adapt kind of situation again. So really when when you run into those problems, try to try to deal with it as much as possible. But if you keep in your mind, how can I keep them as autonomous as possible? Then you're probably going to do the right things,
right?
Um and and like one of the concepts that I've talked about before is you go to like this is the um
uh I forgot the the name of the secretary of defense from like years back who talked about you go to war with the army you have, not the army you wish

you had. And so sometimes you you can have
um so yeah so sometimes it it it's like yeah we just hire a senior person but it's like oh where is that senior person right
but so you just have to kind of deal with the situation that you have to to your point
agreed uh the last piece of that that's important is from my Microsoft days they they call it a rhythm of business which you're establishing kind of a regular cadence of check-ins reviews whether it's an MBR or monthly business review or if you're following more of a scrum uh or defined framework work like that, they have bakedin reviews, right? So, so as a leader, if you're every sprint be able to have a have a look at both the build uh the current status of their backlogs, you're doing regular play testing. As leaders, hopefully you're going to catch much earlier, you know, in a regular cadence every two weeks. Usually, a team can't go too far off into left field in that timeline. So, if you keep a small time box and they're iterating and you have those regular check-ins, you should be able to keep keep your eye on the ball as far as where the team's at. So uh and then give

you know good candid feedback. Um so I that's where I'm also a fan of of some of these frameworks and then staying you know close to the team. Um so yeah there are ways to to to um navigate some of those those issues and there don't get me wrong as we maybe we'll touch on some of those challenges there. There definitely are challenges. So don't get me wrong.
Yeah. Then I I think that last part is one where I mean I've talked about this a lot before but you know the way that I think about a lot of companies is as if you think about it in a simple way people and product and in my experience there are so many people that are so like they have so much complexity on the product the kinds of analysis all these fancy ways of examining and and optimizing the product but then
you know ultimately it's a people that make the product and so if you're like completely ignoring the people and not having feedback to also improve the people then you might run into problems

and what I've observed is the other way to look at this is like the the more senior experienced and advanced the people the less process you need and so then what is the right level of process well this goes back to this discussion about the situational context of the team the more junior you should have a a little bit more progress checks, you know, different kinds of checks where on progress because they are so junior and the the better your people, the less process, the less all that kind of stuff. And so
that's the art and I think that's the the part that is so difficult about what we do but so also interesting and complex
is like navigating exactly how you kind of create these these kind of processes and practices that are optimized for the team that you have.
I am uh so my background being p prominently mostly production um might be crazy for me to say this but I'm a process minimalist. So whatever I can

possibly get away with with the least amount of overhead I will. But as mo as most things as you you find like a governmental regulation is usually when something goes wrong you try to adapt and try to prevent it.
Minimum viable process for the team you have essentially.
Exactly. Exactly. So you you got to adapt per team and per team composition and and that's part of that kind of storming norming performing phase is that you're trying to figure that out. But the more that you change people around or move compositions or move leaders, you will need to reset some of that because you'll have different uh kind of levers and strengths per per person per team. Um so it's an ongoing battle. It's never ending and it will always continue to keep your job interesting,
right?
Okay.
Um should we go to challenges or do you have anything else?
Um I think the last piece here that I wanted to call out is uh is safety um and more psychological safety. I know this is a a buzz word uh somewhat and um I think it's important to call out that you need to have a group of people who trust each other, feel safe with each

other, can have that radical radical cander, who can be safe in disagreement or um anyone in any role can put their hand up and go, hey, I think this isn't the right call or I think this is going to there's we're going to have some issues down the line or players might not resonate with this. Um having that safety and uh making sure that leaders model it and your retros reinforce it is incredibly important. Um the the more quiet a team is. I I remember I was in in an org where um we had a feature kickoff and uh our leadership was celebrating that no one had any questions. So uh and this was a big system that was being designed and conveyed and the fact that there were crickets and everybody said this is great. uh they were thinking was a good a good sign. And from my perspective, that's horrifying. That means that people are not safe enough to to to ask questions, to have thoughts. And if you're in game development, you probably have a lot of passion. You probably have a lot of opinions and thoughts, and doesn't mean that you have to share them all, but someone should be able to say

something when you're reviewing some some piece of content or system or design or what have you. So, um, I would just want to call that out that there are real tangibles around psychological safety that if you're not seeing the components of that, you will not have a very performant team and you will likely miss some icebergs that you're sailing right at. So, I I wanted to call that last piece out.
Yeah. And just to also add a little bit of of my thoughts on that as well. So, I was I had the opportunity when I went to business school to actually go abroad and study in Japan. And I went to this university in Japan where one of the professors is a guy by the name of Ikujiro Nonaka who kind of came up with the concept of scrum. I mean he didn't come up with the very the specific practices but the idea of scrum and he actually also had this concept that he called dialectical synthesis. And essentially the idea of this concept is that the only way to achieve new knowledge is by having like completely opposite perspectives or opinions on

something and then you discuss and debate discuss and debate and there's like this kind of whirlwind that happens and then through that discussion and debate you reach a new insight a new knowledge that can help create a better product and to your point like I have been part of so many teams where it's weird like there were some companies where you know you there be a big room of people discussing something and essentially what would happen is the the the highest ranked person in the room would say something
and then and then it's then maybe somebody else who's higher up would say something else and everyone would just change their opinion and change their thoughts to whoever the highest ranking person in the room is and agree with that that person and I I just like in some of those memes I was just like this is so weird. This is so bad. I need to get the hell out of this. You know, like it's just like what is going on here? But uh but I do think that that is a common problem in our industry where

because of the safety issue and because like people just want to get ahead and like it's like oh if you agree with me then I'm going to promote you. Like that kind of culture is just so bad. But unfortunately, I do think it is a bit common in some companies.
I it's extreme extremely common I'd say in in my experience as well. Um I I read a book recently, Team of Rivals, about Abraham Lincoln and his ability to form a team of actual rivals that really wanted to kind of undermine him in some ways. And so much of what he was able to overcome with a rival is that he built trust and would stand by them and listen to them and empower the hell out of them. And um when you see that kind of an environment, I think Google did a study on this too about like the health of a team will skyrocket and the performance of that team if they trust each other. So um I know I I hear that sometimes like everything starts with trust and it's like but it's real. It really is real. If you can build that and build a culture where people can talk and speak up and and and advocate for their ideas, um you're going to have way better outcomes. So yeah, I totally

agree. I I never heard of that though before. That's why I listen to your podcast.
Thanks. Yeah. And and I also think like it's there's too many times I think leaders really do need to emphasize like for me personally like we're a startup
if our product fails everybody's time, energy and effort gets wasted. So like I don't want to win a debate. I want to win the product right because like ultimately if the product succeeds then everybody wins I win. I don't really care about losing an argument. I want the product to be better. And so many people kind of too many leaders let their ego get in the way. Yeah. And it's just it's so unfortunate.
Yep.
All right. Should we go to challenges?
I think that's great. Yeah. So, one and I don't I my wife asked me why this happens and I actually don't know. most I'd love to know what you think is this idea of cognitive dissonance where a leader believes that they are doing the right things but it's not actually lived

you're not actually seeing it executed. So, and this is common if you if you're a prior scrum master or someone who's trying to, you know, roll out agile, you can have a common conversation with someone where uh you'll ask them like, are you, you know, you running agile? What kind of agile? What's what's your framework? Um, and they'll go, yeah, we're we're totally agile. We change our plans all the time. And and it's like, well, that's not that's actually not that's not what agile stands for. It's a set of values and principles that you try to try to, you know, enforce across your organization. Um but in their head they truly believe that they are right so they they think that they're they're actually doing the thing that they're saying. Um and in in many cases uh this happens all over the place, right? So they might think that they have designed a system of humans or or an organizational structure that is actually outcome or product oriented or um healthy. Um and yet you look at it and things like they're moving people all the time so that you're resetting constantly the you know that cycle of storming, norming, performing. uh or you'll have you know more strike teams

that are temporary so people don't get anchored together well or uh they could be more um a kind of bucket or area you oriented where you'll have a systems team that's bottlenecking everybody and they won't try to address it you know so I think there's these areas where um cognitive dissonance can be very dangerous where where you think that you're doing something right and I'm I'm sure I probably have done it and yet in practicality it's it you're failing. So I I think I wanted to call that out of that um it's really important that as leaders we keep looking at ourselves and getting you know getting feedback um I'm a huge proponent of trying to take a pulse of the organization and and try to listen to the to you know your boots on the ground your frontline workers um uh around what things are going well not going well and try to constantly adapt to it. So I think even with a great outcome oriented organization, you still need to challenge yourself and go, I don't know if this is still good enough and could constantly try to improve. So that has been a challenge I've seen and

I'm curious, Joe, if you've run into something similar.
Yes. And I think for me there's probably three concepts associated with this phenomenon that you're talking about in in my opinion. I think the first is you actually know what's wrong but nobody wants to admit it and especially in organizations where there's there's high you know there's high pressure
and if you admit the mistake then that could have political consequences for you or there's an ego issue right so like you kind of know the mistake
but you don't want to admit it I think that's one part of this I think the second thing has to do with this notion of progress checks and really checking to see, okay, we made a change or we're doing things in a certain way. And that level of introspection where you think about, okay, we are doing things in a specific way, is that effective or not? And actually trying to check and measure, is the way that we're doing things

better or best or are we doing it this way because we did it this way in the last project or people are comfortable with this specific approach. But we live like we're operating in one of the most dynamic and competitive industries in the world. Right. Yes.
And so like not having that level of of both introspection and checking to see is this effective
is the second part. And then I think the third part I kind of wrote about in the last newsletter which was this notion of the the uh the aliens eye view concept which is what you think you're doing and what you're actually doing could be something different.
Yes. Yeah. Yes.
So so I think for me those are kind of like the three concepts associated with this phenomenon this challenge that you're talking about. Mhm.
And certainly I do think more people should really be thinking critically about these things. And again, you know, I high praise for you and for for for

your post, but this is another reason why I I loved your post so much. But
awesome.
Yeah.
Hope hopefully others hopefully it resonates with others too because I think I think if we can try to navigate some of these challenges together as a as an industry, we'll we'll come out the other side much healthier.
Right. Right. Absolutely. There was one other challenge I wanted to share because I I know this is this is a common uh almost one of the first things that'll happen if I try to present an organizational structure that is cross discipline in nature is you can't have a specialist on every team which is legitimate you can't it's it's cost it's not it's untenable you can't you can't do so for example for for one of these would be you can't have a you know UI artist on every team that's working on front end and that's a legitimate challenge so um what I would recommend to try to navigate this and there's plenty of disciplines in game development where uh you can only have a certain amount of them. Uh there's two ways to navigate and if you look at the article and look at the org, I've I've dubbed a team called the catalyst that can kind of come in airdrop in and support a team uh in their respective outcome by supplying their skills for

maybe a temporary amount of time. Um but they still have an identity. They still have a catalyst team that they can corally around and still still have um a connection with regularly. Um, so that's one way to navigate that problem of you have all these specialist needs, but then how do you support each team that needs them is try to airdrop from another team. Um, I'd also encourage that it is healthy and good for an outcomebased team to support a different team. It gives empathy, understanding, they understand what each other is working on, their priorities, and suddenly they'll get more kind of uh back and forth. How can we support each other in the future and and more kind of transparency there is very healthy. So, I would say even if you embed, which I would I would recommend, embed a uh you know, a discipline based resource onto a team, it's okay if that team supports other teams. They should, but I think it's a really healthy dynamic. Um uh so yeah, so and I so those are the two things I I would recommend. If you run to that challenge of yeah, no, we can't have an audio designer in every team that needs one, then try to do some kind of an a hybrid model. Um, and uh, I'm

also open to ideas on how to navigate it, too, cuz it's almost always imperfect. Yeah. And I I think to your point, Chris,
kind of like the the challenge with what you're talking about, and I think and and by the way, as somebody who is not great at this, but who's trying to get better, is that I I think that when we look at the overall macro and potential sources for alpha or competitive advantage, a lot of what you're advocating for, if we just kind of step back for a moment and think about what you're advocating in terms of how we can be more effective is really kind of if if if we think from a high level it it's advocating for a team that is much more fluid in nature you know like
if I were you know quoting Bruce Lee it'd be like be like water you know
but but like so often like the game development philosophy

structure that we've been that most people have experienced in the is very rigid, right? Yes.
And I think the ultimate expression of this is like if you see how like an Ubisoft team works,
very specifically siloed, very structured, very rigid. You only do this. Don't talk to these other teams. if you want to talk to that person, you talk to this. You and and and I guess what I'm saying is like what you're advocating for I think is right, but I also think is very difficult because it requires a change in mindset, but also requires a change in skill in how you think about things and the things that you think about so you can kind of dynamically adapt and make your team as efficient and effective as possible. So on that side, do you have any thoughts or specific processes or ways in which I mean one thing I have advocated for is you know we haven't talked about AI and

I I thought we could get through this conversation without talking about AI but one but one of the things that I feel is important with the impact of AI in game teams is having kind of the notion of a role of an orchestrator of somebody who can kind of go go go in and think about how do we apply AI to different teams and different ways different capabilities emerge and then how you apply it but to some degree that person whether it's a producer or a PM
it feels like there needs to be somebody who's thinking about these issues who's thinking about how do you make your who who like really looks at the different the organizational structure shifting one team to do another thing like that kind of a person or that kind of a function seems necessary. I haven't seen that and we we kind of just try to do our best, but it seems like that should be something that that teams think a little bit more about.
I totally agree. Well, so as as a as a as a producer, I I I would advocate for

having some production staff that can help you with that. Um like EA has development directors that are almost entirely focused on actually I don't know if they're focused on organizational structure, but certainly on your project management side of things. Um but I think what's really important is to do that someone should be looking at your organization looking at how can we optimize how how are team how how are people working together um and can we improve it um always and if if it's uh it could be on a leader it could be on production it could be on a discipline um but I I agree I wholeheartedly agree with you that it should be a capability or a a focus as an organization if you want to optimize your team
okay and Chris one of the last things that you included in your post was an example organizational structure. And I'm really glad that you actually provided like a concrete example. And again, as somebody who's working on a shooter game, I thought it was awesome that you provided an example for what you were calling a double A shooter team. Could you walk us through how you

kind of came up with that structure? Maybe you could describe the structure itself and some of the thought process behind that organization.
Yeah. Okay. Okay, so let's go over the shooter org topology. Um, I'll start with the different teams that are on it. And so hopefully it'll it'll kind of uh come together in your mind. Uh, first would be combat oriented. So a combat oriented team, an enemies or opponents team, uh, expeditions or uh, he could do worlds or uh, you know, levels or missions uh, team uh, but expeditions team, a meta team, foundations and multiplayer team, and then a catalysts team. So I kind of hinted at catalyst previously, but those are uh specialists that would need to be kind of air dropped in uh to support each one of those other teams. So um how did I come up with these? And there are some outcome texts that I've listed and I I can read them off later if needed. Um but I came up with them by thinking through the product first. So in this case, I was thinking um uh like Left 4

Dead, like a Left 4 Dead game. um or I didn't really think about an extraction shooter, but there's also some really good this could be a Hell Divers type style style team or or something like that. Um but what are the core capabil or what are the core areas of the game for it to be successful and how can I anchor people around it and what's most likely not going to change? So unless you totally change the the game, the genre, uh most likely all of these will be needed forever. So you could you could anchor people on these areas to get good at them, build relationships and then start executing very well um around combat, enemies, expeditions, meta, foundations, multiplayer and catalyst. So um the idea is that how do I map these humans to the product that we're trying to build and they have really clear understanding of what their roles uh what's important to them and and their focus and how can they support each other in executing in it. So, so essentially it kind of sounds like what you're saying, Chris, is that you you're looking at a product and I'm I I think it's an important point to underscore

that you're you're starting from the product trying to understand what are the key capabilities, features or things that are necessary for this game to actually be good. So what are those important levers, important things? And then you're trying to construct teams around those things to make sure that those are good because those are the things that would probably drive the success of the game the most. Is that okay?
That's exactly right. That's a great great summary. Instead of starting with what disciplines are most likely needed, it's it's oriented around here's your product idea. How can we best build an organization that can succeed in building that that product? I think in your case we could morph this a bit. Um you likely need people focused on you know live ops and economy. So maybe a marketplace team. Um also backend is going to be a component of this. So there there are different capabilities that you'd probably want uh included uh in this outcome oriented structure that will make sure that when you ship your

game you have everything needed to to be successful at it. Um, the more traditional approach to this is trying to come up with all of your features ahead of time in a big plan and then try to come up with your scope and capacity and estimate all this at day one and then hire all the people you need in pre-production scaling into production. Um, and that has is rife with so many problems as far as most likely the product's going to change. Most likely the people you need likely will change. Even the capabilities of the product will change. Um so so trying to start with that comprehensive of a plan up front versus looking at the people in your product um can have much better outcomes if you focus on more of like what are the product areas? How are are you arming the right people to win in those respective areas? Uh and then you'll also get some really good early signals of how much is this going to cost? How many people do we need? Um and how much focus needs to be there. Right? So,
and maybe one other follow-up question I have on this topic is the notion of of

for example, if you have a big product like a like a shooter game, you certainly would want to hire a lot of folks there and you might have a big team of like 40 people that you could specifically dedicate to those teams. Mhm.
But you know, one thing I actually also did recently is I studied what are successful games more on the PC side actually and so looked at a lot of these teams where it seemed like a lot of teams that were successful in western game development were actually some of the smaller teams. And so if you have a team of let's say between 10 to 15 people, but you might also have
five specific outcomes that you're looking to optimize against. How would you recommend with a small team of like 10 people? Do would you have people part dedicated to one of those teams? Would you split them? How would you think about that kind of a structure?
With that small, it's you're almost within that kind of team size of the

sweet spot already. So, it it's almost like everybody when you're that small, I I would I'm not sure if I would um separate them into even smaller teams. I think I would probably keep them more um aligned. Or what you could do is you could separate say for example um maybe into two teams. Maybe you could have two teams of individuals that are focused on I don't know in-game or outgame you or you could do um you could think of different compositions where you could split that team down to give more focus. But when you're 10 people it's almost like it's uh you already have all that baked in scrainess, transparency, you're working with each other. Uh hopefully you're able to balance the various different uh uh priorities and needs. Um, what's just important there is to have that clear product vision and make sure everybody's marching towards it.
And this kind of goes back to the notion that we talked about around situational context as well as thinking about how do you orchestrate and how do you structure the team given what you have, right? Y
and so and I'm sure there's there's potential solves for this too where you

have a team but that team may be evaluated against well we do need like a great you know dynamic difficulty adjustment system or procedural generation thing and so you can have different outcomes that are assigned to a team and you track progress against those rather than having like a bigger team where you dedicate teams against those those objectives for example.
Exactly. Exactly. I I totally agree. And plus, I think in those smaller teams, it's more common where you have more generalists. You have people wearing a lot more different hats. So, you know, you might have a narrative designer that's also an audio designer. So, I think I think Clare Obscure was an excellent example of everyone coming together to go ship that game with a small group, relatively small group of people um and wearing different discipline hats. So I I think uh it really depends but as you called out I I wouldn't subscribe I wouldn't ask you or submit to you that this organizational structure is exactly what you should do. It's it gives you the right thought of like how can we organize people to give them enough clarity to go win at at

their product. So um so I I would even say this is probably too overconidered for a smaller team like that.
Right. And so to your point, I think that the the thing that I that I like and maybe we should we should underscore is that
there are a lot of important principles that you have written about, but then you got to apply those principles and that the example is a specific example, but then you've got to apply it in the right way. So it's not like like the the other mistake you see a lot is like, oh this game, it's like the shiny new object uh phenomenon, right? It's like this game came out, oh, we're going to just take that and we're going to apply it to our game. not thinking about how do you actually translate that or whether it fits things like that.
Exactly. Yep.
All right. Well, Chris, I think that uh you know I I definitely want to thank you for giving us your your insights. Maybe before we close, uh, I'd love to hear a little bit more about, you know, what's up with you currently and then if people wanted to get in touch with you,

what would be the best way for people to get in touch maybe regarding this poster or anything else?
Well, thanks thanks Joe. This is honestly this has been so much fun. I hope there's more opportunity to discuss about so many of these different topics and honestly I'm open to talking to anybody about what I've written in the article or if you have any questions of what we talked about today. Um, I'm available and would love to to speak with you. So um uh either reach me on LinkedIn or chris.casanovaoutlook.com um to have a look at the article. Uh and also please I'd love to swap notes share you know your your thoughts on how to make you know teams healthier and make games you know even even better. Um I would say is that like the most rewarding part of my career is has been to to help teams find the rhythm. So, when you have people that are happy, they have clarity, and they're kicking ass, um it's so much fun to see that kind of outcome. So, I'm happy to help any team that's looking to um uh you know, navigate uh that ever ongoing um

problem space. So, hopefully we can build some games, great games together. And um I I am currently uh looking forward my next role and so I'm happy to uh talk to anybody about uh you know, future opportunities and how I can help the organization. So, thank you so much for the time, Joe. That was awesome. I'm a huge fan of your uh your work and your podcast and it's been an honor to be on here.
Great. Well, thanks so much, Chris. And I definitely hope you come back on again. There's so many things that I think we can talk about and so few people going deep in terms of like game development and how we can all improve, which we critically need to do given the the current landscape.
And so with that, for our audience, thanks for joining and we will catch you next time. Thanks, Chris.
Thank you.
If you like the Game Makers content and if you found value in what you saw today, then please do me a huge favor. Become a part of the GameMakers community by hitting the subscribe button. You'll get notified of some of the really great content that's coming

up and the bigger the channel gets, the better the guests I'll be able to get as well. Also, comment and let me know what you think. So, don't forget to like, to subscribe. Thank you so much and until next