Successfully reported this slideshow.
Your SlideShare is downloading. ×

My Team Doesn't Work Here: How to Communicate Effectively with Offsite Teams

My Team Doesn't Work Here: How to Communicate Effectively with Offsite Teams

Download to read offline

If you manage remote workers and offsite teams, here are battle-tested best practices for creating effective documentation, clear assignments, and efficient communication for your outsourced teams.

If you manage remote workers and offsite teams, here are battle-tested best practices for creating effective documentation, clear assignments, and efficient communication for your outsourced teams.

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

My Team Doesn't Work Here: How to Communicate Effectively with Offsite Teams

  1. 1. by Jon Jones, Outsourcing Manager at smArtist jon@gameartproducer.com www.gameartproducer.com My Team Doesn’t Work Here How to Communicate Effectively with Offsite Teams
  2. 2. • 15 years in games, 40 projects • Career focus on outsourcing art • Outsourcing Manager on Just Cause 3 • Content Curator of Unreal Engine Marketplace • Clients and employers: –Epic Games, 2K Games, Sony Online Entertainment, Riot Games, Avalanche Studios, NCsoft, Playdom, The Workshop, Groove Jones, and many others. • Website: www.jonjones.com Who’s Jon Jones?
  3. 3. • Bad communication begets bad results. • If your communication is bad, you can’t expect a good outcome. • Timing is also important. Communication is everything.
  4. 4. • Documentation is your first line of risk mitigation. • Know your pipeline. Know how to explain it. • Every minute spent writing good docs now will save you 10 minutes later. Documentation will save you.
  5. 5. • Sitting with your team is a huge advantage. • People offsite have zero knowledge but what you give them. Never assume anything. • Examples of institutional knowledge: – What we talked about at lunch last Tuesday – That thing that guy said about how the exporter works – Using that neat 3DSMAX plugin you found for UV mapping – Where to download that rigging tools MEL script – Which programmer to ask about how this tool works again • It’s easy to take knowledge like this for granted. • Document it! #1 offsite handicap: No institutional knowledge.
  6. 6. • When writing documentation, always: –Use proper nouns. • NO: hesheitthattherethingplace • YES: BobAlicefile.pdf[full path]etc –Save and include images. –Use specific filenames. –Use specific, full folder locations. –Cite everything, including web links. • All information must create its own context. Always be specific: Documentation.
  7. 7. • Document A must not require documents B, C and D to make sense. • Abolish “that,” “he,” “she,” and “they” from your writing. – If it’s ever unclear who or what that refers to, you failed to communicate. • External teams can’t walk to Ted the programmer’s desk to ask. – YOU walk there, and document what he says. – This removes a physical, location-based dependency. • Write down every quirk and edge case. Specify what to do. – If vertex weight influences less than 10% are stripped on export sometimes, write that down! Don’t make them wonder. • All relevant information should be in one shared location. • If your offsite artists lack information, one of two things happen: a. Production STOPS. b. Artist GUESSES. All information must create its own context.
  8. 8. • When giving assignments and feedback, always: –Describe clearly what is included • Initial materials. (sample assets) • Desired outcome • Step-by-step instructions –Visualize • Include screenshots and descriptions – Describe what is gooddesired in each screenshot – Mention what you DON’T want – Specify what game or property it’s from –Specify • Each contact for potential points of failure – X for design, Y for engineering, Z for production Creating assignments
  9. 9. • Specify –When the changes need to be completed –What changes are required in feedback • Use paintovers. Skitch is great. • Highlight issues clearly. Number them. – Numbered issues are easier to refer to – A sequential numbered list looks like a to-do list » Better chance of getting each point fixed the first time • Describe what’s wrong and what is desired. • Save the feedback and date it. • Keep all feedback in one shared folder. • If you make changes to files, send the changed files. Giving feedback
  10. 10. “Please take the attached model and apply the jungle texture. After it’s applied, rig it with the Large Creature skeleton and export it. See attached image.” • Points of confusion: – “What attached model? I didn’t get an attachment.” – “Which model? I got two.” – “I didn’t get a jungle texture. Is this the jungle texture? Or this one? They both look jungle-y.” – “Where is the Large Creature skeleton? Did I get that?” – “What directory do I export to? Do I make something up?” – “‘See attached image.’ What attached image? I got five. Was that in a different email? Is there a newer image?” Example of bad feedback
  11. 11. “1) Please take the Heavy Orc model (HeavyOrc_final.max) and apply the Heavy Orc Jungle texture (HeavyOrc_Jungle.tga). 2) After the HeavyOrc_Jungle.tga texture is applied to the Heavy Orc model, rig the Heavy Orc model with the Large Creature skeleton (projectpath://Skeletons/LargeCreatureSkeleton_Base.max). 3) Export rigged Heavy Orc model to the Heavy Orc directory (projectpath://Creatures/Large/HeavyOrc/). See the attached image (HeavyOrc_Example.jpg) for reference.” Notice: Each sentence retains its specific meaning, even if removed from context. Example of good feedback
  12. 12. • Orc_Chieftain_Run_Animation_01 – Awesome! Great sense of weight. – CHEST: Some vertices on his chest poke into his body. Can you fix the rig? – FEET: His feet dip below the floor in frames 14-17 and 28-31. Can you bring them up? In other words... • [Asset_Name] – [Brief Praise] – [SPECIFIC LOCATION]: [Brief description of problem. Ask for specific fix?] How to structure feedback:
  13. 13. • Official feedback comes from one communication channel only. – Avoid “was that email or Trello or IM or phone?” • Official feedback comes from one person only. – Avoid “but mom said this” and “but dad said that” • Save feedback to its own shared directory. – Referring to past feedback is helpful. – Sending via email is fine, but also put it here. – Hunting through email and IM wastes time. • ALWAYS specify filenames, path names, and build numbers. • NEVER include links to images. They break. Save and attach. • Doing paintovers in PSDs is smart. – You can easily hideshow layers to highlight subtle tweaks. – These tweaks can even be incorporated directly. Feedback best practices:
  14. 14. Thanks for reading! Jon Jones Outsourcing Manager at smArtist jon@gameartproducer.com www.gameartproducer.com www.linkedin.com/in/jonjones/

×