Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Delegating to many means delegating to no one

One of my first lessons learnt as a producer. People just don't behave well in shared responsibility situations.

Samuel Rantaeskola, Blogger

October 24, 2012

4 Min Read

I think this is first lesson I took down into the document.

This is definitely not a revolutionary discovery in any way -- that people don't behave well in situation with shared responsibility. There are several examples on the subject, the most known is probably this one, about a murder in New York with 38 witnesses but no one stepping in. This actually formed a term called Genovese Syndrome. The analogy might be a bit drastic, but the root cause is the same: People don't behave well in situations of shared responsibility.

I'm pretty sure I was aware of this phenomena before starting in production. Unfortunately, this also shows another thing that I have known of for quite a while: We are not very good at learning from other people's mistakes. We learn way better by making the mistakes ourselves.

This causes quite a conundrum for me, given the purpose of this blog.

Hopefully, writing about my own mistakes will at least reaffirm the lessons for me.

I can recall the time when I realized this: The game build was failing, and I sent out a mail to all programmers asking if someone could fix the issue. After a few hours with no response, and a build still broken, I walked over to one of the programmers and asked him to take a look. The issue was fixed in less than a minute, and we had a working build again. 

In my experience, the producer role in the game industry has a pretty bad reputation. I think a common failure in delegation could be the root cause for this. Before we dig deeper into this, I need to share my view of the producer role. I see the producer role as the oil the machinery. They are not sitting on top of the team, but rather making sure that the gaps are filled. The machinery must always run without interruptions.

If we look at this from a responsibility perspective, I see the producer as the person that looks at the whole team (or sub-team), finds holes, patches them and hopefully makes sure that they don't appear again long term.

The failed build sitaution, which made me realize that shared responsibility is an issue, was pretty simplistic. So was the solution. I was pretty new to the producer role, and if I recall things correctly I did not fix the root cause. Failed builds probably ended on my table many more times. Had I been a better producer, I would probably have given out the responsibility area to someone in the team, to make sure that failed builds were adressed immediately.

Having the team working smoothly, without interruptions, should always be the main concern of any good producer. However, keeping problems from reoccuring is also an important part of the role. It is very easy, and rewarding, to be the solution to all problems. Unfortunately, they will stack up pretty rapidly, and the producer will become the bottleneck. Succesfully delegating and following up on solutions to discovered problems is one of the most powerful skills producers can possess. Good performance in that area will keep them efficient for an extended period of time.

Quite a few people can do the identification and quick fix part of the producer role, the long-term solutions are more difficult. Being able to succesfully delegate responsibilities to team members is something that comes with experience.

The producer role is generally a transitory position, where people excelling climb pretty fast in the organization. People that have a hard time with it typically can't stand the pressure and find something more rewarding to do. This means that at any given moment we have a lot of green producers in the industry. 

From a team member perspective, failed delegation of responsilbity will lead to unclear ownership. A highly energetic producer can cover the failure in delegation by commiting a lot of personal energy to continuously keep the team moving, but it doesn't scale well. The absence of clear ownership in the team will lead to frustration and slow progress. Succesful delegation will help the team take responsibility and excel.

To sum it up, I see the most crucial role of a producer as identifying important areas where ownership is unclear, making sure that they are delegated, and that responsibility is accepted. Shared responsbility will not be the solution to the problem.

Since my first realization of the problem I've fell into the trap countless number of times, but I think I know this by heart now. As soon as I hear something that sounds like a shared responsibility, alarm bells goes off in my head. 

There are shared responsility sitautions everywhere, at home, at work, in sport teams etc. Typically they are bad and cause frustrution. Applying the short term solution to it would be to constantly point them out, but that would be like putting out brush fires. The long term solution is to let them happen and hope that people learn from their own mistakes.

Lesson learned
Delegating to many means delegating to no one. Don’t delegate a shared responsibility of one single area to several people, most likely no one will take responsibility for it.

Read more about:

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

You May Also Like