Getting Global
Some real world ways to help
make development teams
truly global
Brett Jackson
Director Game Development
Bally Technologies, India
Jan 2011

This presentation is:
• Production and development centric
• A trigger list not a training manual

Product Development is a global endeavour,
You have two choices:
1. embrace global and continuous improvement
2. fiddle while rome burns

areas of struggle
• it s difficult to create one view
• the issues are not static or clear
• some will lack the skills/experience to
engage with the problem
• tried and true local approaches don t solve the problems
• acknowledging up front the extra cost and effort that
running distributed projects entails - (e.g. 30 to 40%
increase in Project Management efforts)

barriers to overcome
• watch out for tribal or assumed knowledge.
‒ long tenures
‒ arcane rules/regulations
‒ subjective results/goals
‒ IP/Patents
• transparency is uncomfortable/distrusted
• hard won knowledge is not easily
surrendered

common gaps
areas distributed teams encounter
problems or miss opportunities
• Communication • Under-estimation
• Mis-diagnosis and bias • Acceptance of status quo
• Cultural disconnects • Sloganism - a catch
• Skills and tools phrase won t do it by itself

start with people
• become specific in fostering a
global match fitness in staff
• build up CI - Cultural
Intelligence, as a company and
as individuals
• enhance hiring methods to
uncover and hire the globally
adept in all areas of the
business

• explore and encourage pragmatic/innovative tools that
foster and enable collaboration and knowledge sharing
• create a multi level global training curriculum for all
staff - mandatory modules for supervisory and above.
• look at 3rd parties for training resources - stay with
• www.eworldwise.com, www.twmworld.com
people

light up the shadows
• all teams need to:
‒ make meeting times equitable
‒ share the pain and the successes
‒ realise that information does not flow by itself.
‒ vital information must be shared actively.
‒ identify corridor conversations that should be shared
‒ Over communicate and get validation on all key
messages/actions
‒ take the extra effort to find out who owns the issue
at the other end

rethink ways of working
• avoid reliance on a few
massive milestones.
• create regular weekly goals and ensure they are
communicated them to everyone
• create a projectboard that all can see (online and
physical) of this weeks main issues. Update it constantly.
• adopt modern, lightweight, and inexpensive
collaboration tools like Atlassian s Confluence and JIRA
and aggressively drive adoption and usage

try new ways of working
• Teams should trial standup meetings
• daily 10/15 min meetings rather than rely on 2
hour+ review meetings every week or two
• Format:
‒ no one sits down and brevity is encouraged
‒ each person briefly states their goals and
blockers (if any) for today
‒ an owner is assigned to any blockers discovered
‒ team high 5 s any successes
‒ projectboard s are updated

refine ways of working
• single points of truth and ownership
for all issues.
‒ one person for each project/issue.
‒ name and contacts of owner are
communicated to all
‒ publish an online list of projects and current
owners and give someone ownership for
keeping it up to date.

re-engineer your DNA
• overtly define 2nd level team roles in all projects.
‒ Leader ‒ Tech Admin
‒ Scribe ‒ Knowledge Mgr
‒ Facilitator ‒ Domain Experts
• recognise and reward networking activities
• define/actively manage a balance between growth of
islands of competence vs global expertise growth

formalise culture change
create a playbook for meetings and
ensure all have and know it.
• no meetings without a published agenda
• if you can t make a meeting on time let the others know
• friendly timing of meetings for all participants
• remove dead meetings
• time zone tools readily available - meeting planner

phrases to ban
• Avoid the following in speaking
and thinking
• It goes without saying....
• Everybody already knows that.....
• The rest is obvious....

get face to face
• At least one offshore team member
does a 30 day+ attachment with
their HQ counterparts each year.
• All leaders with offshore teams
must visit at least once every 2 years
• bring whole team together for kick
off events/workshops for large
projects

make global the norm
• cultural understanding
presentations for all teams.
Indian culture for US, Chinese
culture for Indian etc
• simple recognition of
significant cultural celebrations
across the organisation -
Thanksgiving, Diwali, Chinese
New Year

re-examine yourself
• Identify your most common Boundary Objects -
‒ Common terms/situations/behaviours which are
viewed differently in different cultures.
• They are close enough to appear the same but different
enough to cause confusion.
• These are common pain points in distributed teams. To
identify, look back on major problems and look for
common threads

know the differences
• sometimes it s how you ask the
question...
• if I ask is xxxx over there? and I point in a
specific direction. then I have expressed a viewpoint
• some cultures will avoid challenging that viewpoint vs.
giving the correct answer to avoid making me look bad
• better to ask where would i find xxxx? with no pointing -
everyone is free to answer with the best response.
• the same is true with business questions
• people don t magically drop cultural habits they learnt in
childhood just because they join a new company

hiring - qualities to look for
• you have to be extra proactive to work
in a distributed company
• you need to hire people in all offices
who are more than just technically
capable, they need be natural
connectors and communicators.
• they need to show proof of staying in
touch with information/trends/prof
groups by their own initiative/drive

hiring - questions
• What is the most interesting
approach/trend you have seen
in the last 12 months? Why?
Where? How did you learn
about this?
• What methods do you use to
stay in touch with technical and
industry advances?
• How do you solve problems
where there is no existing data?

Thanks
Feedback to:
Brett Jackson
brett@mii2.com
Las Vegas
NV, USA