Sponsored By

Producers Of The Roundtable: Structuring Your Team

Gamasutra's latest 'Producers Of The Round Table' discussion looks at team structure, with producers from Gas Powered Games, Stainless, Red Storm and Freeverse analyzing how game teams are constructed to function smoothly.

Juuso Hietalahti, Blogger

July 4, 2008

8 Min Read
Game Developer logo in a gray background | Game Developer

[Gamasutra is partnering with GameProducer.net, a game production resource, for a series of Q&As named "Producers of the Round Table". The Round Table is a place for producers who work in game industry to present their opinions in response to questions. The most recent article in the series dealt with "getting coders and artists to communicate".

In this installment, which deals with programmer and artist communication, participants include Robbie Edwards, senior producer at Red Storm Entertainment, Ben Gunstone, production director at Stainless Games, Justin D'Onofrio, producer at Freeverse, and Frank Rogan, producer at Gas Powered Games.]

How do you deal with structuring your team in terms of different disciplines reporting to leads?

Robbie Edwards: Underneath the producer, we have leads for design, art and engineering for their respective departments within the team. We then break down the departments further into disciplines that are small groups of similarly skilled developers lead by a single workgroup coordinator. For the most part, these workgroups consist solely of one department, but in a few cases, they are cross departmental.

Ben Gunstone: On all of our games we have a lead artist and a lead coder. Ideally we also have a design lead as well but with the smaller download titles that design lead is normally spread across multiple projects. From there it is completely flat.

Our teams are smaller, though, than normal retail products, normally looking at two to three artists and two to four coders per game, so there isn't room for any more levels of hierarchy.

Our leads also spend most of their time doing their scheduled tasks and don't need to spend much time on team-management - mainly as the teams are so small that communication is so much easier. It's also helped by the fact that we always position team members together in the office. They are also supported by me and our assistant producer.

Justin D'Onofrio: While our current project calls for a smaller team, we still have a hierarchy in place. On the coding side, we have a network lead programmer, who reports to the project lead programmer. There's an assistant programmer who reports to both of these folks. On the art side, we have a 3D modeler, who reports to the creative lead (also the 2D artist). Both leads, and an assistant producer, report to me as producer.

That's in the office itself. Remotely, we have an audio engineer. He's considered the audio lead, and has as many of his own folks at his west coast studio reporting to him as needed. Also on the west coast, we work with an art studio, where an art technician reports to an art manager, who then reports to both myself and our creative lead.

Frank Rogan: We have leads for the traditional disciplines - engineering, design, art, animation, etc. - and those leads serve as both the discipline leads as well as in an advisory capacity with the producer for the project itself. It's a pretty traditional model.

Do you have a lead animator and a lead modeler reporting into a lead artist?

Frank Rogan: On previous projects, I've seen the lead animator serve as a separate lead and team from environmental and character art, although the two groups obviously work very close.

On other projects, one lead artist oversees both art and animation. That's a significant chunk of work, though, and requires someone very special in that role. Thankfully, I've enjoyed working with just such a person!

For modeling, I've not seen it broken down so that there's one lead modeler. More often, I've seen it broken down into areas of expertise - as in, one modeler is particularly good with certain types of characters, while another is better at modeling key environmental props.

Justin D'Onofrio: As we're working remotely with our art studio, it's a split structure. The studio's art tech reports to their art manager, who reports primarily to our in-house creative lead. In-house, our 3D modeler reports to our creative lead.

Robbie Edwards: Organizationally, yes, but not with those titles. We refer to our workgroup leads as coordinators (i.e. Animation Coordinator).

Do you think a more flat or "pod"-based structure works better?

Frank Rogan: Flat structures are obviously best for communication, a shared sense of purpose and a speedy, useful approval process. It's very easy to stratify the team structure to the point where the stratification becomes meaningless.


Frank Rogan served as producer on THQ/Gas Powered Games' Supreme Commander.

At the same time, a "pod-based" structure - a team divided into functional, cross-discipline groups - sounds like the best of all possible worlds, but that can fall on its face, too, if there's no clear leadership within the pod. Pods can work, but it requires a special group of people. If the nature of the problem requires cross-discipline skill, and it can be time-boxed, I'm much more inclined to put together "tiger teams" to solve a short-term problem.

Ben Gunstone: For us [a flat structure] works fine. I think if you were working with bigger teams it may be the wrong solution. A lot of it depends on how your team members like to work and how many people (overall including producers) you have to manage your project. I wonder if there is an algorithm out there to compute that?

Justin D'Onofrio: I prefer a structure where everyone has input, so I like to keep things flatter. For example, as our lead programmer works out some additions to the engine, he needs to call on our 3D modeler to sort out details. This casual knowledge sharing is great to have, and something that I feel isn't as available when you have a more segregated, "pod"-like structure.

Robbie Edwards: I think both have merit and we have used both structures in our projects. We have made the move to the "pod-based" structure in an attempt to streamline communications.

With team sizes growing into the 100-200 person range, it is nearly impossible for one lead to manage 70+ people. The pods allow us to have our leads focus on working with about 10 coordinators and those coordinators managing three to eight people each. I think this structure helps developers stay focused on their responsibilities and provides some level of consistency in the quality of work.

Is there any point in the development process where this structure shows weakness, or have you hit upon a structure that is resistant to stress?

Justin D'Onofrio: The structure that we have is pretty resistant to stress - everyone knows what is going on at any given time, even in areas outside their responsibility, which keeps everybody on the same page (for the most part).

Where stress comes into play is when a problem arises, and there's not enough hard enforcement of the hierarchy - who gets to order whom around.

This can lead to some uncomfortable situations, where you need to step in and say "Yes, great idea, but the situation is that so-and-so has the final word on this, and that's the way it has to be."

Luckily the guys on my team are incredibly talented (hopefully everyone has great folks on their teams!), so even though some ideas need to get vetoed, they at least understand the reasoning behind it - this sort of openness is an advantage of a flatter system, while also being a potential detriment. Juggling both sides and trying to be as diplomatic as possible is the key to making it work.

Ben Gunstone: Our structure shows signs of stress at the busiest periods (as expected really) - when our leads are then required to be responsible for their team, fixing bugs, assigning bugs, making sure the game works, providing regular builds to QA and generally being a catch-all for all aspects of their discipline.

But, then again, I've not worked anywhere where the build up to either a latter milestone or beta to cert periods aren't busy and stressful for all concerned.

Robbie Edwards: I feel the pod structure works very well from a quality of work, efficiency and consistency of work stand point, but it suffers in helping the team fully understand the project vision. Each group is tightly focused on their specific efforts and seeing the big picture is quite a bit more challenging.


Ubisoft Paris' Tom Clancy's Ghost Recon Advanced Warfighter, on which Robbie Edwards worked as producer.

For now, the benefits are greater than the costs, but as the company culture and team dynamic grows and changes, there may be a desire to move back to a flat work structure in the future. I certainly do not believe that there is a perfect structure for everyone, but rather a perfect structure for each project's unique situation and developer dynamic.

Frank Rogan: No structure will be resistant to stress! As always, it's important to find the right people for your leadership roles. It's not always the case where the "best" artist should be promoted to a management position, because the skills required of the best artist (however you define that) are not the same skills required of the lead artist.

One thing I will say is that you should avoid situations where your leads are actually on the production schedule to deliver an equal share of work or assets as everyone else. There will be plenty of problems to solve and things for your leads to worry about above and beyond day-to-day work.

The opinions expressed by these producers are their own and do not necessarily reflect the opinions, plans or positions of the companies where they work.

Read more about:

Features

About the Author

Juuso Hietalahti

Blogger

Juuso Hietalahti is a game producer and the owner of an online multiplayer games company Polycount Productions (http://www.polycountproductions.com). He has co-produced several indie games, published indie game production articles in websites, magazines, books, and is the author of daily game producer resource gameproducer.net (http://www.gameproducer.net).

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like