Building Global Development Team

  • Article

Nowadays software is getting so complex that it needs incredibly more and more people to build it. For example, there are 9000 engineers working on Vista simultaneously. In certain sense, you can call that it is a labor-intensive industry. Ideally, it would be best to put all people in one place; however there are also lots of sound reasons to build global development teams.

Pros and Cons

Why bother to build global development team?

  • New talents pool – Software development needs so many persons with similar attributes. In Microsoft Company wide, top 3 hiring criteria are smart, passion for technology and fit to company values such as openness, continual self-improvement and mutual respect, etc. From various studies, supply of talented IT staffers isn't keeping up with demand. And it won't change anytime soon. Even when Microsoft is cutting 5000 jobs now, we still have another 2000~3000 job openings there. What to do if enough qualified hires can be not found within US? Go outside.
  • Lower cost – let us straightly go to data. Annual pay for Level "59" is about $74,000 in US, while same level is paid about $20,000(~RMB150K equally) in China. Another slight fact - It costs about $1.5 to go most common places in Shanghai…
  • Close to market – Most innovative ideas often comes out of interactions with customers. And customers' requirements vary from country to country. So best way to serve a local market is to be in the market.
  • Specific knowledge – Cross-nation acquisition for specific technologies is another reason to build global development. You can't(or not able to) move all folks to HQ.

 

Like many other things, challenges always go with benefits hand in hand. You can't take only part of it. Fair enough.

  1. Distance – People who work on the same software can't work alone, they have to exchange information and make decisions. Less than 3 minutes conversation is often enough for slight but frequently arising communication needs, for example, "Could you show me the bug in your environment?" Distance makes it impossible to stop by one's office. Network bandwidth is another issue introduced by distance. Why it matters? Suppose one team has to copy large file sets from another remote team daily, it would be a problem. The file sets can be growing amazingly big – for example, daily SQL Server build is about 300GB.
  2. Time zone – Would communication a real headache since modern technologies such as email and telephone have been there for quite a long time? But the things are no one is there when you are working due to time zone. You have to wait another day to get an email response. When you rush to office to check it, the most frustrating but concise reply could be - "What do you mean by <insert anything you assume others should understand>? How can I help you?"
  3. Culture/Language – Master level of English is unbalanced in global teams. There are dozens of ways to say "A beats B" in English, but only several of them are understandable for general public; dialect is another obstacle. For example, Chinese folks often have hard time pronouncing letter "L", as a result, words like "girl" might sound weird sometimes.
  4. Junior team – In my organization, most hires right come out of college. We are raw smart, but less experienced. It is hard to deny that some key ingredients for great engineers just take time – design skills, debugging techniques, influencing capabilities. This is not a cutting-corner example.
  5. Conflicts between hierarchical management and local branding – By organization hierarchy definition, many business units have existence in China. STB, Live, Online Service, etc. They functions nearly independently of each other and reports to US. But from the perspective of customers/partners/talents, it looks a bit confusing because there are so many Microsoft's. 
  6. People development – folks in remote sites are not equally exposed to development resources such as face-to-face training, library, mentors, etc.
  7. Governing issue – due to well known concerns, something confidential can't be moved out of US.

How-to

There are several factors playing critical role in deciding appropriate distributed development model. At least you should consider project type, team seniority, team size, team culture, communication cost and history.

  • Build trust first. No matter how adaptable a new team is, it always takes time to fit into a specific team culture. So starting with easy jobs to build team moral and credibility is the safest steps before moving forward. Beyond this, the new team can target increased ownership.
  • Decide on team coupling level. From highest to lowest, the level could be: pseudo random assignment, same branch same feature/component, same branch different feature/component, different sub branch but same main branch, different main branch & clearly defined data contract. Avoid circular dependency.
  • Come up with communication plan. Minimized communication is not always the best, especially for relatively junior teams. The best way to develop people is to work with senior folks on daily basis as much as possible. So you have to make tradeoffs here based on various inputs.
  • Shared lab if possible. If you have to copy large files across the ocean frequently, consider doing your job on a lab down in remote team. If you have to do copying, make sure the files meet most critical quality requirements before doing so, for example, a build verification test.
  • People development plan. Regular staff exchanging plan such as Marco Polo and Silk Road program, getting a mentor, record trainings, etc.
  • Local brand management. Externally shown as one image; internally run by functionality as usual.