Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
In the fabulous and fantastic world of art, design, storytelling and engineering that is game development, how does a professional video game producer stand out and make his mark? This article aims to answer that question.
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.
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.
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.
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.
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?
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.
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”?
Everyone is unique. A good producer knows his flock, and he knows how best to talk to its members. Some people like meetings, others don’t. Some people want to sit behind their desk all day and do all their communicating through email and chat. Some like it when you drop by their desk for a chat, and some people detest it when you do that. If a producer knows how best to talk to his colleagues, he will be in a far better position to share information, ask questions or say “no” when it’s needed. Realizing that there is no single, catch-all method for communicating is the first step in achieving the best method for communicating.
Be reachable. The single most important thing is to be reachable. If someone needs a producer, they should be able to find that producer, and it’s the producer’s responsibility to make sure this can happen. In this day-and-age, that shouldn’t be too difficult, what with email, cell phones, texting and chat, or even FaceBook, FaceTime, WhatsApp and Skype. It has never been easier for someone to make sure he is reachable. The producer just needs to make sure his contact information is available on whatever centralized contact list the company uses, normally in Outlook or some internal website or wiki. In additional to that bare minimum, a good producer will make sure that he’s logged in to Messenger whenever he’s at his desk, that his cell phone is switched on when he’s not, and that he checks his emails from time to time at home or on the move. That should give him 90% coverage. Putting that contact information in email signatures and/or on office whiteboards should take care of the remaining 10%, which can be useful when people aren’t at their desk or near a computer.
Be visible. As I mentioned at the beginning of the article, many people, including other members of the development team, have no idea what producers do. As a result, they don’t know if and how producers can contribute to the game development process. For this reason, it is important for a game producer to make it obvious what he is working on. By showing what he is doing, he simultaneously shows what he can help with or be used for. Obliging his colleagues in such a way, will, in turn, lead to more work and subsequently, a greater contribution. A game producer who can’t be of use to his team or his flock, is a useless producer. Any producer can simply sit at his desk, send emails and enter tasks knowing he is doing what his boss wants him to do. But a good producer knows how to communicate his usefulness outwardly. In meetings he’s prepared, pays attention and voices his opinion. He asks questions that others might be too shy to ask. He shows that he knows what’s going on by sending out reports and schedules. He shows that he knows what his flock is working on by answering detailed questions and making adjustments to the schedule so it matches what is achievable.
These actions may seem artificial or somehow disingenuous, but if a producer wants to be involved in the decision making, treated as an equal and be approachable, it needs to be apparent to all that he is working just as hard and suffering just as much as the next guy, even if he doesn’t know how to animate a 3D model, record sound or translate quest text.
Create efficiency. Ultimately, the goal of good communication is to attain a level of high efficiency in the execution of the work the team does. A producer plays a large part in this. If a producer does a good job in tasking out the work, it’s easier for the engineer, artist or designer to get started on it right away, without needing to ask for clarification or make corrections. Then further down the line, again, if the task was entered properly, it will provide a good record of how it was executed, how much time was and has yet to be spent on it, which problems were encountered along the way and what was done to overcome those problems. This way, managers or other producers can quickly find out how much progress is being made and how it will impact the bottom line. At the same time, designers, artists, engineers and testers might learn something from the execution and need not waste time reinventing the wheel, should they run into a similar situation. By doing a good and thorough job at tasking out the work and doing proper follow-up on that task, a good producer is not merely communicating with the person assigned to fulfilling the task, but also with anyone else who might be reading it, perhaps at another time and place.
This also pertains to scheduling. With a great schedule, and producer can immediately communicate to the reader where we are in the process of reaching our goals and what the important milestones are. If the reader has to spend time understating the graph, repeatedly looking at the legend and not knowing what the numbers mean, he wastes time, gets frustrated and will, overtime, stop looking at the schedule and inevitably stop caring about he deadlines.
Communication in meetings is perhaps a more subtle art than it is with tasking or scheduling. Some teams prefer it if the producer simply does the administration of a meeting: setting it up, making sure the video projector is working, sending out an agenda and making sure the notes are written and sent out. In some cases though, the producer is expected to be more involved; reign in the wild cards, make sure the conversation is kept on track and that the time limit isn’t exceeded. It is generally agreed that meetings shouldn’t take forever and devolve into useless shoptalk or chitchat, and generally a producer is in a good position to be the moderator. Whichever system is preferred by the team, the producer in question ought to know what is best for the participants and make sure those priorities are executed upon. A good producer is flexible to the varying nature of different meetings, but if needed, is also able to steer it in whatever direction is most productive.
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?
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.
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.
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.
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.
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.
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.
Read more about:
Featured BlogsYou May Also Like
