 |
|||||||||
|
|||||||||
|
|
|
| This is a personal blog of Yakov Fain My son's animations and music No BS IT podcast Америчка |
I wrote this while sitting in a training camp Genghis Khan, a school for the rookie offshore programmers. The camp is located in the remote mountains of northern Mongolia. Many wannabe offshore developers come here for training. Since I am a popular personality among Mongol Java crowd, they let me sit in the class where Srini, the guru of offshoring was delivering the presentation called “Dealing with Overseas Employers 101”. These are my notes from this class.
1. America is rich, we are poor. It’s not fair, they have to share.
2. In the beginning, their manager will try to scare you by promising that he’ll check up on the status of your assignments daily. Do not be afraid – a status report is just a formality, and they’ll take whatever you write.
3. One of your major problems will be "what to write in status reports". Never write “I could not do it ” there. Americans like positive statements. For example, let’s say you’ve got an assignment to create a reusable component that will identify the number of failed database requests. You do not even have a clue what are they asking for.
The first week you spend on Google in hopeless attempts to find such component. The status report for the first week should read “Comparing various approaches of creating reusable db-failures component to find the most efficient and effective way for its development”. During the second week invent something similar. Hopefully, on the third week something more urgent will come up and you’ll get another assignment.
4. Be prepared to spend the first couple of weeks waiting for the logon id and password to your employer’s network. After obtaining these credentials, you’ll find out that you still don’t have access to a dozen of servers, which require Unix logon. Your remote manager will promise you to resolve it as soon as possible, but because of the service level agreements (aka SLA) with the Unix support team , you won’t get access for another week or so. Typically, it’ll take about a month just to get you connected.
5. Never say “I do not know”. Accept all assignments – one of two things will happen – either you’ll figure out how to complete the assignment, or it’ll get cancelled.
6. In conversations with your overseas teammates, always require detailed written specifications for each small program modification. Ignore their statements “I’d fix it myself faster than writing detailed specs for you”. They have no choice and must work with you to show that your team is useful.
7. Use time difference to your advantage. For example, if you want to send an email asking for some clarifications, do not send it in the moring, because you may get an immediate answer. Do it in the evening (your time zone), before leaving the office – you’ll get the answer only next day.
8. If you have a choice, avoid fixed price projects. Hourly-based pay will allow to put a couple of extra hours here and there, and having a couple of extra rupees or rubles never hurts.
9. Experienced offshore programmers never try to obtain US working visa and to work onsite. If you do this, you’ll work a lot harder – not worth the trip.
10. Always be polite – it’ll get you far. Insert “Excuse me”, “Thank you”, “Yes sir” in every other sentence. Always smile - even during phone conversation. The he showed this movie about an offshore tech support.
11. Change your local employer every three months. You are gaining experience daily, and even if the new job offers just one percent of salary increase, go there. It’s a golden IT offshoring era – use it while it lasts! Or as they say, it's time to make a quick buck!
12. If you work in QA, keep a couple of bugs unreported till the very last date of the testing cycle. Report them at the end of this day. They'll have an emergency meeting, production released will be postponed (no big deal) and you'll be able to put more billable hours on this project. Repeat the same procedure at the end of each testing cycle. In computer science this is called recursion.
For some time I was speechless after hearing all these advices. Srini spent at least half an hour after the class answering specific questions from students. I also asked him, if he really believed in his teachings. He smiled to me and said, “Welcome to the real world, ma man!”
And most of it is different than normal cubicle-drone's modus operandi how,
exactly? :)
I have heard similar, rather cynical, advice given to support staff at an
outsourcing company where the customers were in the same building. The
objective is much the same, to reduce costs. It was described as "managing
customer expectations".
Advice like, don't even look at a request until the day it should be
completed, otherwise if you do it sooner you may set an expectation you
might not be able to meet later.
Ten years ago I was working as a consultant for a large company that have
outsourced the hardware purchases to some USA third-party company. Their
hardware prices were double the street prices, but we had to order only
through this firm. I guess, in many cases outsourcing is born as a result
of some some super deal between a small number of individual, with
kickbacks involved. This equally applies to local and offshore
outsourcing. And then, the public is being brainwashed that it does your
body good.
The only positive experience with outsourcing I had so far was when we (a
small firm) were working with bright individuals from overseas and closely
managed them.
hi there,
Sad to hear about this. I'm sure there are some unscrupulous elements over there.
I've heard similar about a Fortune 50 company in the US where its consultants are given almost similar advise. I'm sure there are greedy people everywhere -- we only have to look at Enron and WorldCom for other examples closer here.
What I notice in many US companies though : People don't notice what happens to the source code repository. In the 1st 3 months of any developer joining a group, one should compulsorily require a DAILY update on their source code checkins and checkouts. As long as each developer gets their own private stream(using clearcase lingo here) on the SCM, monitoring checkins should be fairly easy to assess someone's progress. You could even automate the whole process so that you get a daily report of the activity -- This process should work as long as you have less than 20 direct engineers reporting to you.
That said, there was a time when I was on the other side of the fence. I was told NOT to be too optimistic since they wanted to be safe with the clients. specifically, they did NOT want to disappoint the client
It surely helps to have someone you can trust sit with these developers. I forsee in the near future that there will be availability(on demand) of professionals who you can trust that can babysit such lazy folks. These professionals will use automation tools and then prepare an (manual) independent report for the US manager.
Hello,
