Diffusion of Responsibility

Feb 29, 2012

When I gave a talk recently, one of the students attending asked afterward what I considered the optimal size for a team of beginning developers.

Specifically he asked, “Is 10 too many?”

My answer was 2-4 per game. Given 10 completely green developers looking to make games, I would advise splitting that group into 3 smaller groups of 3-4, or maybe – just maybe – into 2 “big” teams of 5.

One benefit of keeping the team small is that it’s easier to define clear roles and ownership, to avoid constant confusion over which programmer is implementing which features, which artist is claiming which assets, and so on. Coordinating multiple people to share the same tasks without running into major problems also requires an ability to articulate clearly about the field in a way that is rare among inexperienced developers.

I would set up the roles of each like so:

  • One developer focusing on programming and core gameplay design. Combining these roles greatly accelerates the feedback iterations needed to bring what’s implemented into alignment with what’s intended. Since the programmer is the final filter for what gets hooked up in the game and how, this is often (though not always) the position serving as project lead/producer.
  • One developer overseeing the in-game artwork and visual design. If the game’s art can be done primarily by a single person, there’s less of an issue in trying to get all artists creating content to fit with a single coherent style.
  • If there’s a third and/or fourth developer, they might be either overseeing audio, writing in-game dialog, helping author puzzles, or fulfilling whatever other roles offer the most value given the project’s genre. Without these members, whichever of the other two is most capable in the respective areas can fill in.

    It’s also possible that party members three and four could be an extra artist or content designer. In such cases it’s helpful for each to have a clearly dilineated chunk of the team’s art or design. One artist might be focused on background and menu art, while another ensures all animated sprites and items are accounted for.  With multiple level designers, rather than sharing all levels, it can help to divide up who is overseeing which.

Note my word choices here: “focused on,” “ensures… accounted for,” and “overseeing.” This is not about putting restrictions on people. It’s only about clarifying accountability. Individuals can trade tasks, ask one other for feedback or ideas, get help with aspects that other team members have more experience with, and so on. It’s not mission critical that each person does exactly what they’re accountable for. What matters is that team members see to the timely completion and presentable quality of every aspect in their area, which in some circumstances means handing it off partly or entirely to someone else.

With six or more people, especially if all the people involved are completely new to videogame creation, there’s risk that the project may become administratively intensive, requiring specialization not just in programming, design, art, and audio, but also experienced and dedicated management know-how. Confusion can arise over who is directly responsible for doing what. Feature creep can grow out of control as so many different visions each pull for the game elements that they want to see. Tasks that several people on the team are quite capable of doing may drag out for weeks, partly because each capable member assumes someone else will take care of it, and partly because everyone’s too busy figuratively stepping on one another’s toes by simultaneously taking different approaches to creating the same core assets.

Sometimes having the right word for a concept can be helpful in spotting it, talking about it, and when applicable, mitigating it. The term central to this concern is diffusion of responsibility. Diffusion of responsibility occurs when too many people are all made accountable for the same task(s), without any clarity for which person is ultimately accountable for each.

I’ve found this concept incredibly useful when orchestrating game development teams, both professionally and for hobby projects.

I picked up the concept of diffusion of responsibility from one of my friends in college, in regard to event planning. If we ask a group of 30 well-meaning and perfectly capable students to make sure chairs are set up in the main room tomorrow by 7:00pm, it’s unlikely to happen. Go to one student, instead, ask them if they’ll make sure that it gets done, and it’s much more likely to be accounted for.

The same also applies to, “We need the pickup icons done in time for the demo next week,” or, “The game still crashes every time the rocket launcher is fired.” If there are multiple people that might be responsible for those aspects of the game, these needs are less likely to promptly and decisely wrapped up without additional organizational dialog.

In cases where being vague about who is supposed to do what does manage to work out, it’s often only because someone within that group has the sense to do what the manager didn’t. Someone from within the group has to speak up and play coordinator, making sure that no one leaves that room until it’s clear and decided which individual is going to take ownership over the timely completion of each task.

Nor, to be clear, is diffusion of responsibility a concept only useful for producers. It’s better to err in favor of not falling into the pattern of being just another complicit bystander. If the lead pitches a request to no one in particular, or when it’s clear something is falling through the cracks that may not be claimed by anyone, be that member of the team that keeps everyone around for an extra minute at the end of meeting to confirm who claims accountability for what.

Whether you’re a lead or not, everyone on the project benefits when someone on the team can recognize and overcome diffusion of responsibility. Conversely, everyone on the project risks a great loss from letting untreated diffusion of responsibility serve as an ongoing obstacle to progress. Keep an eye out for it, be brave (though tactful and constructive) about combating it, and you’ll find the projects you’re on more likely to finish well and on-time.



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.