My Team Doesn't Work Here: How to Communicative Effectively with Offsite Teams
by Jon Jones, Outsourcing Manager at smArtist
My Team Doesn’t Work Here
How to Communicate Effectively with Offsite Teams
• 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?
• Bad communication begets bad results.
• If your communication is bad, you can’t expect
a good outcome.
• Timing is also important.
Communication is everything.
• Documentation is your first line of risk
• 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.
• 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
• 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.
• Document A must not require documents B, C and D to make
• Abolish “that,” “he,” “she,” and “they” from your writing.
– If it’s ever unclear who or what that refers to, you failed to
• 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
• 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.
• When giving assignments and feedback, always:
–Describe clearly what is included
• Initial materials. (sample assets)
• Desired outcome
• Step-by-step instructions
• 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
• Each contact for potential points of failure
– X for design, Y for engineering, Z for production
–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
“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
• 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
“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
3) Export rigged Heavy Orc model to the Heavy Orc directory
See the attached image (HeavyOrc_Example.jpg) for reference.”
Notice: Each sentence retains its specific meaning, even if removed
Example of good feedback
• Orc_Chieftain_Run_Animation_01 – Awesome! Great sense of
– 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:
• 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:
Thanks for reading!
Outsourcing Manager at smArtist