I want to be a professional game producer. I think I am on the right track, having worked my way to a project manager’s position in a media development company. I do understand that I need some actual game development credentials to get a job in the field; I live in a small country and openings are scarce. So I took it upon me to find a volunteer position to train my skills on.
I was a little surprised to realize that I could pick from several promising projects to produce. It looked like a lot of teams had gone to first public demo stage, whereupon they’d spread themselves too thin, lost direction and stalled. I picked one and went with it. It’s been a little over four months, now, and I think I should document my work – to learn from it and maybe help another wannabe clear a few hurdles. This document details what I’ve learned so far.
Do note that this from the point of view of a completely net-based, non-paying team’s producer. I’ve never met my team members; we’re spread across Europe, with a few key members in the United States. By the way, this leads to time-zone trouble, which you need to take into account when agreeing on schedules.
First lesson: the job interview
I got lucky with my position. I had asked for details from several teams, but one of them decided to dispense with that kind of formality and instead talk with me in realtime, on an instant messenger. I liked the no-nonsense approach, which led to me accepting the position without further deliberation. I haven’t regretted my decision, but it was foolish of me.
Taking a producer’s job means that you’ll spend at least half a year, probably a lot more, with a given team and a given project. You need to know it’s not time wasted. I could’ve made myself a lot more secure by talking with a couple of the team’s central characters first, asking to see some art and discussing project plans. I got a little proud, because my interviewer said that they really needed a producer.
Once you’ve weighted your options and attached yourself to a team, be sure to let the other prospects know that you’ve turned them down. No sense burning your bridges, and it’s only common courtesy.
Second lesson: authority
So you got the producer position and you’ve probably only talked with the project owner (team founder) and maybe a leading guy or two. I had to explain myself over and over again to get people to understand what I was going to do in the team. Especially team members with no experience in the creative business (or IT) can have so much difficulty grasping what a producer or a project manager actually does, which is not a whole lot from the point of view of a modeler or a coder.
It took time to assert my position. My presence was only really needed when the first crisis hit. Then a person whose foremost interest was to keep the team together really came useful. In those first months, the only skills I really needed were people skills. I had to study my team to understand what made them tick – I actually took notes and kept records about dealings with them. Like “hmm, I haven’t spoken with Tim in two weeks, I need to drop him a letter”.
Getting authority is essential, because you need to be able to get people to do what you want, but at the same time it is absolutely vital that they respect you.
With a couple of months in, I’d gotten better at describing what I do in layman’s terms, and people seem to accept me quicker. Of course it’s of utmost importance that you need to figure out who wield the power in the team and be square with them. My team has two people with authority and I cannot at any circumstances be in less than stellar relations with them. In a sense, I think it’s necessary to team up with the senior staff against the juniors, whenever there’s a disagreement. That way you can ensure that the core team stays intact. Of course it’s preferable that things never get that far and it may be that your team’s dynamics differ from my experiences, so take this with a pinch of salt!
Third lesson: communication
I knew that I had to find out how the team was used to communicating, but I didn’t think I should step on anyone’s toes while at it. Well, I’m that much wiser now. We threw a lot of time and effort to the dogs, trying to work in fourteen different ways – because there were fourteen of us. It doesn’t work that way.
You need to figure out what communication methods serve the project best and make everyone use those. So, yes, we use IM, email, IRC, a forum and text messages (SMS), but it’s not the anything-goes carnivale it used to be. We now have only two IM clients, everyone uses the team email (email@example.com) and everyone frequents the forum. We’ve made these mandatory, not options: you have to check your email and the forum regularly. You have to attend the IRC meetings.
It’s the producer’s job to know what everyone is doing and getting people to talk with each other. I’ve made it my priority to say hi to folks whenever I see them online and find out if they’re having any trouble. Problems in interpersonal relations multiply in the internet – never let bad things gain momentum. Never believe that they’ll just go away if you continue to ignore them. This goes double for the producer: solve your own issues right away, lest your authority erodes. I try to get my team to confide in me so I can relieve tension before it becomes a problem.
Fourth lesson: organisation and workflow
You’d think that actual project management skills would fit in at some point, but they were actually the last major obstacle I’ve mounted with my team! This is simply because getting the communication and relationships right took so much time. If there’s one thing I want to do differently the next time, it’s clearing the introductory phase quickly, although I don’t have any good ideas on how to go about it.
I recommend a project management tool. I’ve been using BaseCamp for some time now. I like it because it has all the features I need (calendar, milestones, to do lists, messages) and none of the clutter I don’t need. I’ve also used it at work; I love the way the dashboard shows where I’m at with all of my projects, not just the one I’m working on currently.
We’ve had to explain the same things over and over again. This was resolved by setting up MediaWiki with all of the newbie information and the stuff we’ve found people are asking about from the senior staff all the time. It’s worked very well.
You need the team leads (art lead, code lead at least) to take control of their staff. We tried several ways but found that a separate forum board works best for us; people fill in whatever they’re working on and the team leads can shift priorities and see what everyone’s working on. Because everyone can see the posts, it also brings the team together. We assign goals every other week and go over them in our weekly IRC meetings.
One thing we should’ve done a lot earlier was trying to estimate the workload. When we finally did, it became clear that we couldn’t handle the outcome we’d gone for. It’s going to have to be scaled back at least one third to be feasible, simply due to the modeling and playtesting required.
Fifth lesson: getting people to do what you want
I had to get my team leads to really organize their teams. However, we couldn’t find a solution until I imposed one. When I did, they didn’t like it, and this threat of having to use something they didn’t like was enough to get them to come up with a much better solution. So when talking doesn’t help, try just going for a solution, but leave it open to discussion, if someone should object. Often people don’t know what they want, but they know what they don’t want, which is one place to start!
Sixth lesson: rules
I touched on rules earlier, but it’s really crucial to have rules if you want to get things done. We waste a lot of effort with guys who do not stay with us. It would be best to make sure from the get-go that they understand how much dedication your team is asking for. This is amply illustrated by stating the rules. For instance, we have rules on communication: you can not go off the radar. If you do, that’s grounds for letting you go.
Many folks take rules in volunteer projects in a bad way, but I just don’t believe you can get a project with more than a couple of staff done, at all, without enforcing rules. You need deadlines, you need quality control, you need critique, you need discipline.
People don’t take the project seriously if you don’t, and that means you need to bring up all rules breaches. The producer does protect his team, but it also means that he needs to protect it from itself.