Attrition doesn’t have to be the huge issue many companies face.

Managing Virtual and Distributed Development Groups in an Outsourced World – Part 4 of 5

In Part 3 of “Who Moved My Team,” we discussed evaluating your teams performance. Today we look at how to ensure IP continuity.

Part 4 – How Can I Ensure IP Continuity When the Bulk of My Team is Remote?

The final pitfall for a manager is the threat of losing key resources. It’s easy to lose sleep over the question, “can a competitor cripple us by hiring away key people half a world away, whom I might not suspect are at risk?”

I have seen turnover rates in India variously quoted by self-serving sources anywhere from 10% (“See, India’s pretty stable.”) to 75% (“Yikes!”) annually. Regardless, it’s my experience, and that of those I’ve worked within the industry, that turnover is becoming a large problem. Other countries are more or less stable, but the key is that you have little direct contact with a distributed team. Watts Humphrey, founder of the Software Process Program at Carnegie Mellon’s Software Engineering Institute, made the claim that developers will stay with a job unless actively pushed, and they can be kept loyal and engaged through rewarding assignments and appreciation of their efforts.[1] That is, you have to know what they’re doing, and encourage them.

But how can you give the appropriate encouragement, or even know whom to give a pat on the back to, without being there? The quick answer is that’s what local management is for – but that’s just dodging the issue. At the end of the day, it’s your team, or else you’d be gone and the local manager would have your job.

Ensure that knowledge is transferred, both within the offsite team, and from the offsite team back to your company.

What Works?

First, attrition doesn’t have to be the huge issue many companies face. Mr Humphrey was correct: Engineers don’t just leave a company – they tend to be pushed. Remote or offshore resources who are treated like fodder – given the worst (most boring or most impossible) tasks to perform, paid a minimum, made to feel not part of the team, and asked to work long hours – will leave. Wouldn’t you? Those who are treated as teammates, whose ideas are listened to, who are given challenging but do-able projects, who are paid fairly and given adequate time off…those people stay. At Calavista, we’ve had remote developers doing great work on projects for 5 years or more. Project attrition just isn’t an issue for us, and it shouldn’t have to be for you, either.

However, since occasional attrition is a reality, you should focus a great deal of effort on retaining the people who matter most. Therefore, the first step is to identify the key people. This may require some actual contact, but some of the principles previously covered in the section on evaluating a team’s performance are germane here. Once they have been identified, it’s important to encourage them in their work. Bonuses, training opportunities (especially if that means travel to the U.S.), and more challenging assignments all make good rewards.

The second aspect is to ensure that knowledge is transferred, both within the offsite team, and from the offsite team back to your company. Much of this is taken care of by the cross-pollination discussed earlier. However, in an offshore world, it’s very possible for a partnership to go south, resulting in the unexpected replacement of your entire team. For this reason, it is extremely important to maintain strong code management capabilities, preferably with the ability to track code changes by issue, or change set. New developers, when assigned a bug fix, should not have to wander aimlessly through the code trying to understand it – they should be able to inspect the work that was done in the issue that is broken. For instance, if there’s a bug in Feature A, a developer should be able to isolate the changes introduced by Feature A as a starting point for her sleuthing. If she can’t, at best she’s wasting time. At worst, the obfuscation could cause enormous problems if the offshore team is changed.

Next Up

We conclude the conversation of managing virtual and distributed development groups in the Part 5 – Techniques for managing virtual and distributed teams

[1] Watts S. Humphrey, Engineers Will Tolerate a Lot of Abuse, IEEE Software, vol. 18, no. 5, pp 13-15