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. This is the third and last part.
TO FIND PREVIOUS CHAPTERS: http://gamasutra.com/blogs/author/MattPowers/951858/
INSERT INTERESTING, USEFUL, AND ENTERTAINING STORY HERE
NOTE: I had a story which would explain this rule but just prior to publishing I was asked by one of the groups involved with this story that I hold off publishing it at this time. It was a polite request and one I am happy to go along with. While I am disappointed I can't share this story with you at this time I understand the reason. Hopefully at some time in the future I will be able to share the full, unedited Producerland story.
Many times in my career I would purchase copies of "The Design of Everyday Things" by Donald A. Norman. And I would give these books to designers on my project (and anyone involved with design, especially interface design).
This was a book recommended to me while I was working for Apple. Apple is well known for its interface design and I was told this book was like a bible for interface designers.
Here is a description of the book from Wikipedia:
The Design of Everyday Things is a best-selling book by cognitive scientist and usability engineer Donald Norman about how design serves as the communication between object and user, and how to optimize that conduit of communication in order to make the experience of using the object pleasurable. One of the main premises of the book is that although people are often keen to blame themselves when objects appear to malfunction, it is not the fault of the user but rather the lack of intuitive guidance that should be present in the design.
I recommend this book to everyone.
People often want strong management, not necessarily for themselves, but for the other people on the team. People will believe they have their "shit together" but they will worry if the others on the team are carrying their weight. They want you, the producer, to manage the team - to ensure others are doing their job so they won't have to worry about it.
It is amazing the amount of time people will spend worrying about what others are doing rather than just focusing that energy on ensuring they, personally, do a good job.
But also realize that being Producer doesn't necessarily mean you come up with all the solutions. Often you confirm the decisions others have come up with but don't feel they have the authority or responsibility to make.
People would come to my office to ask what path should be taken. A very good response from the producer is, "What do you think?" Often team members have a strong idea of what should be done, but they don't feel comfortable taking responsibility for that decision. And, they may not be aware of other issues/factors on the project that could impact this decision. It is important for the producer to listen to the ideas from the team members and often the producer should go along with those ideas. And the team expects(needs) the producer to make the decisions.
I am a stickler on agenda and meeting notes. Every meeting should have an agenda. If it is your meeting - even more so. And then, if it is someone else's regularly occurring meeting and they don't make an agenda, volunteer to make one for them.
Send the agenda out a couple hours prior to the meeting (or maybe a full day). This will ensure everyone knows what is to be discussed. The agenda should have the action items from the previous meeting. This way everyone knows what is expected for them to deliver/report on at this meeting.
For either phone or in-person meeting - have an agenda.
The agenda with its notes is a great record keeper and a great way to track and ensure tasks are completed. It helps ensure people come prepared to the meeting. It also helps keep meetings on track and on topic.
I consider instant messenger the "instant interrupter". There is nothing that will hurt productivity more than having people getting messages at random times constantly throughout the day.
I read a study once that said when someone is working at full productivity and is interrupted (real-time interrupts), it could take 20 minutes (or more) for that person to get back to that same level of productivity.
Email is a great tool:
And when writing your emails do not skimp on the characters. Write in detail; repeat yourself often; use bullet points for people who like to skim through their mail. Reread your emails and answer questions in the email before the responder needs to ask.
The milestone payment is meant to pay for the work already completed. For many developers this milestone payment goes right into their employees paychecks. As a producer we should constantly be involved with the upcoming milestone. There should not be any surprises once the milestone date comes along.
If a milestone does not meet expectations, then whenever possible, the required changes should be put as requirements for the next milestone. Don't get bogged down having a deveopment team resubmit milestones. This is demotivating, loses time, and often focuses on the wrong priorities.
Keep in mind:
Recommendation: With milestones I would often ask the developers to provide me their assesment of the milestone. Where does the developer feel they overachieved in the milestone? Where do they feel things feel short? Ask the development team to asses its progress on each milestone. It is important for the producer to know what the developer thinks of the work they are supplying - make sure the developer tells you.
When working with a developer, it is important for the producer to have a good relationship with the developer. But at the same time, on every project some pressure often needs to be exerted on the developer. I always make sure I have a "heavy."
On more than one occasion I would be on the phone with my counterpoint producer at the developer. I would say something like,
"My boss really needs that updated schedule [or whatever] from you and he is on my ass about it. He needs it right away. Could we really try and get it done? " [Being understanding is important]
"I know you are super busy but if WE can get this done and to my boss it will make getting some approvals easier on this end." [Always find a way to assist - this is something 'we' need to do, not 'you' need to do]
"What can I do to help us get this done?"
Then I would go into my boss' office, and tell my boss -
"By the way, if anyone asks, you REALLY want the schedule (or whatever) done right away."
While at Electronic Arts, I had the privilege of working with the Medal of Honor Society. As Senior Producer on Medal of Honor, I was honored to be invited to attend the Medal of Honor Society banquet in Branson, Missouri.
The banquet hall was filled with heroes from World War II through the Korean Conflict. Conversations tended to steer away from war experiences, and we spoke about their grandkids and their hobbies. At one point after the dinner, speakers come up and miscellaneous awards were presented. I will always remember one of the speeches.
A gentleman came up to the stage, his tuxedo covered with medals, and he took the podium.
"I love spam," were the first words he spoke.
He went on to describe his involvement in the Pacific Theatre of World War II. In particular he spoke about a beach landing with his squad pinned down in a mortar hole. As they were hunkered down waiting for orders, he grew hungry. From his pack he pulled out a can of spam. As he was opening the can the squad received orders to move up. The group quickly climbed out of the hole and moved up the beach. In the excitement our hero left his can of spam behind. They arrived at another ditch further inland and again hunkered down to wait. Still hungry, our hero decided to crawl back to the previous hole to retrieve his Spam. As he left his squad to retrieve his lunch, to get back to the spam he left behind, a mortar came down and landed in the hole he just left - injuring most of his squad, killing some. He was then able to return and rescue much of the squad that were hurt by the mortar.
"I love spam," he repeated solemnly.
It is amazing how my appreciation for Spam has changed after this.
There is the adage, "Rules are meant to be broken." That can certainly the case in the rules I have outlined here. While we strive to make game development a science, there is still a lot that that is out of our control. And if anything, the producer needs to be flexible and adjust strategy and direction throughout development.
I do hope these rules can be a starting point for discussions. You may agree or disagree with many of the rules. You may have your own rules for getting through product development. I would love to hear them. I would also love to hear your stories from the trenches. Sharing our experiences can help us all learn and become better producers.
On the GameCareerGuide site you can find another article I wrote that was just released. The article is about my definition of a Producer. It is entitled "Do you play games all day?" This is a companion article to Producerland. In this article I give a bit more detail on what I believe who a producer is and what they do.
Matt Powers has been making video games for over 20 years. Matt has enjoyed his years in game development and looks forward to many more years to come. And hopefully more stories to share.
Article help from: