Welcome to Producerland - a three part series sharing tips on being a producer and stories from the field. Producerland defines "10 Rules" for producers and shares stories that cover "easpouse", Unreal, Medal of Honor, Infinity Ward, and many more. The 3 parts of Producerland will be posted over the next week.
PRODUCERLAND - PART 1 of 3
In the movie Zombieland our hero creates "rules" to assist in his survival during the zombie apocalypse.
I have always been a big fan of anything zombie related. While watching Zombieland recently, I realized there is a slight similarity between Zombieland and Game Production.
While rules such as "double-tap" or "always check the back seat" may not be exactly applicable to video game production there are rules I have found in my years that I believe have helped me being a producer. I believe these "Producer Rules" could not only help any producer working on a project but could, just maybe, be useful in a zombie apocalypse.
The rules I have come up with for producers are not hard and fast. Nor is this meant to be the end-all complete list. I just picked the ten rules that stand out to me the most from my years of experience. This is hopefully a guide for all producers. If not to use, then at least to start conversation and debate.
Ten rules from both Zombieland and Producerland:
We should always be learning - AND - All of us, can always use a good mentor.
No matter how much experience we have, we should always be in a state of learning. We learn from everyone around us, but I feel most important is learning from a mentor. As a producer you may manage teams and/or other producers. Part of your responsibility is to teach/mentor these people. And hopefully in your role you have a manager who is a mentor to you.
The Unrealistic Manager
My boss was very interested in being constantly up-to-date with what the developer was doing. He made it clear that it was my job to be sure we had the latest information on all aspects of the project. This sounds reasonable but the developer in this situation did not cooperate. The producer at the developer, my counterpoint, needed the okay of his boss before he could send me project information. And, most of the time his boss did not want to send me, the publisher, the work-in-progress.
I understood this was because there was an innate distrust at the developer for the publisher (any publisher for that matter). The developer was concerned about sending the publisher information and details before they were fully fleshed out. This happens and needs to be worked out - trust needs to be in place - but that is a different story.
In this particular situation, the developers lack of cooperation did not deter my boss who continued to let me know that as producer I should have all the details, all the time. So I let my boss know that I needed to elevate this - I needed his assistance to clear the blockage and get the project details we needed.
My boss and I got on a conference call with the head man at the developer. My boss went through the list of requests,
"I would like to get the latest script from you," he asked.
"We are not ready to send that." The developer replied.
My boss would make a small mark on his paper and move to the next item.
"When will we receive the next build?"
"Still working on that, you'll get it when it is ready," was the reply from the developer.
"Could we get the latest, updated schedule?" My boss was persistent.
"Do we have a final level count?"
"Not at this time."
And so on. It was clear my boss could not get the information any more than I could. I felt a bit vindicated. And now I was hoping the two of us could strategize about what to do next - what was the best way to manage this developer.
The call ended and my boss turned to me:
"You may have noticed that I could not get the information either."
I nodded my head, "Yes I did."
"Well, I still expect you to get everything."
Sometimes we can learn from our bad managers as well as our good managers.
Adapt your management style to the team; do not expect a team to adapt to your management style.
Many times I have seen teams fail or relationships between developer and publisher fail because of an unbending producer. A producer who needs things done his way (and only his way) will have a tough time being a successful producer. Someone who manages to the strengths and weaknesses of the team, the budget, etc... will probably find greater success.
When I was offered the position at Accolade I was told straight-away, "This is a troubled team and problem project." The team had gone through a number of producers and the project was not doing well. Accolade had interviewed a number of producers and the team didn't like any of them, except me. I was told that the company did not expect the project to finish - it would probably be cancelled. But this was a win-win for me - cancelled, not my fault. Not cancelled? I would be a hero. Also, they were considering firing a couple members of the team but would leave that up to me.
The team was what I would call a "maverick" team. They worked together prior to being hired as a group for Accolade. They were not accustomed to working with or at a publisher - not accustomed to much in the way of authority at all. Where I initially appealed to them, I believe, was my developer background and my programming abilities. They probably saw me as one of their own.
What I found out is that this team, along with just about every team you will meet, wanted to make a good game. They were willing to work hard to do it as well. But they had their own way of doing it. Immediately it was obvious that "core work hours" was not in their vocabulary. But unlike producers before me who tried to get them to work core hours, I didn't let that bother me.
My job was to make sure there was a detailed schedule and that everyone was on top of their tasks. When they did the work? Didn't matter; just get it done. This was especially true with one of the artists. This particular artist was one of the people the company was planning to let go. I looked into it and learned that this young guy recently had a child with his wife (who also worked) - and they only had one car. His work hours and ability to even predict his work hours was very sporadic. So we made a deal - as long as he got his work done he could do it at home, after hours, on weekend, whenever. With this freedom the artist flourished. And I am proud to say that within the next two years he became one of the best artists in the company.
And Eradicator shipped on schedule and received good reviews.
As producer, you are responsible for EVERYTHING related to project.
If a producer I am managing comes to me with concerns about the marketing support they are receiving on their project, one of my first responses will be, "Well, what are you doing to supplement the marketing to make sure it is successful?" Finding the flaws in the development/publishing process is important for the producer to do. But more importantly is for the producer to be actively finding solutions - to all areas related to the project.
I tell any producer that works with me that they are responsible for everything related to the project.
I had the unique opportunity at Accolade to start a project from scratch. This included picking the people and the project. So a couple of us found a corner of the building and started working. The main idea we had initially was to create our own 3D engine. 3D engines were hot at this time. You had Quake, Unreal, Prey, and more. Everyone was going full-on 3D. And we had the 3D cards battling it out: nVidia, S3, 3dfx, Intel, etc.. We didn't even have an API people agreed upon, there was: D3D, Glide, OpenGL, etc...
Over time we were able to get our 3D engine done (we called it the Ecstasy Engine) and we got a game going. The team went from a handful of us in the corner of the building to a full team of over 25 people. We shipped for the PC and as a launch title on the Dreamcast.
There were many challenges during the development of Slave Zero but there was one challenge I learned from the most.
A little more background: you need to realize that Slave Zero is a giant robot game set in the future based on the style of Evangelian Manga. Yeah, sounds cool - it is - but this was being made by the company whose bread and butter was Bubsy and Hardball. Slave Zero was way out of their wheelhouse. Early on I had frustrations with my publishing team that Slave Zero wasn't getting the support I felt it deserved. Not the marketing, PR, nor sales support. That was when my boss told me, "You'll just have it do it yourself."
This simple statement opened my eyes. A producer is responsible for EVERYTHING. With this enlightenment I went forward on this project (and future projects) doing whatever I could to assist marketing, PR, sales, etc...
As a producer one should expect to:
- Do press interviews
- Be available for presentations
- Work the tradeshows
- Go on sales visits/trips
- Make sure marketing/PR/community all have information about the game
- Try your best to get marketing/PR/community the assets they need to do their job
- Be active in marketing and PR meetings
- As I said, the producer should be invovled and ready to assist with everything
The people are your greatest asset and resource
Always remember that everyone up and down the line is necessary to get the project from concept to the shelf. Everyone is needed and everyone is valuable.
Electronic Arts Los Angeles
There was a time while I was at Electronic Arts Los Angeles (EALA) when we had 3 internal projects all in crunch mode. At this time we had at least 300 people in the studio working 10+ hour days 6-7 days a week. In the evenings meal tickets were handed out that were color coded to denote what time you could go get your dinner in the cafeteria - we had to separate groups by time as the cafeteria could not support everyone at the same time.
This crunch mode went on for months. I recall on my particular projects meeting with the execs and in our meeting setting an "end date" for crunch. During these meetings someone would sometimes remark that we may not actually be done by that date. Well, then we'll just move the date out to a later date. Basically, keep the team crunching with a false end date to keep spirits up - then move the end date and repeat.
This was not a happy studio at the time. The projects did get done eventually. This also led to the infamous "espouse" episode.
The easpouse letter can be found here:
During this crunch I also recall that there was no problem hiring more people to help us meet deadlines. EA had the money. Personally, I was concerned because we had so many people there was no way we could support them after the projects ended. I soon realized this was not a concern of the company.
Months after the projects finished (and after espouse), we had a company meeting. I distinctly remember our President standing up, thanking us for the hard work, and letting us know that changes were going to be made - this wouldn't happen again. One thing I will always remember him telling us,
"And from now on - no one works on Sundays!"