The Lazy Designer

Accountability in Game Development


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.


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.

Former lead designer at BioWare (Dragon Age: Origins, Neverwinter Nights). Creator of Raiders of the Serpent Sea.


  • Robert

    Hi Brent,

    Great to see you writing a bit about game design! Thanks for an excellent read.

    ‘Accountability’ – a topic I couldn’t resist chiming in on! Workplace secrecy and a ‘personality cult’ with respect to leaders is my pet hate. A team that works in the dark, with no sense of investment, will not produce inspired work. But at the other end of the spectrum, total democratization of the work process, coupled with complete transparency is also potentially wasteful.

    I find democratization works very well with a smaller team of near equals, or people that you know well. But in a larger organization, I feel it can be hard to implement ‘glasnost’ in a ‘purer’ form similar to what you describe, simply because of diversity in human nature.

    You mention that “the only reason a management team would hide their decision making
    process is if they are not confident in the decisions they are making.”

    Full information unfortunately all too often doubles up as political ammo… In a large organization, you have to be careful about providing people with ammo to fight their personal political interests in the middle of a project, ie, expect them to be mature enough to use information for self improvement and team goals (as opposed to political infighting). In my view, employee X should have very limited access to employee Y’s job performance metrics (/ list of failures) or remuneration (/ project cost). The cost (risk of divisive politics) outweighs the benefit (increased productivity through being invested).

    And the same further up the hierarchy. Wolf packs have one big big fight to determine the Alpha, and then the ‘lesser’ members all fall into line for a ‘longer’ period. Full transparency can encourage the human version of the ‘Alpha-fight’ to effectively last indefinitely. Which leadership rival could you trust to not capitalize on a minor slip up of yours (we are all human) when armed with perfect facts? Systemic openness is in my experience too often interpreted as an enticement to constantly challenge the leader (productively or for selfish reasons). Wolves have determined this to be a waste of energy and not in keeping with the collective interest. I tend to agree.

    The crux of the issue to my mind is that the management team is accountable to the shareholders, their staff and the customers. The managers have to juggle these three (sometimes conflicting) interests (not to mention their own personal agendas). There are obviously cases when you have to act against the interest of staff and in favor of the shareholders.  It is unfair to expect say, a fresh joiner, to understand- let alone support- a manager in a pro-shareholder, anti-employee act (eg demote a popular but unproductive staffer). In fact, openly announcing such a move and its implementation plan will most likely be met with resistance and enmity, and so secrecy flourishes.

    I think much of what I write comes from working in organizations with strict organizational charts, clear chains of command and rigid hierarchies. The accountability is crystal clear – to you immediate boss, who has tons of metrics on you and your peers which are ‘sprung’ on you. However from our last conversation I understood that BW projects are a collaborative effort, and the directors are decent guys with solid integrity. This would indeed change the whole accountability picture.

  • Brent Knowles

    Wow, great response Robert. Definitely some interesting counter points for me to consider. You are correct that I am thinking about transparency purely from my experience with BioWare and specifically in regards (mostly) to game features and ‘vision’… not necessarily the behind-the-scenes stuff like finances and job performance.

    Sorry for the huge delay in responding… I’ve been on vacation and posting a little but haven’t had time to go through your comment until now.
    I’ll take another look at it once I’m caught up on other tasks and perhaps do a follow up post with some more thoughts.

    Thanks again!

  • Ted Chen

    Interesting idea of logging the data, although people being people, I think Robert is right in how that would pan out with a public list (or something even referenced to the people being collected on).┬á Also, the micro second it gets turned into a reward or punishment metric, it will start getting gamed.┬á It doesn’t need to be any material punishment, but the simple fact that you may get called out during a meeting would be enough to alter people’s behavior.

    I think the problem with the pipeline could be solved by simply introducing a support programmer that has the responsibility, ability, and authorization, to make changes to the pipeline.  Frustrated artists should feel comfortable with this person to vent and bring to attention problems they might be having with the pipeline.  Something keeps crashing the exporter?  Why do I have to redo this work everytime someone else up the pipe makes a change?  Can I have a make-pretty button? 

    In a way, they become the informal gripe log.┬á They archive and process feedback in real time, much more semantically than any automated log collection mechanism I’ve ever encountered.

    Sometimes it pays to get people out of their seats.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.