The document discusses solutions for managing globally distributed mobile teams. It describes problems with communication across time zones and languages. Key solutions discussed include hiring communicative team members, flexible work schedules, using squads, GitHub for collaboration and documentation, RFC processes, 1-2-3 feedback systems, automation with tools like Fastlane, and architectural patterns like Clean Architecture. The document is from a technical product manager at Cookpad describing their global iOS project.
3. Introduction
● Pawel Rusin (twitter: @rusinpaw github: pauchan)
● Double majored in Robotics and Japanese studies in
Cracow, Poland
● Came to Japan in February 2013
● Bounced between iOS and Android projects
● Ads department till Sept 2016
● Global iOS team since - team iOS
● Recently became technical product manager on Data
Analysis squad
4. Cookpad global iOS app highlights
● Existing project (started
as 100% Objective-C)
● Converted to Swift in
February 2015
● Supports 14 different
languages
● released in 148 countries
7. Communication problems
● Physical disconnection
● Timezone differences
● Language barrier - 7 different countries (4 non-native
English speakers)
● Structural boundries - while the same iOS team,
different supervisors and different responsibilities
8. Communication
● “It was a comunication problem”
● “I had no idea about this”
● “There was a language barrier”
● “I have no idea what you are talking about”
● “You should have told me earlier”
● “I don’t know who to ask”
● “I’ve misunderstood you”
10. 1. Hiring
● “Hire good people and rest will follow”
● Right fit for the job
● good communicators
○ OSS community
○ strong peer review cultures
● structured interview
11. 2. Flex / remote
● No 9 - 5
● Resolving timezone problem by adjusting your work
schedule
16. 4. GitHub as the main source of
communication
● PR based workflow
○ PR’s and issues are basic place for tech discussion
○ PR’s are specs
● Code review as a way of knowledge sharing
● Github for onboarding / docs
17. 4. GitHub as the main source of
communication
● [1/4] - Very light suggestion - "You don't have to change this. I'm just
mentioning it."
● [2/4] - Light suggestion - "Please consider changing this, especially if
someone else feels similarly."
● [3/4] - Suggestion - "Please change this, or provide some additional
reasoning behind the decision not to. However, if you feel strongly about it
and we can't come to an agreement, I'm still okay with it being merged as
is."
● [4/4] - Serious suggestion - "Please change this. I feel very very strongly
about it. I will not approve this PR until we have come to a compromise."