[This is the third of three articles based on a talk I gave at Game Connect Asia Pacific 2011 titled Working with Humans. Part one explores successful company cultures; part two gets into the science behind our social programming and in this installment we’ll go through tools to improve an established studio’s culture of communication.]
We’re good at not talking.
In fact most of us have been creatively not talking our entire lives, from grade school to profession!
We’ve become so good at not talking that we can have conversations without actually saying anything at all.
You run into your project lead every morning in the staff kitchen at breakfast, chat about the last Battlefield game or the amazing new ABC show, and somehow never get around to mentioning the unrealistic milestone schedule that keeps you up at night.
You have weekly Skype meetings with your tool development team in Vancouver, they assure you the procedural environment UI is testing beautifully, then a year into production you find out that the artists can’t use it and have to build assets from scratch.
How to Communicate Without Talking
Dutifully train kids in what not to say and they’ll be fully prepared to communicate without talking as adults!
Don’t say things people won’t want to hear. If you can’t say anything nice, don’t say anything at all. Speaking up when we could be wrong or hurt someone’s feelings is paramount to social suicide.
Is it any wonder then why so many of us keep silent or get defensive when a difficult issue comes up?
Talking doesn’t happen when people are afraid of the outcome.
So most folks choose to cope and say nothing at all. But they won’t work as hard. They won’t report problems.
And eventually the project folds under the weight of everything that’s gone unsaid.
In a previous article we looked at the science behind these responses. The faster, instinctual limbic brain switches on more quickly than the slower more logical neocortex; and when limbic brain takes over we lose our rationality, our ability to communicate.
We retreat into silence or lash out to defend ourselves.
So how do we change our default programming from primitive Lizard Brain to the a more philosophical Modern Man?
Tools for Talking
This is a process, a ritual that gives the operating system in our brain time to boot the more recent rational neocortex instead of the default instinctual limbic system.
Tool 1: Write If / When Statements
Determine Priority and Implications. When faced with crucial issue we to tend to respond only to the most recent breakdown in communication. This often leaves the real issue unresolved, continually damaging the working relationship.
- Decide if this is a real issue. Are you really angry because the tool doesn’t work? Or is the real issue the fact that the tool development team was dishonest about their progress?
- When did it become a real issue. When did the relationship start to break down? What events proceeded the breakdown? What issues has it contributed to?
- If you DON’T talk about the issue, what will happen? How will the project be affected if the issue isn’t resolved? How will you be affected?
Example: As much as you may be annoyed that you thought tools were tested when they weren’t, you decide the real issue is the fact that a year of production has been lost and the art department won’t meet the deadline if a solution isn’t found.
Tool 2: Clean Up Hacked Code
Separate Facts from Stories. We look for patterns and tell ourselves stories to understand the actions of others – we’re rapidly prototyping our social responses and this makes it possible for us to react quickly. Unfortunately we’re TOO good at this; we end up acting on stories built entirely from hacked together assumptions.
- Identify the facts, what you actually know. You know the artists aren’t using the procedural content tools.
- Stop telling yourself stories. You DON’T actually know that the Vancouver team lied and delivered shoddy product.
- Get curious about their actions. Why would an otherwise reasonable and decent person act that way? Why would you?
- Get curious about your involvement. We’re good at convincing ourselves of our innocence. How could you have contributed to the issue?
Example: You have a long chat with the art team about why they haven’t been using the procedural content tools. Apparently documentation on how to use the tools didn’t come through until much later in production. They’ve always created their own level kits, so rather than delay they decided to start work developing assets.
Tool 3: Develop a Core Framework
Create a Safe Atmosphere. People won’t talk, openly and honestly, if they feel disrespected or at cross purposes. For good communication to occur at all everyone needs to feel like their goals are valid and their input is truly valuable.
- Set yourself up for clean communication, find a time and a place where you can talk without feeling rushed or distracted. Don’t ambush them in the hallway! schedule a time that works for everyone.
- Help them get to where you are. Do they see this as a real issue? What are they afraid will happen if it goes unresolved? Share your facts, ask them to share theirs.
- Make sure the core mechanics are there – Find mutual purpose. What are your motivations for this project? For yourself? Be upfront and honest. What are their motivations for the project and for themselves?
Example: You call ahead and schedule a Skype meeting with the Vancouver team after their next deadline. You want the freedom to talk without anyone feeling pressured by other commitments. During the conversation you share your concerns for the project and your desire to find a solution that allows you to keep working together (mutual purpose). You share the facts you know and ask them to share theirs, getting all the information on the table. It turns out that the documentation did go through as planned, but the email had bounced. When they didn’t hear anything back from the art team they assumed everything was going well.
Tool 4: Scrum as a Team
Define the gap. Describe the different between where you want to be and where you are now, and identify steps to close that gap. Actively maintain mutual respect and mutual purpose. If at any point you feel like the conversation is getting heated and someone is retreating into silence or starting to get defense, go back to Tool 3.
- Add features only if they improve the experience – Propose solutions that take into account mutual motivations
- Cut features if they don’t – take any suggestions that don’t lead to achieving mutual purpose off the table
- Determine win conditions – how will you know when the issue has been resolved?
- Assign Roles – Who is responsible for what?
- Identify barriers – Make this easy. Address any obstacles are making it difficult for people to do the work they need to do.
Example: The reason for developing procedural content tools in the first place was to quickly generate a variety of levels within a very short amount of time. That wasn’t able to happen earlier in production, but as the artists have produced assets for level kits already you should be able to roll it out now. To help the artists get comfortable using the tools the Vancouver team has offered to come out and work with them for the first two weeks to get them started. In addition to this you’ll be hiring a project manager to create documentation for the art team and oversee cross department projects in the future.
Tool 5: Data Driven Development
Test Your Solutions, Get Feedback. Choose a time limit to test the solutions you generated as a team. Come together frequently to analyse the results and adjust your approach as needed.
- Define the rules of playtesting – how long do you try the proposed solution for, when will you follow up to discuss results?
- Iteration – repeat this process until the issue is resolved and the experience improves.
Example: Every week your project manager Skypes between the art team and the tool developers in Vancouver, keeping them up to date with how the tool is used by artists. This process continues for two months, after which the teams meet up to discuss their progress so far. If the art team is working faster and enjoying the tools then the exercise was a success. If that’s not the case then the teams will go back through steps outlined above and test a new solution.
Changing the way we communicate means changing our default responses to difficult situations. And the wonderful thing about the human brain is that it is endlessly changeable!
The Tools above are just one way to patch social programming. Try them, test them and create your own.