Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
March 19, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

A Team-Oriented Approval Process

by Timothy Ryan on 12/10/18 09:43:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Games express the creative will of the team.

How well the team works out creative differences is discernible in the end product.  Quality suffers when the team cannot balance the input of many personalities. This can be tackled with a team-oriented approval and review process.

Creative Direction

Video game team culture is never a democracy. There is normally a hierarchy on a team with people directing work. I like to tell people that there’s three kinds of creative direction on a team:

  • No direction - soft gloved, disjointed, people do what they want

  • Bad direction - poorly expressed, unimaginative, meandering or lacking conviction

  • Good direction - expressed well, cohesive, analytical

At one studio I worked, we cycled between none and bad as we looked to hire experienced directors. One of those new directors was very good, but one turned out be a wolf in sheep's clothing and showed me a new level of bad. I'll dub it authoritarian direction.

Under Authoritarian Rule

An authoritarian director makes all the creative decisions and approvals. They believe they know best and do not trust their team. They never abdicate quality control to leads or individual team members. They tend to micromanage their direct reports and have flat teams where no one can intervene in their messaging.

Authoritarian directors can have great success. True geniuses can produce great works, they are just not pleasant people to work with, and they are not always the geniuses you hope they are, for the company's sake.

Authoritarian direction adds significant risk to the design and product. Flaws in the director's thinking go unreported or unchallenged. They can sometimes ignore, twist or fail to incorporate consumer data points or others advice, doing what they want, not what careful analysis dictates. They prefer to surround themselves with capitulating direct reports rather than thoughtful and potentially contrary leads who might stand up for themselves. Thus they fall prey to the peril of groupthink

Team members in such scenarios stop thinking for themselves. This suppresses their enthusiasm and contribution of ideas and strips away any sense of ownership and accountability, except when it is convenient for the director to lay blame. Because they cannot think for themselves, team members cannot solve their own problems. Decisions slow down to the availability of the director, where a week or two away from the office means possible slips to the schedule.

Breaking from Authoritarian Rule

I'm not one to shy away from a fight when there's something amiss in my studio. I am always looking to improve processes with the end goal of quality, timely releases and team contentment. To combat this growing authoritarian in our ranks, I preached inclusion and empowerment of individual contributors and leads.

Then as EP and manager of hand-off process and embedded testing, I put my money where my mouth was and instituted an approval process that pushed quality checks down to the leads. I couldn't force the authoritarian to give up his reigns on design direction, but I could promote a team-oriented approach to quality control as part of the embedded testing process for hand-offs to formal testing. 

In a team-oriented approval process, sign-offs are not about control. When distributed to the leads on your team and taking input from team members during regular reviews, they are about empowerment. They are about sharing responsibility for quality.

Recipe for a Good Team-based Approval System

For each release, milestone submission, or each game feature or level you can insert an approval step as a quality check. A good approval system should do the following:

  • Seek sign-offs from each discipline lead and director. This can be design, art, sound, engineering, math, product management, the game director and QA.

  • Make their approvals visible on a dashboard. I first tried getting sign-offs with a contract-like document, but that didn't work as well as a white board mounted on the wall. Clarity creates goals. Goals motivate team members. Later I moved it to big screen monitor on the wall.

  • Open up the review process to more team members. Inclusion breeds loyalty and gets better feedback. This doesn't mean it's a democracy unless you choose to call for vote. It just means you gather more data to make a decision and provide opportunity for criticism or alternate ideas.

  • Track decisions and feedback on a visible checklist in Confluence or team-shared document. Personally I found it easier to keep polish lists out of JIRA or the bug database as it can often be a pretty long list of tiny changes.

  • Test new ideas and give others’ ideas a fair shake. Honest discussion fine-tunes thinking. This eliminates groupthink. Giving people a little leeway to experiment may clear up any disagreement.

  • Share consumer data points from your metrics, customer service, sales and focus tests with the team. This helps the team understand what is being asked and why, providing context for decisions and opportunity for them to suggest solutions.

  • Foster a safe environment to critique each other’s work. Team members should feel safe to both share and receive criticism of their work without fear of reprisal. Remind people it's a team effort and making the game better is the top concern. 

  • Think out loud and share your reasoning with the team. This provides context for your opinions and also allows it too to be criticized. When you think out loud, people will also learn to anticipate your feedback and speed up future efforts with less iteration. 

  • Acknowledge mistakes.  Humility is a very important trait for growth. Every failure presents us with an opportunity to learn.

  • Acknowledge ideas contributed by junior team members.  They don't often get the credit they deserve, and calling out their good work in a team setting is a great way to encourage those ideas to keep flowing.

  • Allow approvers of different disciplines to cross their lanes. If the engineering manager sees some hitches in animations and wants to hold off his sign-off, let him. It might mean bad compression or bad art. You don't know until you dig into it. It's safer to make no assumptions and catch all mistakes whatever discipline is involved.

A Recipe for Disaster

An approval system if implemented wrong can also be a recipe for disaster. Here's a list of DON'TS I can pass on from lessons learned at this and past companies.

  • DON’T allow new content approvers into the end of the development cycle.  It is completely unfair to the team if someone can send you back to concept never looked at the game until the end.
  • DON'T ignore customer feedback and metrics. If you design in a box, you are not being true to your mission. You are not the target demographic of your game, as hard as you may try to be, so instead try to understand them.
  • DON’T repeat random feedback as gospel. Be more analytical. Have conviction. Focus groups find consensus by removing outlier opinions and eliminating participants who are not the target demographic. Even if it's your boss, you owe it to your team to weigh the impact of responding to that feedback.
  • DON’T critique the person, critique the work. Everyone takes criticism a bit personally, so get everyone try to deliver feedback dispassionately in terms of the work, not the effort or person behind it. Otherwise people will hesitate to share their work until it is perfect, potentially wasting significant time as they might have to redo it anyway.
  • DON’T let approvers disappear without a backup plan.  A critical path MUST make allowances by working out a solution to their absence, either working remotely or designating someone to approve in their place. 
  • DON’T try pleasing everyone. Design by committee never works. It’s slow and kills passion. I liken it to sandpaper, erasing all the edgier cool ideas along with the bad ones until you're left with a much delayed product that doesn't offend anyone but also  doesn't excite them either. The same can happen with a content approval committee.
  • DON’T abdicate all approval and quality checks to your testers. They don’t see what you see. They don't always care about what you care about. They are not trained animators, game designers or sound engineers, so they may not know what to look for.
  • DON’T let approvers hold a project hostage without informing them of the impact. Negotiate. Manage up, or sideways if you have to. Even if it's your boss or one of the directors, they too are responsible for the ship date and you should at least inform them of the impact of significant changes. Sometimes a commitment to quality means biting that bullet, but sometimes a compromise can be worked out with a faster solution.
  • DON’T confuse approval with personal power.  It's about leadership. Leadership is helping your team be successful with their work. As a leader you don’t confuse someone debating a point with you as a slight on your authority. It’s NOT about WHO is right, but WHAT is right for the game.

Conclusion

A single point of approval is a single point of failure. Games are too complex to afford that risk. Good direction must incorporate team and consumer feedback and ideas. Present the team with a sign-off board and team review process and they will rise to the occasion, finding more issues and finer polish than with a single approver or no sign-offs. That finer polish and the team-oriented approach to content approval is how we transform good games to great ones.


Related Jobs

Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic
[03.19.19]

Producer/Agile Leader
Skybox Labs
Skybox Labs — Vancouver, British Columbia, Canada
[03.18.19]

Software Engineer
Wargaming.net
Wargaming.net — Baltimore, Maryland, United States
[03.18.19]

Server Engineer
LeFort Talent Group
LeFort Talent Group — Toronto, Ontario, Canada
[03.17.19]

UE 4 Lead Developer





Loading Comments

loader image