Leading an offshore team

Question

I'm in a position where I am leading two teams of 4. Both teams are located in India. I am on the west coast of the U.S.

I'm finding leading remote teams challenging: First, their command of the English language is weak. Second, I'm having difficultly understanding them through their accents. Third is timing, we are 12 hours apart.

We use Skype to communicate.

I have a month to get the project done. We've burned through a week just setting up the environments.

At this point I'm considering working their hours, 11p PDT to 7a PDT, to get them up to speed, so that I can get the project off the ground. A 12 hour lag time is too much.

I'm looking for steps I can take to be successful at leading an offshore team.

Update

The offshore team's primary task is coding, of course, most coding tasks do involve some design work.

The offshore team's are composed of one lead, 2 mid level (4 to 5 years) developers and a junior (~2 years) developer.

The project is classic waterfall. We've handed the offshore team a business and a technical design document. We are trying to manage the offshore in an agile way. We have daily conference calls with them and I'm requiring the teams to send me a daily scrum in the form of an email answering the following questions:

1. What did I do today?
2. What am I going to do tomorrow?
3. What do I need from Chuck so I can do my job tomorrow?

There is some ambiguity in the tasks. The intent was to give them enough direction for them to develop the task with out writing the code for them.

I don't have a travel budget.

I am using Fogbugz to track the tasks. Each task has been entered into Fogbugz and given a priority. Each team member has access to FogBugz and can choose what task they wish to complete.

Related question: What can we do to improve the way outsourcing/offshoring works?

Update 2

I've decided that I can not talk to the team once a day. I must work with them. Starting tonight I've started working the same hours they are. This makes me available to them when they have questions. It also allows me to gain their trust and respect.

Answer 1

More questions than answers, I'm afraid

• What is the task you need to accomplish? Requirements, design, coding, testing?

• What are the roles of the two teams and the individuals within them?

• What's your development process? (waterfall, Agile/Scrum etc)?

• is what needs to be done well understood, or is there ambiguity or research required?

• do you have a travel budget? Can you or (some of) them hop on a plane for a visit?

• how is their written English? (in my experience, Indian English and US English are different, so it may not just be command of English, but the differences matter less in written English)

The approach will depend on the answers, but my generic advice would including using IM as well as phone calls (a group conference where someone gives a running written summary of discussions as they are happening has worked well for me), and using Scrum's user stories and task boards to quickly capture requirements and status.

An Agile approach with short iterations also means you get real feedback (i.e. running code or not) early before you've blown the whole month.

More details on the context please!

Answer 2

I find it easy for me to communicate through chats like google chat. We can understand each other clearly and they are good in written English.

You can give them task list by email and make sure that they complete those tasks in the given time and choose a team leader among them and make him more responsible for those tasks.

Answer 3

I would try to measure what their technical capabilities are. However, one month is a very short period to do this. I would try to read their profiles, etc.

I would use an issue tracker and have it always plenty of tickets. And then encourage the team to pick the tasks they want (it high priority, the better) and to report new tickets (reviewing them, so they don't report repeated tasks, or out-of-scope tasks, and reassigning priorities if necessary). So if they get stuck, they don't get idle until you connect the next day.

I would also make sure that they have a panoramic view of the project and what next releases should include. So I would avoid discussing detailed technical stuff in our meetings. I would repeat over and over this panoramic view of the project to ensure they don't get unfocused.

I would try to give them confidence to resolve technical details by themselves. I would encourage them to "own" the project codebase. I would post discussions on technical stuff as comments in the tickets, in order to reduce misunderstandings. Thus, I would be using written language for technical discussions, spoken language for managerial discussions.

Finally, I would let my superior know what are the difficulties of the project. Since you have accepted a very short line for a project that seems to be 100% risk.

Answer 4

When dealing with people who don't speak your language very well you should try forms of communication that are more universal and easy to reproduce by both parties.

This means use text more often than speaking and use pictures and mock-ups whenever possible.

Build wireframes and flowcharts and requirements specifications. Be very specific. The more precise you are with your direction the more likely it is you will get what you want. When you have cultural differences you don't want to leave too much ambiguity as the way they solve problems may not be wrong but it could be different than what people in the U.S. expect.

Answer 5

[in addition to other answers]

1. If possible assign an offshore lead developer or offshore coordinator. Someone with good experiences in offshoring, onshore-offshore communications, or at least someone whom you trust and have a frequency match with (you understand what he intends to say, and the other way around, without obstacles or assumptions). At first sight this might look like adding one more level of management, but this is greatly helpful. You do most of your communication with him, and he does to the team. And the in the other direction. Advantages: Effective communication, local intelligence for real time issue resolution there. It would also save a lot of little hassles: You need not stay awake the whole night. Some days you start early, and some other days [s]he leaves late. in the worst case each of you can work nights once a week.

2. As you would have already realized, communication is the key. and telephonic conversations are not always efficient given the differences in accents, language and culture. Chat is helpful manytimes, especially when you want them to send code and you send some. Since you have Skype you can use it for chat also. a screen shating program will be immensely helpful.

3. A strong plan, and strong status tracking is essential. Everyone should know what they do, and you have to know what their progress is. More often than not, this dicrepancy kills offshore-onshore collaboration

I would say you travel at least once and say a hi. Not now, but perhaps for future projects. It is very effective. You suddenly see improvement in communication and productivity.

(Perhaps related)

Answer 6

I'm not sure if you ran across it already, but there is a similar question on StackOverflow, as well as one on Programmers.StackExchange that might provide some insight.

From my experience working with globally distributed teams, here are a few things that I think may help you out:

• Communicate via text - In situations like yours, where one or more parties finds it difficult to communicate verbally, make the switch to text. A lot of people are much more comfortable communicating via text when using a secondary language, as it provides them an opportunity to correct mistakes (especially with Skype's text editing feature). From a managerial perspective, communicating via text is also nice, because it keeps an accurate record of who said what, when.
• Clarify everything - Whenever you communicate with your team, make sure everyone is on the same page, by restating each other's points, using your own words. Also, it doesn't hurt to send emails after every meeting, covering the important discussion topics, and their resolutions.
• Set common work times - Make sure that there are a few hours everyday that everyone on the team is available. During these times, team meetings will take place and any questions can be answered. As a manager, try to make yourself as available as possible, but don't strain yourself out. Provide the team with a phone number you can be reached at (at all times of day) for emergency/high priority situations.
• Understand how the work gets done - One of the best things you can do is understand how your offshore team goes about completing their work. The technical details aren't nearly as important as understanding the overall process. Do they use agile, more traditional, or mixed practices?
• Ask for their insight - If you notice a problem, more than likely, someone else on the team has noticed it as well, and may even have come up with a solution. It is also very common for your team to run across issues you aren't even aware of, so it is important for everyone on the team to be as transparent as possible, communicating effectively as much as possible.

Answer 7

I guess Agile comes with its own challenges when you're doing it the first time. I have a couple of questions -

1. Has the offshore team worked in an Agile project before?
2. Was the team involved in the planning sessions (Poker planning, sprint planning etc.,)?

Agile will only work as long all stakeholders involved are on the same page. Every member in the team needs to know what is expected of them and what and when they need to deliver.

If the team was involved from the start and still things are not getting done, then ask them to list down the impediments and try to resolve them one by one.

It would also help if the offshore lead is an experienced person. The lead plays a key role at offshore to get the work done.

Hope this helps.