TL;DRThe producer role varies by studio, but broadly it supports teams and leadership by managing schedules, scope and priorities, built around communication, planning and risk.
It depends on the studio, right? So game production is not the same across the industry. Every studio runs the production differently from another. But generally, baseline, it's about supporting the development effort at large, supporting teams, managing schedules, scope, timelines, priorities. It's a supportive role. We support teams and their endeavors and them hitting their goals. But we're also leading the charge. We're part of leadership and it's all about plotting the course for the next few months, years, whatever the project needs.
Yeah, and I'd kind of echo that and say when I think of just the basic building blocks of a producer role, I think of basically three pillars or columns. One is communication, the other is planning, and then risk. So production is basically managing communication, making sure that's flowing smoothly. Planning is all about schedules and making sure that we have them, first of all, but also that when things inevitably change, because that never happens in game development, that we update them accordingly and then communicate out those updates. And then the last pillar of risk is managing potential risks or impacts that might negatively have consequences on the schedule, essentially.
TL;DRCommunication management means planning how information flows between teams and departments at a project of this size, which artists and designers aren't trained in, while keeping meetings focused and concise.
Yeah, so I think for me, when you talk about communication management, it can vary from project to project. And that's kind of a disclaimer for this whole conversation, by the way, is that production can mean a lot of different things just depending on where you work. Titles can be different, producer versus project manager or development director or coordinator. There's lots of different words that people throw around for what we do. And every company seems to have a different expectation about what a producer does at their various job. So there's that disclaimer for everybody. But at least for us, when I think of communication management, especially for a project with scale, because this is very different for a small shop where everybody works in the same location or if everyone's remote. There's plenty of different platforms for communication through email and messaging platforms and all that kind of stuff. But for a project of our scale and the different departments that are involved, it helps to have a plan for how you communicate. It's not enough to just say, well, just hit me up whenever something's happening. I was literally having a conversation with QA earlier this week about how we communicate progress and status towards bugs and how production can help give QA the information they need. We have these various channels in our communication platform that we use to send messages, but how often are we sending those messages? Does it make more sense to consolidate all of the information you need into a single meeting or does it make more sense to send little tidbits of questions throughout the day, right? What makes most sense? And how do we keep that from ballooning to where it's just absolutely untenable? So organizing the flow of communication is an important part of a project our size and managing a project our size.
When you come into a business like this, you've got artists. They go to school and they train to be artists. You've got designers. They go and they train in game design. In all of these curriculums, and I've been to a few video game job fairs, there's not really a course in communication. The act of communicating is one of those things that is not generally taught. You're taught to be an artist, but you're not taught how to communicate that work effectively with other teams. And that's one of the big areas where producers come in. They form that membrane between all the different disciplines and make sure information is flowing from one to another as effectively as possible.
Yeah, absolutely. Communication consists of multiple factors that you have to account for. Communication is not something you can learn in a Udemy course. It's something you have to build a skill for and get better at over time. The greatest communicators are succinct, they're clear, they're concise. They get across what they want in the clearest way possible with the fewest words, right? Great orators are always the great communicators that we aspire to be. We want to explain something very complex without going into the nitty-gritty and get people on board. And in game production, communication is very similar. When we coordinate with multiple teams, for instance, to get a feature out the door, or multiple departments, we cannot sit in hour-long meetings and discuss all the kind of things that we'd like to talk about. It has to be specific to that meeting. We have to get to the bottom of what we're trying to achieve and get the job done.
More than I would like to admit, probably. But it's good. It's important meetings. When we have meetings that waste everyone's time, we tend to cancel them. But most of the meetings that I'm in are with directors, leads, other producers, other leadership members. And we try to get our features out the door. We try to establish a better process. They're all valuable.
TL;DRWhether to take a schedule risk is decided by production, team leads and a director weighing options, guided by a shared risk appetite that is typically higher for tentpole deliverables.
Usually when we identify potential risk for a deliverable, like a feature or something, I think we had a recent example that we've talked about, the ship trespass feature, for instance. So we had a full-blown schedule for the feature on a task level. We knew when it would be ready, but there was always this risk looming that there could be more edge cases that we have to address before we can release the feature in a good enough state, right? So that was one of those risks that we tried to mitigate but couldn't, and then we didn't feel comfortable with just releasing it anyway because these edge cases needed to be dealt with, and so we had to pull it out of that release. But in other instances, it's usually a discussion between production, the team leadership and a director like Todd. We will sit down, we'll go over the risk, and then we'll give him a few options and discuss it with him. And then if he's happy to go down the road of, okay, let's shoot for it, right? Let's put a few more people on it so we can get it out on time, then we'll do that. And if he would prefer we keep it, we make it good, we get it in a better state, then we'll do that instead. It's always a coordination effort between leads.
And to that I'd add, sort of how this process starts is you look at your release, just the release that you're planning for, and you try to identify what are our tentpole deliverables, right? What are the things that are really going to prop up this release and be the big selling points for this release, the things that are going to excite people, right? So you identify what those things are. And you then discuss what your level of risk appetite is. And basically risk appetite is what's our tolerance for risk with these specific features. And generally speaking, your tolerance for risk, basically allowing the potential to go down different paths that might impact a schedule negatively, your risk appetite might be higher for tentpole deliverables because that's going to be a make-or-break sort of feature. Whereas something that may not have as big of an impact, we don't mind delaying slightly to give it the time it needs. Or it could be even a bigger thing, but we're like, you know what, this needs a little bit more time in the oven, right? The risk appetite is low on this. So let's go ahead and do that. The trick with this is that everybody has to be in alignment. Everybody has to have the same risk appetite.
TL;DRThey keep a backlog and a regular planning cycle that sets goals for the next several months, which production then breaks into scheduled tasks that determine which release a feature can hit, though late-discovered extra work can change the plan.
I mean, we have what is colloquially called a backlog. That's all the things that we want to do for now and forever, effectively. And obviously we're focusing on the things that are upcoming next, right? We have a regular planning cycle where we go through the next three to 12 months and then we start a high-level plan. We need to establish what our goals are for the next 12 months, right? And some teams go even further, right? They have 24-month schedules. But this is just establishing goals. At some point, the team and the production team have to come together and break down these goals into more tangible, sizeable, digestible chunks. That's where production gets really involved. We break down the work into tasks, and we schedule out those tasks. Those then inform what release we can hit with a particular feature. So for Ship Trespass, we planned it out for 3.20, and there was a plan for the longest time, and then at some point we figured, okay, there's extra work that we have to do that we weren't aware of until fairly late into the development process, as we started testing the feature and seeing where it breaks.
TL;DRBeyond planning, producers support the team by clearing tool and cross-team issues, looking after morale and productivity, modelling good working practices, and driving cross-project pushes such as stability or performance.
I mean, for some of the responsibilities I was given here at CIG, it's all about also supporting the team, holistically, generally, right? If there's issues that the team is dealing with, if it's tools issues, if it's collaboration issues with a different team, if they're struggling to find the right information, that's kind of where production steps in and supports, right? So that the developers can focus on development. So we try to support the team, the team morale, the team productivity, that's a big part, right? And then we also try to be a good example of how to work as a department. There's certain principles and guidelines that we have in production that help us become better at what we're doing. So we have regular learning initiatives that we kick off, or other initiatives that allow developers to be more productive. On top of that, we're dealing with a lot of cross-project initiatives. Like if there's a big push for stability or performance, it's usually producers who manage the process and kind of drive it forward so that everyone is aligned and we get the game in a better state.
TL;DRIt can get that granular, but on this project it doesn't; they trust developers and only look at what a team achieves over a period like a few months, not individual check-ins or tasks.
Yeah, we don't want to watch over people constantly, right? We trust our developers. I mean, they're professionals. All we care about is that how long they think it takes is what they feel comfortable with. They don't give us estimates to make us comfortable. All we care about is when we can ship something to the players. And what we look at holistically is how much a team can achieve within, let's say, three months. And if that is half a feature, then it might take six months to deliver a full feature. So we try to give the developers the space that they need to figure out all of these difficult problems, and not look over individual check-ins or measure how many tasks per week they've closed off. That's not what we do.
TL;DRProducers question optimistic estimates and scope, since people are bad at estimating, and add buffer for unknowns, meetings, time off and bug-fixing so schedules are not maxed out.
I'm actually quite passionate about this, because I review all the game design documents that the lead designer puts in front of me. Like if they say this is the amount of work, I'll try and question that, right? Because they may feel very optimistic that we can achieve something with X amount of weeks or months available to us. But I, as a producer, have the responsibility to push back on that and look into those numbers and look into that scope that they're trying to achieve and ask difficult questions like, are you actually able to do this on your own? There's so many things you have to keep in mind, right? Some of our leads have more than just development work that they have to do. They have their own people, they have a lot of meetings to attend, right? Everyone, I think, that I've met in this company is very optimistic about what they can achieve, because it's an exciting project. But humans are incredibly bad at estimating. I think there's entire papers written on it, right? So what we do as producers is question and push back, and wherever we feel like we're not really 100% confident, we can build in buffer, right? Extra time in the development of a feature schedule so that we can account for unknown unknowns. There's always something that goes wrong. There's a tool that's breaking, or there's some priority that has to be addressed immediately, right? So that is something that we have to deal with. It's a very big company with so many developers, with so many people checking in. You've talked about game dev before. It's difficult to get it in a stable enough state very quickly, and so sometimes we just have to make a push, and that can affect a feature's development time, right? So we as producers try to always push back, ask questions, try to understand what's the reality of a feature's development timeline, and then build in that extra safety net of buffer.
Yeah, and then I'd say that you can't always look at just an estimate on its own, right? Sometimes a developer will say this will take me three weeks to do. Okay, cool. You're not working 100%, eight hours a day, whatever it is, for that amount of time. There's meetings that crop up. People get sick or they take time off. You can't just look at an estimate somebody gives and say, okay, cool, I'm just going to take that and plop it into my schedule, and that's that. We do track and ask teams to account for time for unknowns, which is the things you don't know that you don't know, because it always happens. Things come up that we just could not foresee. And so we don't max out our team schedules. If they give us an estimate of three weeks, we might actually put it in the schedule for something like four, four and a half weeks, because we know that there are real things that crop up. Bugs will come in that need fixing. So there's an element of that as well, of trying to keep in mind the whole context of things, whereas the developer's scope of what they know about is the stuff they've been asked to do. Producers have to be mindful of everything that's going on in the project, so that we can be like, well, I know that there is a release happening around that time and that likely we will have to monitor the bugs that are coming in. This team is often supporting the releases and fixing bugs. So I'm going to take your three-week estimate and I'm going to add a little bit of time there, because I know that you will likely have to get pulled off and reprioritized to help support the release or something like that.
TL;DRProducers trust developers' estimates rather than dissecting them, but add context and buffer where they know of conflicts, and the process is collaborative between developer, producer and lead.
Ultimately, it comes down to trusting what the developers are giving us, but then always having a backup plan, right? I don't want to question every estimate that I get from a developer, because they know best. As a producer, my role is to get the information that I can gather and add some extra caveats to it, and as my risk mitigation process, for instance, add buffer. So there's been times where I've asked, are you sure this is just going to take one day? Because you have a meeting all week, or like the entire afternoon, so it's more like half a day that you actually have time for this. Like, yeah, okay, let's make it two, right? But I don't try to criticize or try and dissect what they're thinking this would take.
So you're talking about trusting the devs, and I just know from experience, you absolutely have to. But there has to be another layer of, I'm going to check over here, and we're going to check over here, because they're always very focused on their work.
I think it's just asking the right questions, right? It's a collaborative process. Game development is a collaborative process. Schedules are no different. You have to have the developer's input, absolutely, because they have to be the ones to tell you how long the thing is going to take. But then you also have to have the producer's context, and you have to have the lead who probably has more years of experience and can say, well, you didn't think about this. Oh, yeah, I didn't think about that, right? It's a collaborative process.
TL;DRProducers are part of feature team leadership, driving the team's schedule, coordinating across departments and sign-offs, and acting as a calming, supportive voice when the team is frustrated.
I mean, on the feature side, which I'm overseeing, I see producers as part of those teams, as leadership, right? You have your Elliots and your Eds and your Lukes, but then there's also an Ash who is part of that team, who is the producer for the mission feature team. He's just as much part of the mission feature team's leadership as Elliot is, for instance. He's not getting camera time, but he's playing a huge role in actually allowing the team to deliver what they're looking to achieve, right? He's making it all happen on the schedules, coordinating between departments, QA, publishing, getting directors on board, getting them to sign off on what we're trying to achieve. It's driving that team from a production perspective. Supporting them, right? Like Jake said, a shoulder to cry on. That's what producers often have to provide, because there's frustrations that the team has to contend with, and the producer is always the calming and reassuring voice: this is a problem, it's good to be annoyed by it, but let's sit down and figure out the process to fix it, right? It's the voice of reason, the voice of a better future, so to speak.
TL;DRYes, they hold regular internal venting meetings and playtests and track player feedback, which matches internal views, but fixes are often complicated and come down to how teams split time between features, bugs, quality of life and tech debt.
Yeah, we actually have a weekly, bi-weekly meeting that is just venting, right? It pretty much is that. It's not supposed to be just a place to vent. It's a place where you can share your frustrations, and we play the game every week. We have playtests internally that every team does. And after it, it's like, okay, there's a lot that we need to fix here. It's an opportunity for us to get a reality check, and we try to play as much on live as well. I try to do it all the time, to get the pulse on the current situation in the game, and then have that feed into the decision-making process that we do with directors and leads, right? Everyone is acutely aware of the issues that players have right now. We share those frustrations 100%. I'm seeing the posts, I'm seeing videos of people talking about what they like and don't like, and it matches almost 99% with what I'm hearing internally in meetings with regular developers. So I feel like we are very aware, but there's a challenge in just addressing what is currently the biggest problem at face value. It's often a little bit more complicated than it appears to be, especially when it's deep-rooted in some of our tech stack. It just requires a bit more brain power than just one developer going off and doing a bunch of bug fixes.
We do have a process for tracking all the player feedback, essentially. And so we do have an acute awareness, as Philip said, of what the issues are. It always just comes down to priorities, right? And I mentioned earlier how we have an expectation during our planning that we allot time for unknown unknowns. We also have an expectation that teams account for time to address what we call quality of life issues and bug fixing. And so along with the feature development commitments we would need to develop a specific feature, we ask teams to account for unknown unknowns. We ask teams to account for tech debt. We ask teams to account for quality of life and bug fixing. And so it's just a matter of what percentage of the team's time is spent on each of those allocations. And often new feature development dominates the team's schedule, but there are times where we pull those levers around and we say, okay, we're going to need to spend more time on quality of life this quarter, or more time on bug fixing, or more time on tech debt. But that's just the challenge of having both a live product and an alpha development game at the same time. So these are always just different levers that we have to pull.
TL;DRThey ask this constantly and decide case by case, sometimes pulling a feature and sometimes releasing an imperfect one for feedback, with producers communicating the impact of business leaders' competing priorities.
That is always the question. I feel like we ask ourselves that question internally every single week. That's the constant challenge. Folks expect a patch, and then folks expect a certain threshold of content to be in that patch. None of that determines how fast a project gets developed, how fast a feature gets successfully built, how fast bugs are found and destroyed and whatnot. And that's what we talked about earlier. Sometimes when it's a thing that's egregious and we can do it, like ship trespass, we pull it out. And sometimes you go forward, and it's like, we think this is in a place where it can still generate good feedback. We think it's in a place where it can still be useful for testing, where it can still be useful for analytics and stuff. So even though it's not perfect, we still put it out there, because it serves a purpose to our game development to get it out there and to get it in the hands of players. And I hear this conversation constantly, there's always this back and forth between whether that should be pulled, or whether that should go in with just a little more pillowing around to make it safer. It's the forever challenge, right?
We've done something similar for 3.19 when we introduced the ability for tractor beams to remove and reattach items. We knew that there would be issues with some of the ships because they're not up to gold standard yet. But we accepted that as a risk, because we felt the feature was in a good enough state that it would add so much more value to the current game. We now have the ability, when you go out for a salvage contract, to find loot and strip the ships of their components and make some cash on the side, right? Or re-equip missiles for some of your vehicles. There was value in just pushing forward and not scaling back and not saying, okay, let's get all these ships sorted out and hold the feature from getting released. We felt like it was the right call at that time.
It's that same debate. It's the debate that's going on in Twitch chat right now. It's whether a thing should go out, whether a thing should be held back. Oh, that's too many things being held back, now the patch has to be delayed so we get more stuff in. But if you delay the patch too much, I thought we were going to pull things out so we didn't have to delay the patch. It's just this constant, never-ending shifting of levers.
Part of that too, going back to what a producer's role is in all this: every single one of those things, putting out new features, addressing stability and performance issues, bug fixing and releasing patches, the events we do every year, preparing for CitizenCon, these are all goals that are set by our business leaders. They set the goals. This is what we want to do. What they don't know is, if they come in and say, hey, this is a new initiative we want to do for this next release, how does that impact everything else we were already planning on doing, right? So as a producer, a new request comes down. How does that impact the current state of things? And something that I feel like we've improved at over the years, but still could very much improve on, just full disclosure here, is better communicating impacts: this new thing came in, here's what that impact might be. We want this new feature. Okay, well, do you realize by requesting that new feature, it means this team's allocation towards quality of life and bug fixing actually shrinks? Was that something that we were aware of? And often that's not the case. So we have to be better at communicating that as well. And I would say over the years, we've improved at that leaps and bounds from where we were four, five, six years ago, right? But we can always do better at that. So I'd say that is something we're constantly assessing: of all these things we're trying to juggle, which thing is the most important at any given time? Because that does change quarter to quarter. And essentially, what would we lose by focusing on this versus that, and that sort of analysis and what I call scenario building: if we do this, then that means this; if we do that, that means that. That's the communication management aspect of this, right, where you come in and here's the impact, do you want to go left, do you want to go right, and then hopefully we can help our business leaders make a more intelligent decision that way.
TL;DRPhilip Becerra recalls, at a different company, finding the Steam go-live date unset 30 minutes before launch, while Jake Ross recalls late nights and broken air conditioning before the first Arena Commander release.
It was not at CIG. It was a different company. I think it was probably 30 minutes before live, and we would release our game on Steam, right? So on the Steam backend, there's this little thing that you have to put in if you want something to be able to be purchased on the actual store. That's the go-live date that you have to set. And 30 minutes before the go-live date, we realized that nobody had actually set anything in that field. So panic sets in. And fortunately, I was working with a company that had good relationships with Valve. And so we kind of picked up the red phone and said, Gabe, make this go live, please, effectively. But in those 30 minutes, I've never been this stressed out. This was a crazy moment. And I'm happy that five minutes before live, it was actually live.
I mean, I was thinking about this. It's funny, some of what I would call horror stories in the moment, I now kind of weirdly look back on fondly. I don't know what that says about me, but I remember the early days here, trying to get that first publish of Arena Commander out the door.
Yeah, so the days leading up to that were intense. I'm just going to say it for what it is: late nights, people sleeping under their desks and stuff like that. But what was great about the whole thing was that at that time, the Austin studio's air conditioning would go out for no reason. So it was really, really nice to be up super late at the studio with no air conditioning in hot Austin summers. Or I guess at that time it was in spring. But it was things like that that I look back on and go, man, that was trying. Let's just put it that way. But I look back now and I kind of laugh about it, because it's like this camaraderie building that also happens. Some of those people are still here, I still work with them, and I built relationships with them, and you build those friendships that last a lifetime through trials like that.