Managing a Global Programming Team? 737
cwimmer asks: "I work for a technology company in the United States who survived the economic slowdown by trimming fat where necessary. Unfortunately, it seems that my small programming team must've looked like mostly fat to management: it has been trimmed from a high of 5 to the current 2. We have been given a very large programming project that we estimated would take 4 coders (the size of the team at the time) 6 months to deliver. I have been given deep pockets with regard to moving some or all of the project to an offshore partner, and I can probably get 4 or 5 programmers in India. Does anyone have any pointers on managing a team of programmers on the other side of the world?"
Re:Yes. (Score:3, Informative)
Re:Yes. (Score:3, Informative)
Do not do it! (Score:5, Informative)
I'm not sure what all the root issues are, but the time difference is huge. Get used to 9pm phone conference meetings. It was horrible explaining the software needs to the offshore groups. And fiunally, it's much harder to do quality control with people who aren't actually there. It's much harder to get them to fix problems when you don't have an in-person presence. Most programmers by nature get things done in the worst possible long term way. In the offshore situation, you will have almost no power to encourage them to create code that's built to last.
Good Infoworld Column (Score:1, Informative)
Suggestions. (Score:5, Informative)
In terms of working with them off-shore.. You have the time-zone differences, which could be a potential headache (not sure exactly what the time difference is). Most Indians would already speak english (with decent clarity) so that usually isn't a problem.
I personally enjoy working with the Indian co-workers (off-shore or H1B's). The Indians that I have worked with have always been very productive, friendly, and don't slack off as much as their American counterparts. They almost always have better education backgrounds (due to the need for visas) but conversely have less real-world experience. Granted, I don't exactly like the idea that they are taking jobs away from Americans, but I can understand why companies will hire will hire them. Especially in this economy, where they are very excited about being able to get a position and will typically take a lower wage to work.
Re:The usual suggestions... (Score:5, Informative)
Just do the usual stuff...
...but in spades.
My employer first began contracting work to India about 10 years ago. The first couple of projects were dismal failures; but we eventually got the hang of it and continue to use lots of India-based developers. Here are a few of our learnings:
Re:Yes. (Score:3, Informative)
India has 14 official languages. Hindi is widely used but is not the native language of many Indians and is not even related to the languages spoken in South India.
So, while it would be commendable if you learned an Indian language to communicate better with your staff, you might have to learn several if they come from different regions of India. Not very practical IMO.
Here's one opinion (Score:5, Informative)
In general I wouldn't recommend offshore development for a small company. The overheads of managing the operation will kill you, and you will typically be doing exactly the sort of work an offshore team is less suitable for. It is much more suited to a large company that can build a long-term relationship with the offshore team and use them to help out several different projects. This allows you to amortize the overhead costs over a number of teams and projects.
Good luck.
Cost less for a reason (Score:2, Informative)
Be prepared to document more than you've ever documented before. You can't 'wave your hands' and get the point across. You have to do rather formal and complete documentation for any portion of the project that you would ever want them to do. You can't do small-group programming, like when your programming partners are staring over your shoulder, when the rest of your team is 10.5 timezones away. This may seem obvious, but a lot of folks miss this one.
Nail down your code/source/project management tools, and choose ones that can work in a multi-master (when more than one server can maintain data for the same project) or disconnected mode (see note above about connectivity).
I don't know if this is cultural or just a bad experience, but it seemed to me that there was no reguard for schedule or deadlines. Trying to get folks to actually attempt to meet a deadline was difficult most of the time. We had to go to India and sit on some of the people to get anything out of them. What's the ROI on that?
English is one of the official languages of India, but you'll still have language issues. Usually not too bad, but can be humorous at times. I remember once a sever was taken down for 'upgradation'. If you are having them document any of their own code, have it proofread by a US tech writer.
Be prepared to go nocturnal at times. There are times on any project when all folks have to be available at the same time. You will have to match your schedule to theirs.
Good luck.
India isn't your only option (Score:5, Informative)
Software development--particularly business software development--isn't about computer "science" or "engineering." It is about communication--communication amongst your team, communication with the computer, and communication through the computer with the end user. Communication is the key.
In hiring offshore developers you face substantially more complex challenges than you do working with a telecommuter. People who telecommute have established relationships with their employer--so they already know the implications of the tone of your voice, and what you mean when you preface your sentence with "I don't mean to be rude, but...." An offshore development team doesn't know that--you don't have the kind of relationship, based on trust, common bonds, and plain old time, that are necessary to make a team work.
There is a simple way to deal with that problem. It is called an airplane ticket. You go to them, or they (all of them) come to you--naturally that means you're the one on the plane. You can find a whole range of airfares, and a whole range of hotel prices, and a whole range of expenses involved in traveling literally halfway around the world. And unless your project is huge, you'll blow any conceivable cost savings on the travel.
You have other options
One (warning: self-serving promo coming) is to outsource to a consulting firm [windgap.com]. They'll charge you a fee--but at the end of the project they will go away. You don't have any overhead costs, you don't have any headcount, and you don't have costs for machines and toolsets that you no longer need.
Another option is to consider outsourcing to an "offshore" country that is considerably easier to get to. If you're in the United States, you might look very carefully at consulting firms in Canada: the Canadian exchange rate makes tech workers up north very attractive. And Canadian "offshore" development avoids a lot of the problems with outsourcing to the Indian subcontinent: Canadian firms are (mostly) on the same time zones as U.S. firms; Canadians and Americans share a common language--most of the time; and Canadians and Americans share a common cultural heritage (most of the time). In general Canadians are more polite than Americans, more funny than Americans, and perhaps more serious about their work than a lot of Americans.
Believe it or not, sometimes outsourcing deals don't work out....
An old dictum of business law says that you don't need a contract when everybody is making money. You only need the contract when things go bad. That's true--and that's why you'll need a solid contract before you start any project with any outsourcing firm. It is a lot easier to find legal help with contracts between U.S. and Canadian firms than it is to find legal help with contracts between U.S. firms and Indian firms. And--(look for articles on this subject in Fortune [fortune.com] or The Wall Street Journal [wsj.com]) the legal climate in India is not as stable as you'll find in developed countries. Long before Enron hit the headlines with its accounting problems, Enron was embroiled in a long-term dispute (see this BBC article [bbc.co.uk], for instance) with the government of India. There are all kinds of charges and counter-charges, but many in the West have viewed the debacle as proof that in India contracts are not nearly as ironclad as we view them to be. If it comes to it, it is substantially easier to litigate in Canada than in India.
Bottom line:
Don't. (Score:3, Informative)
To make that sort of operation work, you'll have to write such detailed specifications that you'll practically be coding it yourself. You're much better off with a couple of coders who will look at what you're trying to do, and make it work that way.
Canada (Score:2, Informative)
-Duke
Yes, Don't. (Score:3, Informative)
Unless:
- Your 6 Month deadline is flexible to ~ 9 months (b/c it'll take a loooooooooong time to get in sync)
- You know of specific competent people there that you know you can rely on (b/c mostlikely you cannot)
- You have specific requirements spelled out precisely how you want it implemented
- You do not need to worry about performance and memory (b/c mostlikely you'll take a hit there)
- You can't just hire another American employee and try to sweat it out... (b/c otherwise you're obviously working against the common good of the programmers in this country)
- You can deal with severe communication barriers. Lets face it, I know of PLENTY of H-1's that have lied about having a college degree to get a job here. Its obvious when they don't: they can't speak or write english well! You're mostlikely going to hit this problem!
- There's nothing preventing these people in India from blackmailing you for more money by not providing what they promised (its happenned to us!).
Need more??
Re:The usual suggestions... (Score:3, Informative)
- spec your work as detailed as possible. That includes GUI look, feel, nav, etc. If you don't do this, you force your offshore friends to get creative - and you definitely do not want this. It's amazing how much cultural influence you get in a GUI design....
- this goes double if the work is OO-based! OO development is by nature a collaborative effort, so we tend not to spec the details. This doesn't work when the team is somewhere else. Believe me.
- establish up-front how software testing will be done. In my experience, unit testing is about as far as you want to go before they hand it over for system and acceptance testing. Otherwise, you end up with a big heasdaches (security, connectivity, etc.) connecting these folks to your internal development infrastructure.
- bring a few of your offshore friends in-house to get a feel for the people and approach your IT shops uses. This is really key to building trust and context for future endeavours.
- Only outsource what you know. Don't ask your offshore friends to develop stuff with which your company has no real experience. It will be a disaster for all involved. Trust me.
Guess that's it. Good luck.RE: Managing a Global Programming Team? (Score:3, Informative)
The Dutch product is supposed to integrate with the product I work on, but in more of an inter-process-communication way than a codebase-integration way. That is to say we collaborate on interface, but implementation is generally determined locally.
Even so, the geographic separation has been a nightmare! At the very least, the nine-hour separation makes the round-trip turnaround for an email Q&A one full day: (I ask a question at 9AM PST - which is after quittin' time in Holland - so they don't see it until 8AM their time (11PM here) - and I don't get an answer until I come in the next morning.) And these are locally-managed developers with an execellent existing infrastructure. The problems would increase exponentially with the required granularity of long-distance management.
A recent assesment of the problem by an outside consultant suggested that the only cure for this problem is a large increase in spending on plane tickets. Our developers will have to fly there, and vice-versa, for face2face communication far more often than the semi-annual visits we currently do. If we had hired the Dutch developers just because of their lower cost/hour, we would have seen the savings completely blown in the additional travel costs (not to mention the lost productivity from jet-lag - you're not going to get anything useful done when you hit the tarmac at Schipol at 8AM local time, but your body is telling you it's bedtime.) This problem would only be worse if the remote office were in India, with a 12-hour separation.
Summary: The overhead of long-distance management will far outweigh the savings realized in hiring cheaper developers. Don't do it.
Re:regardless. (Score:5, Informative)
If there's that much more money in Bangladesh, though, then people there can afford to go to the hospital, and that many people are no longer dying in the streets. Moving jobs around doesn't destroy wealth -- it simply redistributes it. What globalism does is help make the market more even -- smooths out the particularly rich areas (as labor will be imported from elsewhere) and the particularly poor ones (as they'll be able to export labor cheaply). The net result, then, is that the standard of living everywhere will move closer to average -- without the use of government wealth redistribution (which I find repugnant) but merely market forces.
The point I mean to be getting to, however, is that people won't starve -- they'll just have to work for less. Countries without minimum wage laws will do much better, of course (they'll be able to export the labor of folks willing to work for less than the minimum wage elsewhere, whereas those in countries with minimum wage laws will be unable to find work at all in fields where the going market price is below the mandated minimum wage) but that's a problem with government interference, not globalism in general.
The main reason I can see people being homeless and starving due to such smoothing is artificial price floors -- minimum wage laws (allowing foreign competition to result in unemployment rather than merely lower pay), building regulations (raising the minimum price of housing and forcing people to be homeless rather than merely poorly housed), that variety of thing. Those problems can all be fixed -- and the net result will be less starvation. If there's less conspicuous wealth as well... so be it!
And I say this as a capitalist myself -- but as a fellow who'se convinced he has even globally a better-than-average product to sell, and who is happy to have more buyers (and more competition among his suppliers!) even if it means competing against more of my fellow sellers. I also say this as a fellow with a sister who'll be halfway around the world in a few months who may not come back -- I hope that she can always find work able to cover food and rent wherever she goes; if that means taking a job exported from elsewhere (like my employer, which has offices around the world), all the better!
You claim to be a "capitalist", but what you want is not a free market but a market rigged with tariffs and restrictions and taxes to benefit yourself alone. It's a short-sighted thing to want -- it may benefit you immediately, but the infrastructure set up to profit you immediately may bite you in the ass later; and the power to lay those tariffs in your favor can every bit as easily be used to raise the cost of the goods you sell. You mistake capitalism, a means of efficient resource distribution via fair competition, with unadultered greed; and shame the former in the process.
Also checkout the company!!! (Score:2, Informative)
However, check the quality of the company.
1.) Look for a company that is owned by an Indian who lives in the US. This will save you a lot of problems as a company owned by an Indian-American is more likely to have already addressed many of the cultural, not to mention technical, issues. Plus you want an Indian-American owner because they can better explain to you what to expect from the Indian business culture, some of which is actually better once you know what to ask for.
This is important because you don't want to spend your time and money teaching another company how business in done in America.
2.) Ask the company to provide you a written list of what documents and work products you can expect from them. This will cost you, but it will save you lots in the long-run. Every company claims to have process, but if you hold them to delivering an SRS document (etc.) before coding then you will quickly get a real feel for whether or not they use a formal development process.
3.) Ask about their facilities.
Find out if they own or rent the building. Companies that own have better financial backing and are more stable (usually).
Also, are they connected with a local University (this can save you lots of money and time for mundane programming tasks!). Affiliated companies can also hire more quickly should your requirements rapidly change. Also, they'll be more flexible with regards to a sudden and short-term need for additional staff.
Also ask about their Internet connection if you will be transfering large files. Everyone will tell you they have broadband, but you should test this by sending several large files (40MB) over a period of several days. Also, put instructions for downloading the second day's file in the first.
---
And Finally:
All in all, I would highly recommend checking out the company and not just they technical capabilities.
Also, don't listen to all the negative people who say that Indian programmers are not good. If they are not good, then how did they develop a multi-billion dollar software export industry (which happens to be the world's largest supplier of software services to the good 'ol US of A).
As an owner of a trans-atlantic software development firm, I wish you the best of luck. Plus, on the off chance that you get a lemon with your first attempt at hiring offshore, don't give up, just analyze what caused the problems and fix them.
Thanks,
Akbar
President, COO
America Technologica, Inc.
Re: Real costs of Indian development (Score:5, Informative)
Background: I've invested five years involved in the management and growth an Indian engineering team, and spent one year working for an engineering company based in Bangalore. I'd like to share some real experience and raw numbers for educational purposes.
First off, two things compel management to explore Indian development as a viable option:
1.) Cost savings
2.) They speak English
First, cost. The burdened rate for your average full time US software developer currently runs around $30-$50 an hour. (Burdened rate= hourly expense to the organization, which includes hourly wage, PLUS hourly breakdown of benefits, PLUS hourly breakdown of an individual's share of the operating expenses, calculated roughly as "AnnualExpenses / NumberEmployees / 2080", 2080 being full time work including vacation and all that.)
The burdened rate for your average web developer in Bangalore India runs anywhere from $6.50/hr USD for entry level engineers to $20/hr USD for intermediate host software end embedded engineers. Note that Bangalore is perhaps one of the more expensive markets for developers, certainly more so than Chennai and in Hyderabad (see below for regional discussion).
Quick - do the math. From a cost accounting perspective this makes loads of sense. The devil, of course, is in the details.
Next issue: "they speak English." That is true, but in the south, where the "High Tech Triangle" is defined by the cities of Bangalore, Hyderabad, and Chennai, often they speak Kannada or Tamil first, THEN they learn Hindi and English in school. Sometimes English isn't even their second language.
At this point many laugh and point out that there is then no way one could hope to understand these people, but that's an oversimplification. I've yet to have an experience where I've been unable to understand what an Indian Engineer is telling me.
Where this becomes an issue is where communicated expectations and requirements are sloppily conveyed verbally or through informal channels, such as Email. This audience of any should know to manage requirements well, but I've seen this mismanaged repeatedly.
Number 2 on the aged list of "Sex Best Practices of SW Development" states one should "manage requirements." Working with teams in remote locations, regardless if they are across the country or around the world, will fare far better if you nail this essential rule.
What happens if you don't manage your requirements? I encourage anyone to try working for a US company while located in a remote office...or even managing your project while on the road and working out of a hotel room. Working in India is often like working at the end of a 10K mile whip. Most people forget that hallway conversations don't make it to your remote office.
One more point on requirements: make sure your specifications include a definition of UI, preferably developed in the market where the product will be used, and look into using a string table to manage your strings, which helps greatly in your localization efforts. I actually make these recommendations regardless of where the SW team is located. Since when have traditional SW developers created winning interfaces?
If an Indian engineer has been toiling to get into SW development since they were 13 years old, how would they gain the experience to know what UI is intuitive? And even though developers have a good command of the English language, don't expect them to fix typos in your strings...which is why a string table is often better.
This is actually a huge issue, but in summary, nail your requirements and you come close to nailing this whole "they speak the same language" deal.
Finally, don't be shy to call during their operating hours, which on the west coast is 11.5 hours off. The work day typically begins at 9-10 am, and continues till 7-8 pm. Lunches are at noon or 1, and there is a coffee time taken at 3 or so. A phone call will nail close to every issue, far more so than an Email.
Finally, know your regions and how to take advantage of them. The "High Tech Triangle" is getting pretty sophisticated and therefore expensive, relative to other developers in other areas in India. Step outside this triangle and find some fat development deals, such as Profluent (not the one in San Jose), who is located outside this region and therefore hit even harder for business than those within, but my getting access to Profluent came through a strong personal relationship I have there. It pays to network.
Bottom line: process exists to negate risk, so evaluate the risks, then staff and define processes as appropriate. If I were to do it all over again, and I am, I'd invest in a project manager whose not afraid of 36 hour flights and 2 am calls, and I'd work with a smaller development shop before I'd work with a large one, for reasons I'll not enumerate here.
I'd like to end by sharing why I continue to chose native Indian developers for personal start-up ventures involving my investments: the developers I know there exceed the technical sophistication of domestic US resources. Too many American engineers smugly avoid cramming on diverse topics, a skill learned in the high-stress schools that weed our slackers. If I want good engineering work I call my friends in India.
I hope this has helped.
It won't work (Score:2, Informative)
China is a good alternative (Score:2, Informative)
If your calculations are right, the total cost of a Chinese programmer is even lower than that of Indians. This fits with the view I've heard from some other big companies discussing outsourcing; India is getting too expensive.
Plus in China, with so many foreigners here chasing "the wild-wild east gold rush" you have excellent native-speaking systems analysts, project managers, even designers on the ground!
I've worked with Indian teams as well, and here are my experiences:
Language barrier
Over the phone it takes quite some effort to understand what they are saying; if you're used to the Indian English accent, ignore this.
Crap requirements management
Even companies claiming to be CMM Level 5 didn't manage requirements; they just casually talked about them over the phone. This seriously destroyed my faith in CMM Level 5 as a useful quality measure. Note that I'm not claiming most Chinese companies will be better, just questioning value of CMM.
Poor user interface design
Here I agree with the previuos poster: outsourced to Indian software development companies, the user interface will be everything but user friendly and obvious. One company that had the user-interface for their website developed in India had to offer 2 day training programs to teach people how to use the site! Talk about self-evident design! Let professionals designers do it. In China you can find plenty of US and English designers, at a very reasonable cost; they're here for the experience, not the money.
I'd be glad to forward requests to software development companies in China.
Re:China is a good alternative (Score:2, Informative)
Good Experience in China (Score:1, Informative)
I've had a very good experience with outsourcing programming to China. We're a
small company with a (correspondingly) small budget and no inhouse
programmers. But we realised that if our company was to grow rapidly we had
to move a lot of our workflow online and offer 24/7 access to information to
our clients.
We spent a long time drafting a requirements specification and on paper
designing and re-designing the site until we were clear on what we wanted. We
took our specs first of all to several companies in the UK and discovered
that there was no way we could afford to invest that amount of money. In
despair and shortly before giving up a friend mentioned they knew a foreign
run software development company in China.
We contacted them and everything was plain sailing. No language barrier, even
more importantly no cultural barrier, the project was completed on time, on
budget and at a price that we could afford.
Being a web based application it was very easy for us to check the work as it
progressed. We did have some problems with features implemented wrongly but
that was down to our lack of experience in writing specifications as much as
anything else. Once the app was delivered we found a couple of show stopping
bugs during our own testing phase which if they had been allowed to go live
would have been a disaster, but we found them and they were fixed within
days.
We signed an ongoing maintenance contract with them which has been running for
a year now and so far we are very happy with it.
Retrospectively I think the key elements to our success were spending a lot of
time on the design and making the specifications very detailed and readable;
and having experienced westerners at the other end to translate our
requirements to the Chinese programming team.
Why India? (Score:1, Informative)
Re: Real costs of Indian development (Score:1, Informative)
Working in Northern Ireland and having managed a number of development teams for US based companies I can tell you of my experiences that are obviously NI based and have always been good.
If treated well developers stay with a company for life. Well at least three years and but +12 is not uncommon. This has advantages and disadvantages, you get staff with intimate product knowledge but if you hire a looser your stuck with him until you take action (more on that later).
Culturally NI and US are very similar. Just look out for differences in humour and a lack of political correctness. Some Americans have difficulty with local accents but this is rarely a problem and does not effect written communications. Other differences are holidays. We like to take three-four weeks at a time (OK, don't fall off your seats, this does not cause a problem, if managed). Work Ethos - we work harder during working hours but are much less likely to come in early/go home late. Typical working week is 40hours. My experience with American and NI programmers reporting to me is that it does not make any difference.
Government grant aid exists to help set-up a business here, especially if you plan to grow it, if nothing else they can help you evaluate NI as a location for offshore development (http://www.investni.co.uk). There are also grants for training and research. Personally I suggest treating these like a bonus, if you can get them great but don't base everything around them.
Developer cost range from less than $30K/year for a graduate to $60K/year for a senior engineer with 10+ years. Typical costs for a good C/C++ coder are around $45K/year. On top of this you should budget ~17% to cover employee benefits such as medical insurance, pension (401K) and government taxes. Graduate programmers are of a much higher standard than in the US, probably because they do a year out in a commercial environment as part of their course.
Office space is cheap.
Ignore anything you may have read in USA today or seen on CNN. Belfast is not like the image portrayed in the media. I have brought many Americans here, most were worried about their safety, and all have either been back or left wanting to come back. To put things into perspective, more people die on the roads here each year than due to terrorism and the general crime rate is one of the lowest in Europe (unfortunately going up).
Don't split the project between two different sites. Minimise the dependencies between sites and give each site a complete task and make them responsible for it and for achieving the deadline.
Don't underestimate the importance of face-to-face communications. It is surprising how much inter-company knowledge is passed via hallway meetings and chats in the toilets! Make sure you visit the remote office and make sure they visit you. You can fly to anywhere in the US from Belfast for around $600 via London and people here do not generally expect to fly business. In many cases it is cheaper to fly international than across the US. Flight times are around six to ten hours depending on location.
You can't just hire and fire!
People are generally on one-month contracts, this means recruiting can take two months (one month to advertise the position and arrange interviews another as the new recruit works out his notice). Getting rid of staff can be a legal minefield if you don't know what you're doing - so hire a local manager you trust and who knows what he's doing.
Time zone differences can be godsend and a nightmare. If you on the East coast then there is at least a 3-hour overlap with Belfast. Actually it's better than this because people on the east coast come in early. On the west cost there is very little if any overlap and this is compounded by California coming in late to the office. In my case working to 12pm my time on a regular basis, always having my cell phone switched on and offering reciprocal time to the staff working outside normal office hours resolved my problems.
As someone already pointed out the time zone difference can be used to your advantage if the task can be broken down to day sized chunks. This allows you to pass the project from one team to the other at the end of each working day. Personally I have only found this to work for bug fixes.
All parties need to be fully aware that it is important to accurately communicate the status of a task at the end of each working day. The number of times I came in to find an email detailing a critical problem but not providing all the information was incredible. In this situation I either had to waste time by exploring multiple possibilities or wait for my colleague to arrive for work in the states before committing resources wasting valuable time.
Good quality email, voice and Internet connection are essential especially if you go for a centralised source control system. Downtime on any of these systems is a killer.
Get voicemail at all sites, provide staff with cell phones.