Working with distributed and overseas teams is a fact of life these days in technical environments especially and knowing some basic tips will utilize the talents of the entire team more effectively.
Time zone differences can accumulate to mean real schedule slippage so you have to try to use the time zone difference to your advantage. For example, if the shift in India starts 10 hours ahead of east coast time consider working in the evening for an hour or two to prep work plans for the next day. When you arrive in the east coast morning, the team in India will have had several hours to work on tasks that you'd agreed to. If you wait until the morning you may miss an entire day of productivity in India.
This time zone issue even comes into play with east coast / west coast teams. If your west coast team gets a late start they are going to push the east coast team to have meetings at the end of the day. Not always practical. And having the west coast team get up early constantly is often not workable, especially with tech workers who seem more prone to night work than morning work in my experience.
Asynchronous communication like email helps of course, but still, email that is not responded to for many hours requires more time to come back up to speed. If you are both online working and can respond within 30 minutes or so the thoughts behind the email will still be quick to draw on.
Verbal communication can be challenging with language barrier and accents so I find that technical conversations and involved explanations are best handled with email. Having a call several times a week is important though to establish an emotional connection with the overseas team.
Make sure you respond to questions from the overseas team promptly. Just deciding that they'll figure it out is a recipe for rework and lowers morale. I also like to solicit feedback and suggestions as there are some incredibly talented people working in India and elsewhere and as a team we need to tap the talent of all members as much as possible.
Importance of an Issue Tracking System
Having issue numbers to refer to as a shared language (interesting comparison to mathematics as a universal language) is very helpful. It takes time to establish a procedure with the team to make sure everyone is being diligent about using the issue tracking system, but it really pays off in adding shared organization around the work tasks.
It's very handy to be able to pull Excel extracts from the issue tracking system to build ad hoc reports. And investing in some Excel macro development to create regular reports instead of developing full online reports (at greater expense) can be a reasonable way to go, especially if the product manager or another in-house team member writes Excel macros. Reports can be adjusted quickly for reporting to senior management.
Although QA should definitely be part of the overseas team's process, you need to have either in-house QA or QA provided by another vendor. I would argue for at least some minimum QA by in-house personnel who can also double as support because they know the product. Even if the overseas team produces perfect work, there are going to be misunderstandings around requirements and an in-house QA team will be more likely to pick those up. The in-house Product Manager also has to participate in QA.
It's really essential to have localized management that's responsive. It's just not practical or fair to manage an overseas team of a dozen or more at an individual level. There are going to be personal issues as with any team and not being present physically makes it impractical to know what is going on. Having a good relationship with the management onsite with the overseas team is important. Invest in it.
The overseas team needs to provide good time records and they need to be tied back to the issue tracking system so you can monitor and defend the costs associated with various development, QA, and support issues. It will take a few (monthly usually) cycles to establish a good routine.
On software teams and with the rise of Agile in particular, managing teams with Theory X is not effective so the skilled manager of an overseas team (any team really) needs to find a way to encourage the team to produce great results using a Theory Y philosophy.