The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Over the years, I had mentored a few select individuals for associate producer positions in the hopes of growing a garden of local people around town that knew what they were doing and would spread good habits to the studios they end up at. The crazy grand master plan was to nurture a culture of good production habits that would seed the population of producer talent in the city. This was to be a counterforce to the bad production habits in various places I had become aware of, past and present.
My primary job is and will likely always be that of programmer (by choice), but the producer role has such a strong influence on my work environment that I wanted to affect the odds of working with a good producer by mentoring potential associate producers who were open to influence.
There is no shortage of bad producers in this industry. The role of producer can be an unfortunate dumping ground within the company. The best producers I know are exceptionally sharp individuals who grew into that position through the purest intentions in the best interest of the project. The worst producers I've heard of reached that position because there was no other place to put them... and these bad producers would mentor associate producers until the bad habits spread like a pestilence within our industry's DNA.
As part of the mentoring process, I would write these starter notes for the protegé to establish a measurement of their baseline potential as a producer. The protegés were not aware that other protegés existed... until now.
I started this document in 2005 as a favor to a friend who was looking for a job at the time. The notes would evolve over the years as I evolved... the result of things I had written for myself when interviewing producer candidates at previous jobs as well as things I would look for when interviewing with new potential employers. Also incorporated into these notes is illuminating advice that I've collected, filtered, and relayed from various successful producers both inside and outside of the games industry. This is the first time I am sharing these starter notes with the general public.
So without further ado...
Kain’s Notes on Becoming a Producer (or Associate Producer)
I know you’re gunning for an associate producer position, but I’m going to treat this doc as if you are going for an executive producer position. They both have the same goals, even if one does more than the other. Practice what you can. Some of this stuff may not apply. Some of this might even be wrong. Some of this, you won’t be able to do because you are an associate producer and your boss has his/her own ways of doing things that may be better or worse than what you think is best. You still need experience, because I might be wrong. This list is obviously not complete as people write entire books on this subject. Either way, this silhouette can help paint a picture of what you're shooting for.
What Do Producers Do?
- They lead the effort of getting the game finished on time and within budget.
- They can be the voice of reason that pushes to reduce the scope of the game if the design is too ambitious for the resources
- They make schedules, minimizing chronological dependencies between tasks so that nobody is blocked and waiting on somebody else to finish their task.
- They make budgets, taking into account the salaries, application tools, and license fees that need to be paid for
- They notice problems with workflow and find ways to fix them.
- They are leaders, part of the management circle. A good producer can carry the team to victory, and a bad producer can cause the studio to shut down.
- They communicate the work process to the team
- They make sure everybody knows what they should be working on at any one time.
- They adjust the schedule as needed, but also try to plan as much as they can early on so that little adjustment would be necessary.
- They can deal with the press by providing review copies and giving interviews that make people want to buy the game
- They can be a liaison between the development team and anybody above, like the studio director or the publisher’s representative (the external producer)
- They may not necessarily solve every problem, but they do make sure that somebody is assigned to solve it
- They may possibly pick up whatever leftover slack they can take using whatever skills they happen to have to help balance everyone’s plate (including their own) as best they can
- They are in charge of ordering food for the team if the team needs to work late
- They make sure there that documentation exists for tracking logistical issues such as equipment purchases and inventory status
To paraphrase a colleague of mine (Scott Foe): "A Producer does what nobody else wants to do."
- Some scheduling software – Make sure you get your hands dirty with some type of project management software. Examples of scheduling software include Microsoft Project and Hansoft. Be prepared to learn a new one when you start the job.
- Wiki - Everybody on the dev team needs to have one or more technical skills that say they are not just some schmoe that got the job because they have a great personality. I suggest one of your special skills be working with wiki and possibly bringing it to a team that isn’t using it but needs it. This is one of those hot topics in the gaming industry, these days, because it solves the problem of people on a team not knowing how to do things because nobody writes it down. Email is a horrible way to relay workflow instructions that get used throughout the project cycle. You could be the person to write it down or schedule another person to write it down. Get to know this wiki thing, and embrace it. Maybe even see about introducing this at the place you work at now. The idea behind wiki is that if somebody quits, gets fired, or dies, then their knowledge will live on within the wiki page that lives on the intranet. You may have to work closely with your IT person to get this started, but it helps if you know enough about this to set it up yourself.
- MS Powerpoint (or OpenOffice) – Just in case you need to present something to people outside your team
- MS Excel (or OpenOffice) – Maybe. Spreadsheets can be useful sometimes for tracking things
- Reading manuals and learning how to use new things: burning discs, taking and packaging screenshots, capturing video... whatever it takes to get that odd job done. Anything you can't do affects somebody that might be better utilized towards their primary function.
Good Producer Qualities:
- They keep meetings short and on track – It’s really easy to start clowning around during meetings, as being in a room full of devs can be like being around a bunch of grown up kids. Keep the group as small as possible and don’t let the meeting sidetrack into tangent discussions. You may end up saying things like “Let’s take that discussion offline” to keep two people from boring the rest of the group. You may also end up scheduling a more focused meeting if you need to go into detail. Your goal at the end of the meeting is to have a plan of action that wouldn’t have been possible to come up with if you didn’t induce this interaction. To prove that the meeting wasn’t a waste of time, commit those actions in writing as a task listing to the attendees and adjust your schedule accordingly.
- Updates the schedule once a week or more – Things change. People forget tasks. Time estimates may be wrong. The schedule is your bible. This is what you turn to when somebody needs to add a new feature, or when your boss asks you how the project is doing or why the project is falling behind. Numbers don’t lie, and that makes the schedule your main validator for the producer job. You don’t have to have everybody in a room telling how they’re doing because that just wastes time for those listening. Instead, the team should have some means of letting you know where they’re at in their part of the schedule.
- Communicates in a non-intrusive manner – This is tough… people like when producers stay out of their face and let them concentrate on work, but they need producers when they want to know who should be doing what and how things should be done. Wiki might work, here… or maybe a group email status update. Whatever the case, it’s up to you to choose the method that works best for your situation.
- Good interviewing practices – A good producer will take an interest in making sure every hire is somebody that went through a formal gauntlet with the full approval of all those that are currently working on the team. The problem with interviews is that people tend to be too busy working to have time to do good interviews. So what the producer can do is make sure there’s a plan in place that can be initiated for any person coming in for an interview. This plan includes a bank of questions to ask (provided by each discipline) as well as an itinerary for where the person gets escorted through every step of the process. The team you hire can make or break your reputation as a leader.
- Sees the big picture – The producer knows salaries, financials, and studio strategies… and this stays in her/his mind through the entire process.
- Catches problems before they happen – based on your experience, you have a bird’s eye view of the project, and seeing the big picture can catch issues before they have a chance to fester
- Knows a little bit about everything – She/he may not know how to write code or animate a model, but she/he knows what software programmers and artists need to do their job and what vocabulary to use for relevant features. And the learning never stops because tools are always changing.
- Doesn't let things slide – If somebody mentions a problem or issue with a process or another person, then a good producer will always make sure that side quest reaches an intentional conclusion.
- Turns everything into a time estimate – A producer shouldn’t just say “no” to a new expensive design feature that gets put in. Instead, the producer would say “We can’t afford to spend three days on this feature unless we sacrifice something else that takes three days because we have a milestone on X date.” With everything being put in terms of time, then nothing becomes personal. Numbers don’t hold grudges, nor do they play favorites.
- Stay as late as the team - When the team stays late, it’s usually because the producer asked them to stay late, and so the good producer will stay as a sign of solidarity. She/he might pass the time by serving as additional QA, playing the game and writing up bugs for the database.
- Is a highly empathic people person with good social instincts - This is probably the defining quality of this discipline. Like all other disciplines, they are problem solvers, but gifted producers particularly excel at incorporating behavioral dynamics into their problem matrix. The ideal interaction between a producer and their team is one of trust, honesty, and respect for each discipline to shine in their own categories.
- Always trying to improve – Like any discipline, there is no official best way to be a producer, everybody is still trying to figure it out… the tools, the hiring practices, the communication, and the scheduling methods. Nothing is set in stone, including what I’m writing in this document. In essence, the producer is just a really good problem solver who finds the best way to identify problems that need solving.
Bad Producer Qualities:
- Makes the team stay late for crunch and then leaves at a normal time to enjoy a regular evening for themself - I can't stress this enough: If your team crunches, then you crunch... because it is partially your fault. It is your responsibility to reduce scope and find that happy compromise between art and life.
- (Pertains mainly to large projects) Usurps ownership of Game Design authority - It’s okay for every member of the team to have input on game design, but it is bad if the producer’s pet design features end up getting priority on the schedule without any design delegation from the creative director. If you ever find yourself on a team where the producer is calling the shots on aesthetic design decisions, then run. Run very far away!
- Doesn’t write anything down – Many of us have worked with bad producers who would never write any tasks or schedules down. Nobody knew what they were supposed to do or who was supposed to do it. These producers sometimes get fired, but not always. A lot of times, these producers tend to be really nice people who get by on the charity of their coworkers.
- Downer Personality – Low Morale can be a dangerous thing for any team. It makes people slow, lazy, and at worst, they start looking for other jobs. Once you cross that line from trench worker to manager-type (Producer), you’ll have to walk a thin line between having your team trust you to be honest, yet still make them feel good about working on the project. You might have to bury your feelings in the name of professionalism. If trench workers see that their leader is down, they will be demotivated as well.
- Can’t separate talent from personality – You have influence over whether people on your team get raises, promotions, action plans, and/or terminations. Being a cool human being is an important part of loving what we do for a living, but at the end of the day, we all have a job to do. I believe that it is possible to have a workplace that rewards high standards without losing humanity.
- Won’t fire anybody no matter how bad they are – This is a continuation of the previous point, but if a studio ends up getting a cancer, then the cancer will continue to grow unless it is surgically removed. It’s hard to have to fire somebody if you like them. Be mentally prepared for this from day zero. Anything is possible, and it doesn't have to be personal.
- Promotes nepotism – Nothing can bring a studio down faster than hiring a bunch of friends that aren’t necessarily good at their jobs. It’s ok to hire people that somebody has worked with before and found to be a good employee, but loyalty can’t be the only reason to hire someone.
- Assumes that crunching is a normal part of the schedule – Crunching comes from trying to do too much in too little time. That could be the designer’s fault for coming up with too many things too late in the game or the producers fault for not putting her/his foot down when she/he needed to. This is a touchy subject amongst devs. Not all game devs believe that crunching can be avoided with good scheduling. Read the people around you and adapt. They may either think you are naïve or they will think you are one of the good ones who share the same religion as them.
- Freaks the team out by constantly telling them how grim things are and leaves the team in “firefighting” mode instead of taking actions to prevent fires - You may see these types of producers spend their free time drowning sorrows instead of working extra hours to make sure fires don’t happen again.
- Says yes to everything - It’s tempting to be a people pleaser
- Says no to everything - Instead of saying no, you can give them a reason why the answer is no and suggest an alternative or compromise.
- Does Not Know The Product - It is a huge red flag when your producer does not know how to test or demonstrate features in the game for which they had been tracking tasks for. This is an indicator that the producer has lost sight of the product's end goal and sees their job only as a spreadsheet administrator.
- Focuses on the Blame Game - Mistakes will happen on the project. There is no way to avoid this, but there is a way to keep the culture of the workplace from being consumed by fear to the point that people start playing the "office politics metagame". Instead of chasing people down to hold them accountable for human mistakes, collaborate with people to find ways to steer this jointly-owned process towards something that they can work with. As a producer, you have a choice to either pull rank to get things done or frame yourself as a collaborator at the team's service.
- Believes they have nothing more to learn - People are either getting better at what they do or they atrophy at what they do. To believe that one has nothing more to learn is to hit a ceiling, and there is only one direction to go from there.
Interview Questions for Producers:
- At what point do you realize that you need to fire someone and how would you go about it? I like this question because I’ve heard of people who just would not get fired because they were friends with the right manager. It’s really hard to fire somebody, and so I consider it a red flag for a producer to not have a good answer for this. Usually, the good answers go along the lines of they have the discipline lead give warnings and some plan of action to fix themselves along with a deadline to fix this by. If they don’t fix this by the deadline, then they fire them and let the team know (in a face to face group meeting) what happened and why. Emails on why a guy gets fired can be dangerous for legal purposes, so people usually do this verbally.
- How would you go about scheduling game X from start to finish? (Where X can be anything from World of Warcraft to Soul Calibur) This question is designed to see how much you know about the dev process for the games that they’re hoping to make, and it also gives them a feel for your scheduling philosophy. If you like doing homework, then I’ll give you a homework assignment. Pick some games, bad games, good games, games you’ve worked on, and come up with a task list for those games. Send that list to me, and I’ll tell you if you’ve missed anything to the best of my ability. Getting a complete task list for any game takes practice, and I can help give you that practice. (note: For this public Gamasutra blog, I will not necessarily do that for you). In the real world, you would delegate task enumeration to discipline members. This exercise forces you to get better at being cognizant of the work that goes into a game, and it becomes easier as you gain EXP.
- Why would you want to work here? Be honest, but also be aware that everybody wants to work on sexy games. You want to be an associate producer because you want to be a part of a team that does things the right way. And you want to work with cool people. Small companies will ask this question to screen if you might run away if you find something sexier to work on. Large companies will ask this question for no good reason in particular, but it’s always good to have an answer ready. This is a good time to tell them what you would like to see in a workplace.
- What are the types of difficult people you might work with? How would you handle these difficult people on the job? Aggro-nerd? Skeptical cynic? Checked out space cadet? This is where your people skills come into play.
Other Interviewing Tips:
- Read the hiring producer’s personality. Some producers might be territorial, looking for nothing more than a yes-lackey. This is bad, but sometimes, you have to put up with crap when you’re trying to get your foot in the door. Don’t make your potential boss feel threatened if they can't handle your crazy ideas. There are still many working producers in the industry who don’t believe in a formal production process, and they may disagree with the concepts I’m listing in this doc. Keep an open mind: This doc might be wrong, and they might be right.
- Different studios have different power structures of leadership between the producer, creative director, and possibly a project leader. Assume nothing. Prepare to stay flexible on what your expected responsibilities are. In fact, a good interview question from you to them is to ask “What are my responsibilities?”
Useful Internet Resources:
Wikipedia’s Definition of a Game Producer – There are two types of producers described here, internal and external. You want to be an internal producer… specifically a line producer.
This is a very good how-to article on dealing with the press. Having a good relationship with press is important. Treat them well, and follow the rules of this article.
Scrum seems to be the dominant poster child of production methodology starting from 2007 or so to the time I am writing this sentence. When used correctly, it can be nice. When used badly, it can really suck.