Slashdot Mirror
Managing a Global Programming Team?
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?"
For the love of God, DO NOT DO IT! I've worked with or interviewed for positions at 3 different companies/departments that used off-shore india programmers. It was always a horrible experience. In each situation, after 6 months they said that hiring the offshore team actually hurt progress. That is to say, X programmers on site would have made more progress than X on site and Y offsite.
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.
But, as has been pointed out here already, there are thousands and thousands of US developers out of work, which makes it a buyer's market. To put it into perspective, a top-gun Russian developer is going to charge 25/hr. I am certain that you can find a comparable US developer right now to do it for approximately the same; plus or minus 10% or so. It's amazing, but even software developers like to pay their mortgage... ;-)
My company has hired "off-shore" programmers, however we have always brought them in. You tend to get a really good rate even bringing them in (much cheaper than typical $200/hr consultants.. I think we pay around $40-80/hr for the off-shore ones), and I would wager that you would more than make up for it in the problems that would arise doing off-shore. The other thing with bringing them to where you are is, they tend to be more willing to work (what else are they going to do, hang out in the hotel?).
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.
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:
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.
Sailing over the event horizon
In the company where I work we have a partner in India that we can outsource to.
A few important rules do apply.
1) Projects should be of a fairly large size. Don't try to outsource a small part of a project.
2) Be precise in you specifications. We typically document and develop the architecture and design of the system together with management consultants and our customer.
3) Send you architect to India. When your architect (or lead programmer) has got a firm grip of the project, send him to the development team in India. You may loose a lot if you try to do everything by email, notes etc. You don't need to move project managers etc, but architecture is critical.
4) Make sure the outsourced parts can be boxed. I.e. develop in components, and specify and test each component individually. This should be done in most projects, but when you outsource, keep focused on splitting down the project in small (and easy to solve) components.
We work with a partner company in India. This provides us with project management of the remote team. It might be difficult if you try to have freelancers spread over a large area. Try to take contact to one or more companies over there and establish control of the project that way.
Many comments are about the language. We have not had many problems with that. The employees we work with in India are all fairly good to speak and read English, and I think that goes for most Indian programmers. That will be solved, as you will be able to determine their language skills when you talk (or write) to them.
In regards to tools there are many. Most of our contact is done by email, word documents etc... The issue about managing the versions of source code require tools, but there are a lot of good tools out there. The most important rule is to define the handling, updating and deployment of code. (Did I mention you should build often?)
When outsourcing don't underestimate the importance of quality control (testing etc...).
Hope it gave you some ideas.
-:) Oh no - not again.
www.rednebula.com
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. 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 or The Wall Street Journal) 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, 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:
Canada has highly talented and educated programmers. Many of them, like myself, back from stints in the Bay area.
The price is right. Typical rates for Canadian consultants are 10 - 20% discount on US rates and then discount a dollar that only worth $0.65 US. No time zone issues or language barriers. Frankly, I don't understand why a US company would consider going anywhere else.
- Tune in next time for.. a clever sig.
now we need to go OSS in diesel cars
These come from my experiences working with Indian programmers off-site. I am making no claims wrt Indian programmers on-site at your location as, in my experience, things work much better in that case. Furthermore, I am not saying Indian programmers are useless, only that the culture and language barriers make them much less productive than on-site developers.
Assuming you have four people including yourself on-site and, say, four developers in India, you will need to dedicate at least one of your developers (probably you) to managing the Indian programmers. This will be a full-time position. You probably will not do this and as a result, the productivity of the four Indian programmers will be approximately that of ONE of your on-site developers, and that is optimistic.
With a person full-time on managing the Indian programmers (and please note, an Indian manager in India is not the same), you will find that the four Indian programmers can develop at the rate of two to three of your on-site developers. This is because, in my experience, they are never willing to work overtime and also, because of the rather extreme language barriers, infrastructure problems, and culture differences.
Note that you will likely also need someone to do design for this project and furthermore, the design for the code you are shipping out to the developers in India need to be much more detailed than that you give to your on-site developers. In my experience, this can only be done on-site.
Add in a manager as you have a team of eight and you are now looking at:
- One manager
- One liason with the Indian programmers
- One (or two) designers
- One (or zero) local developers
- Four Indian developers, producing approximately 2 - 3 on-site developers' worth of code (and no design)
So your eight person team will be, optimistically, as productive as a four-man local team. Pessimistically, they will be half as productive.
You are likely to become slightly more productive with eight Indian developers and four local people.
For every four developers, you need one full-time person locally to do detailed design documents. For every eight or so people on your team, you need a manager. And you need one person solely managing the off-shore developers, assuming you keep their number down to reasonable numbers.
That means that with three local people and four Indian developers, you will achieve roughly the productivity of two local developers.
With four local people and eight Indian developers, you will achieve roughly the productivity of five local developers.
With five local people and 12 Indian developers, you get productivity of approximately 7 local developers.
It is rarely worth it to do development like this.
Oceania has always been at war with Eastasia.
Having done several of these, as your first project, with deep pockets and a compressed do date, you are going to have problems. Major, miss the date, lose your job type problems if you attempt to remote source it.
Oversea outsourcing has problems beyond the traditional remote support. I have and continue to be a strong proponent of remote support. You get the benefit of hiring expertise that may not want to locate near you. For example, I work remotely for clients where the cost of living is easily three times what I pay here. And they do not offer three times the compensation. It sounds like that is what you are after. A win-win.
Here are just some of the issues:
- Time zones are more than inconvenient. If a question does not get answered by 8 a.m. , it will sit until the next day. Picking up the phone sounds easy, but will not be. How many issues can pile up before the communication is complete or they stop asking and just begin assuming? Who gets to call meetings and who attends? As the person leading the project, are you ready to work day and night? Team, status, and planning meetings need to be held with everyone so when?
- Code is not code. Simply put, cultural differences create issues in code. If you wish to own the code when you are done, both parties need to understand what is acceptable standards and what will happen with code that needs to be reworked (do you still pay while they rewrite it?). Standards for names, fields, tables, access types, how and what type of inheritance is allowed, etc. Assuming they will be coding in English (yes, you do need to make it a requirement), unless you all agree (or they have worked extensively in the US), someone will be rewriting the code. Or you will need to look at it like generated code. It does the job, but you never want to maintain it.
- Cultures different. As Americans, we tend to be naive in the assumption of cultural neutrality. And while many organizations do their best to be neutral, language continues to be a barrier. Consider how difficult it can be to understand someone with a varied US dialect. Add the phone, email, and 5,000 miles and a simple statement "You wish the account number removed, no?" takes on a whole new meaning. My unscientific number of 30 -40% redundant communication will work to minimize these types of issues.
Some companies put an American in charge from your side. You work through them and they make sure the details get hammered out with the team. This helps a little, but sounds a lot better than it works in practice. I was approached by a company to have mine work as that front. I passed when I saw the only difference was I would now have all the issues the client had, plus my own.
- What if it fails? This is the one that can be a stickler. Suppose you are being told that your project is on schedule and all the areas are coming together. The status reports look good and the code is getting delivered right up to the point everything stops. What are you going to do? While this problem exists in many contractor type arrangements, these folks are overseas in a country where use of the legal system is unknown. I hate to say it, but at least here you can sue someone if for nothing else but to get the code that was created.
At this point, I foresee a number of people reaching for the "reply - he's a bigot button." Hardly. These are business decisions and people make them from the cost/benefit. Often the price appears cheaper, because the assumption is made that given any programmer "X" they will generate lines of code "Y" and the result will be the same. That is not the case and is simple as the difference between hiring a person out of school and one with 10 years experience. The both know C++ so the results will be the same, correct?
Finally, consider the current economy. You did not say where you are, but I am willing to bet you could get the project staffed locally (or even US remote) for less TCO than you think. If they insist you use off shore help, then research carefully and find out the number of oversea projects done by the firm managed from the US. Of that total, how many were on time and on budget when complete. Then contact those customers and get their input. If their references are not glowing consider what the unhappy customers would be saying.
You may be the one that kicks the trend. However, I would be careful about putting your career on the line for it.
Imagine people dying in the streets because they can't afford to go to the hospital, like the rich people that farmed jobs out to Banglna-fucking-desh.
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.
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.
I'd like to send a big "Fuck You" to your company.
Simple question. Why? America has done more than any other to usher in the era of glabal markets and global business. Someone in India offers the service for less cost, then I say all credit to them. America delegates almost all manual labour to the far east - where are your clothes made? Now they are handing out contracts for skilled work, and because many asian contries have excellent numerate education they are kicking ass. The same will happen in russia when it gets in gear.
The Indian guys we shipped in at $ORK[-2]were a fuck of a lot better than me, and as good as most of the rest of the group. Bear in mind that this was in a research group where the average PhD count was still above one despite two secretaries and a student on work placement. These guys are for the most part _good++_. I don't know where your degree is from, but they probably have two. And cost half as much. Put yourself in the position of the manager - If the project is reasonably atomic and QC isn't going to be a problem then shipping out contracts is a no-brainer.
now watch _this_ get modded to shit.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994