Note from the author

Although I work for Blizzard Entertainment, the opinions expressed here are my own and not representative of Blizzard’s policy or conduct in any way, shape or form.

PART 2

In Part 1 of this article, I talked about the role of a game producer within game development, and the main principals by which he should allow himself to be guided. In this second and final part of my article, I will focus more on what a good game producer should do in certain situations, and what he ought not to do.

Specific Situations and What a Good Producer Would Do

So now that we’ve established what a game producer generally does and what his role is within the development team, let us delve a little deeper into a few specific and common situations in which a producer will find himself, and subsequently determine how a *good* producer would deal with those situations.

Tasking

Nothing says ‘Project Management’ like tasking, and every game producer I know does a lot of it. The job of tasking is really nothing more than what the name would have you believe; assigning tasks. Whether it’s through email, a board with Post It notes or some fancy, customized tool, it’s all essentially the same; technically simple and generally quite mundane. But even with this simple, monotonous work that’s hard to screw up, there is one way to do it, and then there’s the good way to do it.

A producer can easily just get all the relevant parties together in a room, or in individual meetings, and have them dictate to him what the tasks ought to be, how long they’ll take etc. Then if something is unclear about the task, he can simply refer to the original dictator; all the game producer needs to do is to regularly check on the status of the tasks and jab the taskee in the ribs for an update.

But there are weaknesses with this approach. A task, in the context of game development, is not just a method of assigning a job to an engineer, artist or designer. It is also a way to see all the pieces of the puzzle, not just for the producers, but for everyone involved in the project. The combination of all the tasks should ideally function as a record of the work that has been done, has yet to be done and the problems that were encountered and fixed along the way or that have resulted in further tasks. Proper bookkeeping through tasking will result in clarity and lessons learned for the future; a playbook of sorts. So it’s important that the tasks contain the information that will yield this result. Is the task understandable to someone not working on it? Do the start and due dates align and make sense in the general schedule? Are finished tasks marked ‘Complete’, or are we passed the due date without a comment or update? Will future-us be able to read through the task and the comments and know what happened?

Of course, applying this level of detail and diligence to the thousands of tasks a random producer might enter for any given project, will balloon the workload to such a level, that he would have little time for anything else, but I think the point is still valid. A producer should ask himself: Do I understand this task? Is it reasonable to expect the desired outcome? Could I describe it in non-technical terms if someone asked about it? If he can honestly answer yes to those questions, he’s doing a great job.

Scheduling

There must be hundreds of ways of making a schedule, depending on its purpose. Is it to show the engineers, artists and designers how much time they have left to complete their work? Is it for marketing, PR, Community and the Executive Management to show when the work will be done? Or is it to show which dates all of us absolutely must reach in order to make the Christmas shopping season? It could be any or all of these. But whichever one it is, there are two simple basic rules I’ve learned to adopt over the years in how I make my schedules: 1. Don’t let the tool determine the format of the schedule. I simply use Excel. 2. You are not making the schedule for yourself; your client is the recipient. If I wanted to make a schedule for my own private use, it would be filled to the brim with details, abbreviations, random notes and personal comments. It would be illegible to almost anyone else.

But these are just basic tips that I would recommend anyone adopt for any kind of scheduling in general. For a game producer, it would be all too easy to simply take down the delivery dates handed to him from the department leads, put them in a pretty table or in a nice diagram, and send it to whomever might complain that they don’t know what the schedule is.

A good producer however, understands the schedule. He knows what the milestones mean, why they are on that particular date and what will happen when they aren’t reached. He also knows which forces have played a part in determining that a date for a milestone is reachable; who’s working on what, who’s on vacation, who’s out sick and which teams are understaffed, on track or delayed.

In knowing these things, he will be able to anticipate questions and hurdles and subsequently be able to answer those questions and overcome those hurdles. If a game producer is asked why a date in the schedule can’t be sooner, he needs to have a useful answer ready, or at least commit to procuring one, and not resort to deferring to someone else. If a producer doesn’t understand something as basic as his own schedule, what is he there for?

Meetings

I think it’s safe to say that not many people genuinely enjoy meetings, and as a result, few people in charge of leading or preparing for a meeting will do so with the vigor and enthusiasm necessary to get the most out of it.

A game producer, like any meeting organizer, ought to make sure the basic criteria are met for organizing and running a meeting well. Things like making sure there is an agenda, that someone is taking notes, that it starts on time and doesn’t last too long, that the right people are present and that any action items are followed-up on. This may sound easy, but it’s practically impossible to do consistently. At least for me.

In addition to these standard best practices for meetings anywhere in any business, there is one thing that is, if not unique, then perhaps more prevalent in the work of a game producer. Unlike most meetings I was in before I became a game producer, it is now common for me to find myself in a meeting where we talk about work that I am not personally expected to do. This means I don’t necessarily need to understand everything, I just need to know that it was said. It may be because it was too technical or because it concerned managerial matters, both of which are rarely within the realm of a game producer’s responsibility. Or, more often than not, the meeting might be about the job of an entirely different team or department, in which case I might have no idea what anyone is talking about!

In those situations, a game producer is obligated to make additional effort outside of the meeting itself. If he wants to be able to contribute, he needs to not only know what was said, but understand what was said as well. It’s all too easy to simply take notes, enter tasks and call it a day, and an average producer could get away with that ad infinitum. But a really good game producer makes sure he understands the material, how the conclusions were reached and why the decisions were made. In doing so, he adds a new dimension to his work, and instead of merely being an executor; an enterer of tasks, and sender of emails, a setter-upper of meetings; he has become an architect; an authority, a project owner and a real developer.

Communication

In job descriptions for game producers you’ll invariably see mention of the necessity to be a “good communicator”. I’ve always found this to be somewhat obtuse. Anyone can claim to be a good communicator and, as far as I know, there’s no standardized methodology of determining someone’s skill at communicating.

This is not to say that it’s unimportant. Being people-shy won’t do if you want to be a game producer. Similarly, if you’re ill-at-ease in large groups or at running a meeting, you might also want to consider another career. At the very least, the need to talk to people shouldn’t be a limiting factor or a hurdle that needs to be overcome. If it is, then communication is not your strong suit.

So what are the key elements that a producer needs to keep in mind when he’s working on his “communication”?

What NOT to do as a Producer

We’ve talked about the role of the game producer within the development team and how a good producer should go about achieving his goals. Now I’d like to drive it home by looking at it from the opposite angle. What are the main pitfalls a producer should avoid. What should a good game producer NOT do?

Don’t be afraid to ask questions

It is not expected of a game producer that he has deep technical insight or is aware of the details of every task and bug. In fact, if he spends too much time on those things, he is likely wasting time, because in any event, there will be people out there more knowledgeable about such things and in a better position to work on them than he. By looking at and understanding the workload from a little bit of a distance will give the producer some perspective and allow him to see everything in the context of the bigger picture, and that is exactly what he is there for. Additionally, if a producer is able to understand an issue and able to describe it in general, non-technical terms, sometimes referred to as “producer speak”, it will be easier for him to pass on that information to other parties, like other producers or support teams. The key to making this work, is to ask questions. If something doesn’t make sense to a producer, he needs to have it explained to him, even if it makes him look stupid or incompetent, or if he feels that he might be burdening someone. It’s better to spend some time asking questions and getting explanations, then to move forward, enter tasks and share information in subsequent meetings when it is not entirely clear what the challenges are. Better to waste one person’s time and suffer the shame of potentially looking silly, than to have the whole team suffer. A game producer should learn to swallow his pride and stick his neck out when needed.

Don’t create unnecessary work.

The first step in properly prioritizing work, is to determine whether the work even needs to be done at all. Any random person on any random day may have several “wouldn’t it be cool if we did this!” ideas. Whereas for most people those thoughts remain safely locked away in the realm of inaction, people in positions of power might have the means of seeing them come to fruition. Especially on occasions where opinions can be voiced with an eager audience, like in a meeting, an idea might sprout into a concrete task. This is where a producer needs to be wary. Just because one person thinks doing something would be cool, doesn’t mean it should be done, particularly when they themselves wouldn’t be the ones doing the ‘doing’. A producer needs to be aware that decisions translate to work, and too much work translates to delays, and delays are kryptonite to a producer (or at least it should be). An engineer, artist, translator or designer, even if senior or lead, may not have the same overview of a project that a producer should have, and therefore might not realize the overall impact. So this is where a producer can be very useful. If a meeting can be cancelled, a bug can be punted or a task can be postponed to a later date or can be refrained from needing to be done at all, more time and effort will be made on the work that does need to be done.

Don’t make people not want to work with you

Strictly speaking, it’s not critical for a game developer, in whatever discipline, to work closely with a game producer. A regular character artist or server engineer can simply come in to work in the morning, look at what’s on his task list and start hammering away at his job. Whether his tasks were entered by a producer or his lead, really doesn’t matter. If he needs to work harder or stay late, his direct manager will tell him. If he has questions about his salary, career path or vacation days, he can talk to his manager. He could easily get by without ever having to deal with a game producer.

This is why, above all else, it is important that the game producer makes himself useful and approachable. If he can make sure people don’t outright ignore him, he has taken the first step in becoming helpful. I firmly believe that a dedicated team of producers will greatly improve the productivity of a development team, but this can only work if people understand the benefit of having a game producer, desire that benefit and actively seek it out.

Don’t be the one who holds things up

Delays in reaching deadlines can originate from almost any place, be compounded by a plethora of additional variables and have a myriad of dire consequences for any number of interdependencies. This is to be expected and prepared for. Power outages, sick leaves, dead pets and earthquakes happen and even the most veteran of game developers will misjudge how long a particular task may take to complete. All of this is acceptable. What is not acceptable is consistent delay on the part of the producer. If a plan can’t be made because the meeting didn’t take place, it’s the producer who failed. If a server engineer is waiting for a reply from a web designer, the producer needs to make sure he gets it. If players have encountered a critical bug, it’s the producer who should find the guy to fix it. And in truth, it is very easy for a producer to avoid being the bottleneck, because usually all he needs to do is send an email or pick up the phone. But simple as this may sound, it just serves to strengthen the reason why failure on this front cannot be tolerated.

Don’t forget to follow-up

It is all too easy for anyone to send an email and simply assume it was received, read and pondered by the recipient. All the more so in this day and age with instant messaging, Facebook and ‘commenting’, in which it is the common practice to simply post a remark and forget about it. This is a fire-and-forget culture in which there is little accountability or follow-through. But in the day-to-day work of a game producer, that’s not good enough. By and large, emails are sent, phone calls are placed and meetings are held for a reason, and those reasons require resolutions. And while engineers need to go back to writing code, artists need to go back to creating models and designers need to go back to designing levels, producers don’t have that luxury and can’t allow themselves to get deviated or distracted for too long. Following-up on an email, action items from a meeting or questions from a developer, is part of what justifies the producer’s position to begin with. Failing in this is failing in a core responsibility of production work.

Conclusion

It’s very hard to determine whether a game producer is doing a good job or not. As I said at the beginning, if a product is successful, the producer can claim credit. He can say “Yes, I was there, I helped make it happen”. And at the same time, if a product fails, it’s easy for a producer to absolve himself of any blame. He can simply say “Hey, I’m not a designer, or an engineer, or an artist. I didn’t break anything”. A game producer can get away with being crappy if his team is good.

But the fact is, it’s a poor craftsman who blames his tools, and for a game producer, his flock represents his toolkit. A producer should always own the deliverables of his flock. He may not be the cause of a failure, but that doesn’t exempt him of responsibility.

At the beginning of this article I mentioned that an art producer doesn’t make the art, which is true. However, a good art producer knows what it takes to make the art. He knows how much time his team will need to reach the deadlines, what obstructions there are, if any, and what the work will subsequently be used for. He understands the life cycle of the product his flock delivers and its place in the general development of the game. Similarly, I also stated that an engineering producer doesn’t manage a team of engineers. Again, true, but a good engineering producer knows how to deal with his engineers. He knows how the engineers prefer to work; who prefers to be alone in a dark corner writing code all day, who needs extra attention on their task assignments and who wants to be invited to every meeting.  Furthermore, it’s true that producers generally don’t decide what goes in the game, but if they’re good, they know the game well enough to be in a position to make useful suggestions, propose alternatives and shoot down outright ridiculous feature proposals. Producers often have a broader view than the individual, core developers, and with this broader view comes a useful perspective. Lastly, and perhaps most importantly, although it’s also true that most producers have little to no influence over the team’s budget, they need to always keep it in the back of their minds. No company in the world can afford to throw away money, whereas the opposite extreme should also be kept in check: no company can afford to have their employees stymie their productivity by fretting incessantly about potential costs, especially in a business driven by creativity. This is why being efficient, trying to hit the deadlines and making sure problems get addressed as soon as possible, are what should be foremost in the mind of a good game producer, if in no one else’s mind.

In short, a good game producer delivers a customized service, tailor-made to the people he is working with, the product he is working on and the urgency of the deadlines. To succeed in this he needs to be flexible; always be able to adapt to new circumstances and know that the unforeseen will happen. And when it does, to stay calm and rational even when others aren’t.

At the same time, he needs to be vigorous and exude strong principals. He needs to do what he said he would do and he needs to follow-up on the work that has been set in motion. He needs to nudge slackers, jab stallers in the ribs and remind the heck out of everyone. He may not be liked for it and he may not get much recognition, but that is part of the job, and a good game producer needs to set his ego aside in favor of the greater good. That is the only way he’ll be able to claim his rightful place in the pantheon of true game developers.