Playing the Game Long-distance
- Language - a minority of the Chinese members of the team spoke English, and even fewer spoke well enough to communicate effectively.
- Culture - the products we developed were used by city and county agencies in the US for licensing and permitting. They were designed to support processes that are commonly used and understood by US citizens. The business domain supported by our software was unknown to the Chinese team members. They had no first-hand knowledge of the business use cases we supported.
- Technological Maturity - while I'm sure there are many skilled Chinese software developers, our partner's philosophy was to run a development team along the lines of the manufacturing model used by Chinese companies that hire relatiely inexpensive labor to perform mundane, routine manual tasks that require very little creativity or skill. That philosophy translated into code that was not well designed, not extensible, and not very durable. The partner company did little to attract higher skilled talent or to retain the higher skilled members of the team. A related issue was the lack of reliable internet connectivity and poor phone quality, both from the offices and homes of the workers.
- Geography - the time difference between our engineering office in the US Mountain Time Zone and the Chinese partner offices in Shenzhen was 15 hours. This meant their workday began at approximately 5:00 p.m. MST. Our customers and other departments all worked US hours, which meant we were required to be available during those hours, but to communicate in a synchronous way with our offshore partner (by phone or IM rather than e-mail) required that we continue working into the Chinese workday. This is not a sustainable model. In addition, to ensure the best possible outcomes members of both teams frequently travelled to the other team's office. The cost of international travel and lodging for extended periods counts against the cost benefit of an offshore partner.