I’ve worked with offshore teams for over 6 years both as a contractor (with an offshore team) and as a VP in my current post heading up Product Development for Dominion Dealer Solutions.
When you are a contractor, managing offshore talent requires no real balance because you are the manager supervising your offshore programmers. Your job in this task is to communicate well, manage expectations for both the client and the team, and then know the strengths and weaknesses of your team… promoting one and carefully managing the other.
Managing local development teams that use offshore talent is a whole different beast. Your challenges are multiple:
- Buy-in from your local team is critical. You need to sell offshoring to your local team through logic and common sense. If they can’t get their projects done because they can’t find local developers quickly enough, then using offshore is logical.
- You must listen to your local team’s concerns. If your local team has concerns, hear them out. Work with them using logic and common sense… something developers respect. Shoving offshore talent down their throats is a sure way to lose your best people.
- Getting started can be a challenge especially if local teams have an anti-offshore bias. Start small with offshore support that will augment your team so that people can work through their biases and find success. We started with QA. The key was in defining clear rules, expectations, and specs for the QA team. It worked well thus giving my teams a good model with which to start.
- You must help your team learn how to manage their offshore partners. Don’t just dump the offshore team on your local team as say “Go!”. Help them pick the team, select the tasks and set the rules, learn how to communicate, and release the offshore team if things don’t work out. We had one offshore team that couldn’t get things right no matter how hard we tried. Part of the management challenge was knowing it was OK to let them go quickly the same way you would a poorly performing employee.
- Know how to communicate with your offshore team. Different cultures communicate differently and their attitude about work can vary. For example, some cultures do not obsess about work like many Americans. They see work as equal to other pursuits in life. They work hard… but play hard too. Moreover, other cultures treat authority differently. Americans are comfortable with challenging authority while other cultures practice greater deference. A good rule: When you ask the person if they understand, they might say “Yes!” but not understand a thing. Sometimes you need to confirm what they understand by having them recite it back to you.
The list goes on, but I’ll leave it to another blog entry. What I am discussing here is balance. Once you create your team of local and offshore talent, do you freeze your local team’s size and build your offshore units as you take on new business? How do you balance your team… do you use your offshore support everywhere or do you specialize their focus?
The answers to these two questions depend on your values and how you manage risk. I’ll hit both of them separately.
Once you create your team of local and offshore talent, do you freeze your local team’s size and build your offshore units as you take on new business? I would answer this question with a resounding “No!” about freezing your local team’s size. There are some who pursue this model, but I think it is a bad idea for the following reasons:
- You need a solid base of local talent that can manage your offshore teams without being overwhelmed, can keep your coding standards to the level you seek, and can retain the necessary industry knowledge to give your software the edge it needs.
- The more you bias toward offshore, the harder it will be to hold onto top local talent. I may be wrong here, but serious coders don’t like to just be managers… they want to code!
- The industry typically sees a balance of 1 local to 5 or 6 offshore as ideal. I think this makes sense if all you want to do is put most of your talent offshore, but I believe that it is better to maintain a roughly equal balance using offshore for specific tasks/functional work and keeping a strong local team that can stand on its own if there are breakdowns in your offshore model. This approach mitigates risk, but can shift in favor of a larger offshore team when you have bursts of work and then can stabilize when your workload returns to normal.
How do you balance your team… do you use your offshore support everywhere or do you specialize their focus? From my experience, I would suggest that it is best to use offshore for:
- QA/Maintenance: Using your offshore talent for this type of work is often a great fit. There are many offshore teams that specialize in QA from manual to automated. Our fit has been very good. Breakdowns have largely occurred when we have not outlined a clear testing plan… (Our fault!)
- Specific Projects: We have used offshore teams to do new feature work alongside our local teams within our sprints, but this often takes a more management on our local team’s part than I like and can lead to critical code spinning out of control unless you are very careful in your code reviews (leading to refactoring that is a pain in the *&@). Using your offshores for a specific project with clearly defined coding standards works well… especially if you make them demo their own code during code reviews and have a qualified dev look over their shoulders.
- Code Migrations: Migrations are usually time consuming and tedious. Using offshore support for this type of work gives your local team time to do more important new feature work.
So where does management fit in with all this tech talk? You are likely to find that the business side will see offshoring as a great way to save money. That make sense from their point of view, but it behooves you to clarify that the money saved is often counter-balanced with higher levels of management, the critical need to develop industry knowledge in your tech team, and the key requirement to have a solid local team that can hold down the fort whenever necessary.
I stress all of these issues with management so that we maintain the sought after balance I listed above. Interestingly, I have not mentioned one other reason that I feel is important… employing locally is good for the local economy. I guess I’ll just let that little confession sit here as my ending to today’s post. 😉
* * *