New Post | Subscribe via RSS

Wednesday, March 10, 2010

GDC 2010: Communication scaling – how to keep people talking to each other

View powerpoint presentation: http://www.gdcvault.com/free/category/








This talk was an overview of rapid team growth from a producer's perspective. Gave example of organizing bigger teams over various projects. Used Fear 2 project as the example project. Overnight, it went from a team of 22 to a team of about 60. 
Having middle producers in a large team "can create a bad Chinese whispers-style communication line".
Core rule set for effective communication
·    Know your subject

o   Don’t bullshit
o   Facilitate the people who know the subject to communicate with each other
·      Trust

o   No trust, no listening, break down in communication
o   Build trust by being honest. Even the painful stuff.
o   Be as transparent as possible. News filters very quickly – let people understand how you got from point A to point B.
o   Treating everyone with respect.
o   Follow up – make sure if you task someone to do something, that it’s followed up.
·      Consistency

o   Getting communicators on the same page.
o   Be consistent with communication and be on message.
o   If there are disagreements make sure you come to consensus and then run with that.
o   When there is huge dissent make sure you talk through it and come through to some sort of understanding.
o   Inconsistency is one of the easiest ways to break trust.  
·      Up & Down communication

o   You need people in the trenches moving forward at all times, so you need to make sure they are in the information loop.
o   You need upper management in the loop so they don’t keep messing with you at the last minute.  
- Forgetting to effectively communicate upwards is the #1 issue many producers screw up.-
- A friend described working with upper management as trying to  "Avoid the Eye of Sauran" In other words this guy’s management group wasn’t effectively managing upwards.  
·      Core Rules

Adapt – as a producer you are dealing with lots of different types of people.  For example. People who don’t open emails – if you know he doesn’t have email open you need to find another way to adapt and communicate to the people you have.

·      Being efficient

o   Get to the point as quickly as possible
o   Summarize at the start when presenting or in meetings, move on to the meat later.
- This is important when managing down since you don’t want to waste the time of the doers in your team.
Equally important is communicating upwards, as the amount of data grows hierarchically when moving up the ladder.  Sumarize!
·      Full team involvement

o   Make sure your team know why descisions are being made
o   Include many people in the descision process where possible.
- Doesn’t mean giant meetings.
·      Targets?

o   Identify core communicators in your team.
- These are the conduits for communication to flow up and down.  Use this to your advantage. People who have trust with team.
o   Communication must start and end with the people who are getting the work done. These are the ones you really need to ensure are being communicated with.
·      Classifying Communication

o   Active vs passive (push) communication.
- Active is when the user is pulling data and getting data for themselves.
- Push is when data is getting sent to you (eg. IM, email).  Push becomes noise super fast (eg.email)
·      Types of Communication

o   Face to face
o   Larger meetings
- Ensure they are goal oriented
- Send out agenda first
- Keep them short. Anything over an hour is painful!
- http://tobytripp.github.com/meeting-ticker/
- Must ensure there is FOLLOW UP
o   IM
- All external IM clients are not secure.
- This speaker uses ‘spark’ – internal IM client.


o   Prioritized hit lists
- This project created a bunch of strike teams – figure out what you need to do for that day or week and will post it to the wiki. So everyone at a glance can see what everyone across the department is working on.
o   Game play throughs
- Goal oriented
- Send out agenda first
·      What are we playing?
·      What are we evaluating?
·      What type of feedback is required?
·      keep them as short as possible.
·      Documentation

o   Everything they do is on their Wiki. Great way to communicate to those outside the strike teams.
o   They use ‘CONFLUENCE’ which works well with JIRA
- Forums
- Push notification
- Can embed and edit excel and word documents.
·      Status updates (weekly)

o   It can be really long, but keep simple and break it down. Mostly combine all related updates from teams.
* Executive summary
·      Key personnel
·      Key dates
·      Upcoming dates
* Updates
·      Main things changed from past week                 
* Issues and risks
*  Key Dates
·      Milestones etc.
*  Discipline updates
·      Updates divided by physical groups
* Strike team updates
*  Fully fleshed out risk list
·      Go into much further depth for risks
*  Deliverables


Example of team;  "Fear 2"


-       identify features (audience ambience, weaponry etc)
-       identify strike teams (and each strike team lead)

o   strike teams take full ownership of feature
o   smaller more manageable teams
o   decisions were not bottle necked with a few key individuals
o   not everyone created equal – there was an approval process.
-       Main push

o   4 level strike teams
o   floating content strike team to supported other teams. Acted as consultants.
o   Also acted as ‘contractors’.
o   A good mix of junior and senior folks. Had to be self sufficient and self motivated. One person who knows the technology and also understand how the team works.
o   Approvals process
* Play throughs of level at predetermined intervals or when the team asked him.
* One on ones with principal designers if issues popped up
* Each week a level was singled out for the team to play.
·      There is no stronger motivation than peer disappointment! (peer accountability)
·      Empower people to push their peers into a better place
·      Anything that could be broken down into functional group we broke it down
o   Weapons
o   Characters
o   UI
o   Core Combat etc.
·      Had owners called Strike Team leads
o   Had a face to face each morning with each other to triage bugs and issues across all of the strike teams.
o   Figured out who was finished and what was needed.
·      End Game         
o   Still level based
o   Polish team
o   Performance
o   Memory certification
o   End of game had DAILY PLAY THROUGHS from 4-5

    What did they learn?

·      Empowerment!
o   Give people tools and support they need to make cool shit.
o   Identify core individuals as shit filters and course correctors.
·      Identify and rely on key individuals
o   Trusted by rest of team
o   Small leadership roles
o   “Pony express”
·      Trenches-style camaraderie and ownership = high moral on a project that could have been painful. 

No comments: