Accountability in Game Development

Overview

This post will cover a topic that doesn’t directly relate to what goes into the games you are building but is more about how the team builds games. I’m going to touch on the idea of accountability, starting with a general overview of what I like about accountability and why I think it is important and then digging into some specifics with my experiences in the game industry.

An Accountable World

When making a decision I like having reasonable data beforehand. I read reviews on products before I buy them. I talk to people I know who own the product. I visit the company’s website and look at how they engage with consumers. Can I easily contact them? Do they respond?
I like systems that make individuals and companies accessible to me. I like the promise of accountability.
Several things drew me to joining the Empire Avenue team. I knew some of the team members from having worked with them at BioWare. I enjoyed the ‘buy’ mechanic that introduced me to so many interesting people around the world. And I like the implicit accountability system inherent within it.
I reward users by buying shares in them. Because I can read a user’s content streams (their twitter and their blogs and so on) I can make a judgment… is this somebody I support?
Empire is still in its infancy in many ways and accountability is not the reason it exists but I do believe it is a cool side-effect and one I’d like to see developed more in the future. There’s real opportunities for brands and brand supporters and I’m curious where it will go.

An Accountable Team

Why is accountability important to game development?
After having worked years in the game design industry I’ve seen the damage that poorly designed infrastructure, misguided direction, and secrecy can do.

How do we go about instilling accountability?

The Pipeline

The Pipeline is not a clever nickname for a team member. It is what it implies… the data pipeline… from creation to manipulation to insertion into the game world. The path data takes from creation to usability.
At first it might seem hard to associate the pipeline with the concept of accountability discussed above. But a bad pipeline can wreak havoc on the game development process because it hides the mistakes creators make.
A common error I saw was data being mangled. Basically an artist or a designer built something then pushed it to the pipeline and along the way it became garbled. At best this would create a hard-to-catch bug in the game. At worst it might bring the entire build down.
Very often the build was garbled because the creator of the content had made a mistake in its creation.
So how do we make the pipeline accountable? First it should be able to detect that garbled data is going to be generated… trying to limit bad data from entering the pipeline. Secondly it should inform the user of what might have caused the error so that they can efficiently correct it.

Still problems might remain (and it is not always desirable to put too many delays in pushing new resources into the pipeline). Only the creator actually knows an error has occurred at this point. This might not seem like a big deal (after all the user is fixing things, right?) but often individuals try to cover up repeated errors because there’s an assumption that “I’m just doing it wrong.”

But sometimes they are not actually doing anything wrong. The pipeline is at fault and is misrepresenting the problem. The users assume they — not the process — are the problem. And so they try again and again and again… when in reality the actual issue might be a simple one for the pipeline programmer to solve.

This is why I feel it is important to log changes (and especially failures). This log should be accessible by the entire team. This is not about shaming. The primary goal of the list is not for departments or managers to single out an individual who is constantly making mistakes (though we should understand as employees we do have an obligation to reduce failures in our own work, especially failures that affect the entire team). The primary goal is to improve the pipeline.
A dedicated pipeline programmer can look at the logs and see if particular individuals are having problems submitting content. Examining the details they might realize there’s a configuration issue on that user’s machine and its not a user error at all! A frustrated artist might look at the logs and realize that all the artists working with a particular resource are having problems… something the programmer might not have caught. A manager might look at the logs and better realize why delays in her schedule are happening.

Visibility is important. Let the entire team work to fix problems with the pipeline.

Decisions

A similar process should be used with decision making. There should be a list of major decisions (especially when previous decisions and direction have been reversed). These turning points should be identified on the schedule. The people agreeing to the decision should be listed.
The entire team, if not the entire company, should have easy access to this information.
Yes, it creates headaches and invites arguments… individuals will feel compelled to point out what they consider to be flaws with the design. But at the end of the day a team that has ownership over a product will work longer and harder than a team that is kept in the dark and working on a product they do not care about.
And occasionally real solutions that were never thought of by the decision makers might emerge from the rest of the team. I’ve seen it happen.
The only reason a management team would hide their decision making process is if they are not confident in the decisions they are making.

The Individual

As a team member you can help push for accountability by always being accountable yourself. Make it clear through whatever means your team is using what you are working on and the delays you are experiencing. If you need help to meet your deadlines, explore options. If there’s a particular aspect of the pipeline or your work environment that is delaying you don’t suffer it in silence. Talk about it… whether with peers or management.

Problems don’t fix themselves. I’ve seen many hard working developers banging their head against pipeline problems that were resolvable but they had learned just to deal with it. Don’t accept that kind of attitude in your team environment!

That’s it

Accountability needs to be built into the core of the company, and the teams, that make games. With it, I believe, that game development can become a less expensive and more satisfying experience, just as I believe the consumer-brand relationship can become more satisfying. Just as shoppers should know what they are getting into when they give their money to a brand, employees should understand the company that they are giving their time to.

Yes, I realize there’s always a lack of manpower and a lack of money but adding accountability — presenting more data about how the team works to the entire team — is not expensive. More often than not with a little bit of extra light shone on the work they are doing the team will figure out and solve most of their own problems without incurring a great deal of additional overhead.

So what about your own experiences? Any successes with accountability? Any failures? I often hear people (especially high level managers) express concern over revealing too much to ‘the team’ but haven’t really heard about actual situations where this caused damage.