Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Update 3

The project was completed and delivered on time.

The key factor was me working the same time as the offshore team. If that had not occurred I'm confident we would have failed. I managed two offshore teams. One of the teams under preformed and I fired them taking on the work myself.

Things that lead to success was:

Communication, understand their culture and how they communicate. Build rapport with them. A couple of the workers I keep in touch a year after the project completed.

Meetings, we met at the beginning of their day so any questions or blocked tasks could be addressed. At the end of the day a daily summary was send out by the worker describing their day and if they encountered any issues. Ideally we could resolve their issues by the start of their next day.

Questions, ask questions. Most cases information is not volunteered.

Be visible. Being online, available and reachable help fostered the team's commitment to the project. I was not just the daily email.

Make it easy. Internally we had a complex QA system in which bugs where tracked. It was complex and hard to use. I paid the $$ for a fogbugz account for each of the team members. Most of the team had used FogBugz and understood the workflow. Daily I would update the fogbugz with new bugs and update the QA system from Fogbugz. Stackoverflow question Leading an offshore team

share|improve this question

closed as unclear what you're asking by gnat, Bart van Ingen Schenau, GlenH7, MichaelT, World Engineer Mar 17 at 14:17

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
Wow, good luck. This sounds like a train wreck in the making... –  Mason Wheeler Oct 8 '10 at 23:42

8 Answers 8

If you are having trouble communication, try written communication. If their English is too weak, perhaps providing code examples as well as written explanations will help them grasp the concepts. Skype has a messaging system that can be used alongside the webcam communication. And about the time delay. I know it is frustrating (I have a three hour delay with my family), and 12 hours must be insane! Perhaps you should become nocturnal, if you have little else to do. And even if things are looking like the're crumbling to the ground, just keep up the persistence.

share|improve this answer
3  
I agree. In my one successful experience with working with an offshore team, I used Yahoo chat in real-time. Eliminated the problem of dealing with accents, still allowed back and forth communication, and provided a written record which could be archived. It did require me to adjust to their hours. –  tcrosley Oct 9 '10 at 2:33

If you have the budget, I would consider flying to India and meeting the offshore teams in person as soon as possible. This will allow you to get to know them and gain their respect and trust much quicker than through Skype and email - and you'll also be able to make sure that they are on track. After a week with them they should be ready to go, and you will be able to keep saner hours (though some overlap will still be necessary.

Switching to their time doesn't seem like a really sustainable idea: unless you are a night person, this will hit hard on your productivity.

share|improve this answer
    
+1, nice answer. No one mentioned the trust thing. That is very very important for both sides. –  Geek Oct 10 '10 at 4:39

Some points to be noted in this offshore-onsite engagement are

  1. Using written communication is always good. Whatever we talk in conference calls may not reach everybody at offshore. Daily task status updates through email is better idea than daily conference calls.

  2. Your evening time is offshore team's morning time which can be ideal time for team meeting/conference calls. People at offshore may not like idea of meeting at morning which is late night for offshore.

  3. As you are 12hrs behind offshore, you have 12hrs 'extra' buffer time before anything goes wrong. And it enables project working hours as 24 hours. And its great while you sleeping your project will be taken care at offshore.

  4. Communication gap can introduces problems here. If strict timings not followed, offshore timings can eat personal timings at home.

share|improve this answer

One of the teams under preformed and I fired them taking on the work myself.

All too common, IMHO. The success of this project was not that you worked late and communicated with the teams, but that you did half their work. I often say that 1 good man is worth much more than a whole team of cheap developers, and you prove my point.

If you hadn't been able to take on that work (eg if you were a non-technical manager), then would you say it would still have been a success? I doubt it. It shows that having an offshore team is fraught with trouble and anyone thinking of taking such a thing on needs a massive amount of backing, infrastructure and excess capacity to make it effective. The headline numbers simply don't add up when you factor in what's needed to make it successful.

share|improve this answer
    
It would have been much more difficult to be successful. I was handed a group of developers without the opportunity to vet them. Out of the 8 developers, 2 or 3 could work independently. –  Chuck Conway Dec 3 '13 at 16:08
    
I feel your pain, I imagine the other 7 or 8 couldn't work without being hand-held all the way. –  gbjbaanb Dec 4 '13 at 12:33

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

The two words highlighted above seems incompatible to me, by nature. But I know it's not the point. As a frustrated Agilist, I had to react :)

Regarding offshore management, everything is related to human communication, that are in different cultures, most of the time have different goals, different background, different everything.

This is why I think offshore development is amazing. You met people (and their culture) all over the world (I'm not stuck to india) and that make the things more enjoyable, but also a lot more difficult for the beginner.

I assume here you do not write code. If you write code, I highly suggest you to stop here and take a flight to India. I also assume that you don't want to micro-manage them all, and that you are more the interface between the business and the development.

  • Since you are short on time, I would suggest you to discuss only with the team leader and give me power to manage the team. Self managing teams is very uncommon in india.

  • The stand-ups meeting is a good idea IF you watch them remotely and don't participate. Let your team leader do it for you.

  • Take time to discuss with your team leader on phone regularly. At least 3 times a week.

  • Ask your team leader to aggregate questions and send you a mail ONCE a day. Take the time to answer them, don't rush.

Once you have passed that deadline. Consider purchasing these two books:

Finally, I will say that the only way to handle offshore development with ease, is to practice, practice, practice. And please, if you don't take lot of pleasure communicating with those marvelous cultures, stop.

share|improve this answer

In addtion to working their hours (sorry but you don't have the time to do otherwise), I suggest code review as often as possible. You do not want to get to the end of this project and find out the code is a horrible mess. I also suggest spending a lot of time on developing tests if you don't have a QA team. Not the unit tests the devs should do (and I would want to see them too!) but tests based on the requirements and user tests, so you can be sure that what they did met the requirements. I also suggest reading up on the Indian culture - the devs are less likely to push back when something is unreasonable or doesn't make sense than American devs, for instance. So if you are expecting that level of questioning, you may think things are fine when they are not.

share|improve this answer

In my experience verbal communication is also important don't replace it entirely with written communication. Try practising both. Sorry that their English is way too bad :(

share|improve this answer

As an alternative, you may want to consider bringing one of their team leaders here. We did this (at a major financial institution) and it was helpful, though the overall experience was still a bit shaky. The onsite lead would work a couple of hours a day with us and then would direct his team at night.

The benefits of this are:

1) Practically instant credibility

The lead will most likely be a solid developer/tech lead and repoire will be built in no time. They should already have credibility within their own team.

2) You still get to work closely with your local team

I'm assuming that you are not alone on this. You'll have to work with the business or project management through the development cycle.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.