What Does a Game Producer / Manager / Leader Actually Do?

Posted by Rampant Coyote on February 23, 2011

When I was in the trenches of game development early in my career, I was lucky enough to have some producers / managers who were pretty good at their job. Later on, in other jobs (including many outside of the games biz), I wasn’t always so lucky. A couple of days ago, in response to my little commentary on interesting bug reports, we got into a lively discussion about some producers in the games biz who are pretty much useless. Late White Rabbit even asked – as an experienced Marine with a business degree – questioned the value of managers or “producers” (as they were called in my first company) at all.

One of the things that really shocked me when I released my first indie game was how much of my time – particularly during the latter stages of the project – I spent doing “management” type things. Here I thought, as an indie with a principle team of one (plus contracted help), I’d be rid of that entirely. So I figured I’d post on this – based on my experiences (good and bad), and my ideals of what I think management SHOULD be like in my own little imaginary world. But I was spending a lot of time emailing or talking to contractors, signing paperwork with e-commerce and distribution sites, working out launch & marketing plans (evidently I didn’t do so well, as the game was never a big seller), talking to journalists, working on the website, etc.

So this is valuable stuff for indies, too.

First – a quick review. How things work in theory. These lessons come directly from Mount Obvious, so you should already be familiar with them.

Let’s say you are a “lone wolf” developer. You are really good at just about everything. I hate talented guys (and gals) like you. 🙂 (Actually, I want to be a guy like that, but I hide my aspirations with jealousy.) Anyway, you the lone-wolf can devote your full attention in a  day to your game  – whether that’s a full-time day, or a 2-hour evening working part time, doesn’t matter. Let’s call that amount of work a “zot.” So your productivity is 1.0 zots, and the game gets the full zot. Life is awesome. Ain’t being a lone-wolf indie grand?

Now lets say you are awesome at programming, but not so good at art. Maybe that part of the game development process only has you operating at 0.25 zot efficiency. Or maybe you think you can only achieve your full productivity if you don’t have to be distracted by things like level design, dialog, and so forth. Whatever the case, you decide it’s best if you have a partner. Now there’s two of you working on the game. Should get things done twice as fast, right? Well, not quite. As soon as you have other people working on the game, there’s some overhead introduced involving communicating and coordinating with each other. Let’s say it’s a cost of 0.1 zot. Believe me, it’s cheap compared to the alternative – major, major disasters have been caused by teams NOT paying that cost and the project descending into utter chaos. While not a disaster, we ran into similar issues when I was working on Jet Moto, where some team members had a different vision of the game than others, and ended up generating assets that were totally incongruous with the expected gameplay (and code).

Anyway, both of you are now spending 0.1 zot coordinating and communicating, and then putting 0.9 zots into the game. Now the game is receiving a combined total of 1.8 zots, for 2 people. Not too bad.

Rev it up to three people – say a designer who is also taking on the role of tester, an art guy, and a programmer. With everyone spending 0.1 zot talking to each of their other two team members, that leaves them 0.8 zots working on the game . That’s 2.4 zots spent per day on the game, total. Four guys, the total is 2.9. Five guys, it goes up only a tiny bit, to 5 x 0.6 = 3.0. And then… we bring the team size of six people. same values. If every team member is spending 0.1 zot coordinating and communicating with the other five members, then they are spending 0.5 zots on overhead, and only 0.5 zots on the game itself – for a total of still only 3.0 zots per day.

What? No improvement at all over a team size of five guys? And it gets worse! As the team size expands above six, productivity drops even more with a flat team hierarchy.

I may be pulling numbers out of the air, and in reality guys may spend more time talking to some and not to others, but in my experience the break-down usually starts occurring somewhere between four and six team members where “flat” fails. Also, once you get more than two people involved, politics may happen. Democracies are great for getting people to coexist freely and peacefully with each other, but they don’t work well for getting  a job done. And the more people you have with different roles, the more potential there is for something “falling through the cracks” and not getting done until it’s a bad, expensive surprise.

And that’s where you get some kind of management involved. You break things into a hierarchy. Even something as dumb as the picture to the left will work — now we have seven people working, but only “talking” to the producer (who is probably, in reality, facilitating coordination between members rather than just acting as a single point of communication — this is all theoretical here…) So in this example, adding a seventh person as the producer theoretically brings everybody up to 6 x 0.9 = 5.4 zots. And even the producer may have 0.2 zots left over to do some direct work on the game himself, right?

This gets even more important with larger teams that may have two projects in development at a time.  As studios grow, this is key, as games have different manpower needs during development. Having someone at a higher level who can perceive the “greatest need” and shuffle resources as needed can be very helpful.

Obviously, there are probably much better ways of doing this that would be cleaner than having one dude doing little more than just “managing,” especially for a very small team.  But this was a theoretical exercise to illustrate about where a “flat” model breaks down very quickly, and why some kind of hierarchy gets needed after about three or four people. Anyway, that’s the basic theory, if you have a good producer managing a team. Now we’re going to some personal theories / ideals of my own –  based loosely on what I’ve seen work.

First of all – the rank or position of the manager. This is a tricky situation. And this is why I drew the picture with the team surrounding the manager instead of being “under” him. I do believe, especially for small companies, that management should be pretty much equal in pay / rank to the rest of the team – or at least no different from any of the other “stakeholders.” It’s not unheard of that a small team might actually hire someone to manage them – making the manager their employee. I do acknowledge that the lack of authority may cost them some of their tools. But I do not believe that is necessarily the case, and I think there’s something inherently healthy about the “leader” of a team also being answerable to the people he leads.

Secondly – there are lots of leadership roles on even a small team. Or maybe especially on a small team. Not all belong to one person, but I do believe there should be one person for whom the buck stops with them.  That person is the project lead / manager / producer / whatever. But whenever more than one person may be involved in a task, one person should have the leadership role related to that task. You have the art lead. The programming lead. The design lead (or “keeper of the vision.”) Someone leading marketing efforts. Someone handling the business end of things – particularly when it comes to setting up contracts with third-parties or distributors.  You could have one person doing that role. For many indies it comes exactly down to that, as there’s one person running the show and working with contractors.

But the role is always there, even for lone wolves who must wear a dozen hats daily. Someone needs to be making sure the project ships in a timely manner, doesn’t blow its budget too badly, is of reasonable quality and addresses the needs of its intended audience. In other words, they have to lead the team to success.  Someone needs to have both the will and the authority to cut features and make other hard decisions necessary. It shouldn’t be done in a vacuum, but someone has to have the final say.

One final role I admired in team leads / managers was to be the “mother hen.”  This person, whoever they are, may also be in charge of removing obstacles to the team’s success – whether it is in internal argument between art and programming, or deciding whether or not to buy a new tool for the team that would theoretically boost their productivity.

Unfortunately, as Late White Rabbit noted in his comments, this isn’t all “industry standard” even in the software industry as a whole, let alone the games biz.  Too often they end up doing the opposite of  what I feel their jobs should be. They create long meetings to feel busy and collect information so they can report to their own superiors as if they actually knew what was going on. They nitpick the small stuff, and are afraid to make a decision on the big stuff. Or worse, they play tyrant, and make fiat decisions without gathering information from the rest of the team.  And worst of all, they don’t seem to consider themselves part of the team, but rather someone aloof to the fray.

But then I’ve always been a “lead from the front” kind of guy.

(Updated: Capitalized “Marine.” ‘Cuz it’s right, and ‘cuz they deserve it!)

Filed Under: Biz, Production - Comments: 9 Comments to Read



top