Offshoring Classes

I came across this post on the internet that details the how companies now give classes on how to deal with offshore teams. It sounds absurd. It is clear that we are dealing with an Indian workforce that is ill equipped to do I.T. work:

Interesting class – pretty generic. Things like don’t take a response at face value on things that are critical, like project status. You will often get told what you want to hear rather than the truth. You need verification. If you really want to know the status, you probably want to befriend someone on the offshore team who will tell you, outside meetings, a bit more of the way things really are progressing, issues the team is having, and things like that. Because it is a society with so many people, people will cut corners to get the things they want. There is a ton of competition and you have to take whatever opening you have any way you can. They are very impressed with degrees and certifications. You need to throw them out all over the place to get any respect. Your business card needs to look like a reading chard. PMP, MSc, etc. (Which I am sure is a lot of the reason people feel compelled to fake them).

Verification is key – especially in a formal situation and/or where there are different levels of management hierarchy involved. A lower rank person will rarely if ever be honest if someone over them in the reporting structure gives you an inaccurate response.

Look for proof – if the team says they are 50% or 75% or whatever complete with something, do frequent reviews of what they have accomplished. This is also true because although you document everything to a great degree, the interpretation of that is often way off.

Just from my own development team, some of my takeaways were things like

a) if you document it very clearly, but wrong, until the team gets really comfortable with you they’ll usually not call it to your attention.

b) when they do decide to get innovative, it’s frequently nothing like you expect it would be and you won’t get told about it unless you specifically ask

c) you have to have mock-ups, playbacks, etc. if you don’t, you won’t see the results until they are pretty much cast in stone and they are expensive to change. The challenge is that the team won’t want to show you stuff that’s partially done.

A really interesting example they gave in the class was enlightening because it made a lot of sense from a project standpoint (this is very rough, but you’ll get the idea). One of the trainers lived in the US but her mom still lived in India. For a gift, she had a ceiling fan installed at her mom’s house and she had the work done remotely. When it was all finished, she asked her mom how it turned out and her mom said it was really nice, but there wasn’t an on/off switch. When the lady called the contractor, the contractor said she hadn’t asked for a switch, so they didn’t install it. One of the things reminded ourselves of as we prepared requirements later was “document the switch.” If you don’t specify pretty much everything, too frequently it’s not there – even if it’s ridiculous not to have it there. Or it will be put in, but in a way you never would have expected, and no one will likely tell you about it until it’s all complete.

We had so many examples where this was true in the work we saw if we were not detailed enough (we are talking about deep, deep requirements). Another example was a pop-up window from an application that needed to have several fields filled out. Only the popup window was about 3x3 and you couldn’t get to most of the fields. No navigation and the window was too small anyway.

A lot of you have worked with offshore teams. Are these some of the experiences you’ve had? What else? In some ways, in retrospect (my immediate team is now all onshore because we just had so many issues with a multi-geo model) it’s funny to look back and see some of the inane results we had as a result of cultural differences, difficulties in communication (time overlap, language, etc), not having the right level of detail, and struggling with hierarchical mindsets (sheesh – send an email to someone telling them they need to do something a bit different and it has to get copied to 5 levels of management). Or- and I can’t even tell you the number of times this happens – send an email with 5 very specific itemized questions and get a half-assed answer to one thing. Keep sending email back and forth about 12 times until you get the full answer to all of your questions. And try to do this in some kind of a hurry (ok – have to skip email and have an 11 pm or 6 am meeting to get it cleared up).

I saw this kind of shit at the Curry Den. An Anglo manager would go up to an Indian and try to get to the bottom of some bug, and the manager would have to explicitly request that the fucking Indian not lie to him. These were his exact words:

"I DON'T WANT YOU TO LIE TO ME"

DISCLAIMER: The thoughts expressed on this blog may or may not be the author's own and are protected by the 1st Amendment. Any attempt to reveal his identity by contacting a slumdog hack at Google, or a corrupt Desi sys-admin at his ISP will be dealt with promptly and severely. Civil and criminal penalties may apply if one is found to have used private information in an attempt to get the author fired at the Hindu-only I.T. ghetto he currently works at. In addition, any Desi who attempts to burn the author's house down because they are enraged over his writing will be prosecuted to the fullest extent of the law. This isn't India.

Got something I should know about? Classified company info like tax forms, org. charts, and emails documenting the ethnic cleansing of American programmers at the hands of the H[indu]-1B lobby? Email me. tunnelrat at itgrunt dot com.

Note to slumdogs: All death threats will be reported to the authorities -- it is pretty easy to track you down and get your ass deported once we have your email info.