In the past decade or so, multi-national corporations have taken to diverting many of their customer service hotlines to Bangalore and other metropolitan centers in India, primarily as a ”cost-saving measure.“ Yet they’re perpetrating a greater injustice than simply annoying their customers to save a few cents. By giving their distant call center operators little training and even less authority to help customers — as most of them, with a few notable exceptions, seem to do — they’ve left many Westerners with an unfair impression of India as a pool of labor that, while presumably cheap, is apparently unskilled, apathetic, and awkward at communication.
Yet for the average Westerner to use this rather limited experience with “Indian outsourcing” to make inferences about the broader Indian labor market is as absurd as a Canadian making judgements about the entire American workforce based on the fast-food cashiers he might encounter at Interstate stops between Toronto and Pittsburgh. India is, after all, a country of one billion people, no more homogenous — and in many ways less so — than the United States.
My own experience working with web development teams in India has not only controverted every one of the popular stereotypes, it has greatly improved the productivity and quality of the work that all of my companies are able to produce.
At my Ruby on Rails consulting firm, for example, we have been operating an office in New Delhi since last October, supplementing our base in Boston. I decided to hire my New Delhi team after working with them on a one-off project and being very impressed by their work.
Anyone who cares about crafting good software should bear the vast pool of talent available in India in mind when assembling a team of developers. I’m not advocating favoring any one nation, but merely that we should decide to work with people without respect to the flag that flies over their heads. Moreover, I’ll grant that working with the Indian IT industry requires some care and a bit of cross-cultural sensitivity. But I can attest that the rewards are considerable for web entrepreneurs and project managers who are willing to learn to navigate this new trans-Pacific trade route.
Concerns and fears
First, just to get it out of the way, malcontents of various industries will inevitably surface the old poujadist complaints about “shipping jobs over seas” whenever the prospect of working with offshore companies comes up. The title of a recent book targeted at software developers says it all: My Job Went to India (And All I Got Was This Lousy Book): 52 Ways to Save Your Job. There is nothing new in this. In the late 1600s, London silk weavers staged riots and were known to rampage through the streets, tearing the clothes off women who were wearing cheap printed textiles imported by the East India Company.
But people who oppose outsourcing never seem to learn what every empirically-minded first-year economics major knows: unrestricted trade across international boundaries makes life better for everybody in the end. The Western companies who employ either firms in India or US firms who employ Indian workers are often able to get more work done, more efficiently and cost-effectively than they might otherwise.
Other typical concerns are of a more practical, rather than political, nature: for example, that communication will be difficult, that it will be impossible to select a reliable team, and so on. But a little bit of attention to the peculiarities of the Indian software industry and its ways of doing business will help avert the (admittedly real) potential problems that lie behind such concerns.
Why go abroad?
As usual, one need look no further than Techcrunch for a distillation of Web 2.0 conventional wisdom on the subject:
Something that you don’t often see a lot written about in new media is the strong trend by startups to outsource a lot of their work. Digg for example was originally designed by Kevin Rose outsourcing the job on elance, and sites such as Slideshare [and] illumobile.com have gone down a similar path.
Naturally it’s a cost thing. I spoke to one startup CEO last year who hired five programmers in India who had PhD level qualifications for $45,000 a year each.
But while cost is an advantage that many Indian teams can offer — especially when it’s a question of lower-skilled services like data-entry and back-office work — I think that putting a focus on price in this way detracts from the true value of looking for a team without respect to international boundaries.
In fact, the reason I originally found myself looking to India was necessity rather than parsimony. I was exasperated trying to find a good Rails consulting team to help out with a start-up I was working on at the time. Over a period of several months, I hired quite a range of developers to help me out with various tasks: well-known “rock stars” in the Rails world, little-known but highly proficient and affordable indie guys, low-priced American firms who had only recently switched to Rails from other technologies, and finally the team in India.
The worst work came from the “famous” firm, who were charging us nearly $150 USD per hour yet would regularly take two weeks to reply to one-line emails. We were largely ignored, and whenever code was finally checked in, it was half-baked at best. The lower-priced firms in the US paid us more attention, but I didn’t get a sense of intellectual curiosity or expertise from most of them. One indie guy I hired in the US was amazingly talented and relatively affordable, but he simply didn’t have the hours I needed because he was also working a day job.
To my surprise, my best experience by far was with the team I hired in New Delhi. Not only did they fully grasp the principles of how to write good Ruby code, but they were lightening-fast responsive, good communicators, highly available, and enthusiastic. Given my past experiences, to find a team like that I wouldn’t have cared what they charged me. It was, therefore, all the more fascinating that the Indian team charged less per hour than most (but not all) of the developers I had hired in the US.
I uncovered in the process a number of other formidable advantages to an offshore arrangement.
Undeniable advantages
The first, and most significant, is actually related to the lower cost of living (and therefore labor) in India, but only as an ancillary point. Consider that when you’re a consulting firm with an expensive office in a large US city, along with having a payroll composed entirely of US full-time developers, you simply can’t afford to spend much time expanding your team’s skill set unless that work goes right into hours billable directly to a client. But when labor is more affordable, you can more easily make choices that favor increasing the skill and expertise of your team — things like being choosy about the client projects you accept in order to make sure every new project is an educational, as well as a profitable, experience.
Equally, you can allow your developers to spend spare non-billable time on interesting side projects that enhance their skills with new techniques and technologies, which also allows them to contribute to open-source. Although there are plenty of “software sweatshops” to be found in India (as well as the West), the more enlightened boutique firms often strongly encourage their employees to improve their skills rather than spending every second on client work, leveraging lower labor costs into greater expertise rather than raw dollars-to-lines-of-code output.
In practical terms, this meant that when I first hired the New Delhi team as contractors for my start-up, I immediately had someone who was an expert in Amazon Web Services, another who was a CSS guru, another who knew deployments in and out, someone else who knew all about building APIs in Ruby, and so on. I had access to a team with varied experiences and a vast repository of resulting expertise, which would have been very hard for most smaller American consulting firms to put together and retain on staff. They were also all available to work on my project part-time when I needed them, because they didn’t have the cost imperatives that push many Western firms to take on more work than they can handle, severely overworking and limiting the availability of their developers. With a well-run firm in India, you’re likely to get far more available time and attention than you would with a comparable firm that only has a local team.
Additionally, I found the team members were simply better educated in the full breadth of computer science and engineering than their counterparts in most web dev shops in the US. Most Indian software firms require at least a bachelor’s (and often post-graduate) degree. I don’t generally abide by the notion that formal education makes better programmers (sometimes the opposite is the case), but it’s hard denying the value of having folks around who can code a custom utility for you in C or .Net when necessary, based on having worked with those technologies at university. This has proved essential to us on more than one occasion.
I also found that my application immediately adopted a 24-hour development cycle when I began working with an Indian team. This workflow, sometimes referred to as “chasing the sun,” means that while you sleep in the West your dev team will work through the night on tasks you assign during the preceding day. This type of iterative daily (or at least weekly) cycle of work-and-critique fosters an agility in the development process that makes for a manifestly better application. In addition to the cycle of work and review, there is also an overlap in the morning (if you’re in the US) when both you and your team will likely be in the office at the same time, making real-time Campfire and Skype discussions possible. So you get the best of all possible worlds, especially if you’re into Getting Real: automatic alone time for your developers, iterative development, and the impetus to keep your meetings brief and action-oriented.
You’ll notice that none of these advantages is about hiring a developer at $20 an hour to churn out code mindlessly. It’s about looking for the best people without respect to international borders, finding a good workflow, and having a team that both cares about quality and has the logistics to support keeping that quality high.
I thus like to make a critical distinction between “outsourcing” and “offshoring.” Outsourcing is when one company hires another to perform some task because it doesn’t make sense (for whatever reason) to hire an employee to do internally. When I hire an accountant here in Massachusetts to do my taxes, I’m outsourcing. Offshoring, however, is a subset of outsourcing, and it involves selecting an outsourced provider specifically on the basis of cost of labor differentials between countries (see “labor arbitrage”).
When it comes to skilled work like software engineering, savvy entrepreneurs ought to be interested in the efficiencies afforded by outsourcing, but in offshoring only insofar as not caring where a provider is based means one can get better outsourced work.
Selecting a provider
The first criterion when selecting a firm is to figure out what type of client you are. Over time I’ve learned that there are three discrete types of web dev clients, and each one requires a different type of consulting arrangement if things are to go as smoothly as possible.
The first type are those who are planning on being very technically involved. These clients know their programming platform well enough to ask for very specific tasks, are able to assess the quality of the work at the code level when it comes back and are the ideal candidates for working directly with an Indian team — in direct communication with the developers working on the project, with only minimal (or in some cases no) management by a US consultant. This type of arrangement saves money, and the fact that the team and client will be able to speak the common language of code will allow them circumvent most potential cross-cultural and management issues.
The second type of clients are those who are comfortable working with a partly offshore team but who care more about the product and its functionality than the underlying technical details. We’ve found that these projects really need at least a part-time on-shore project manager, in addition to the one or more full-time developers in India. In arrangements like this, the project manager acts as a communications liaison and is the primary point of contact for the client. From the client perspective, this is basically like hiring an entirely domestic firm, but with the added benefit that they’ll likely get a lower overall hourly rate, along with a team that has the ability to give far more attention (and expertise) to the project. Trans-national project management is an emerging business skill — and a fairly particular one at that — and clients will benefit greatly if they hire a company that has already learned the ropes. This type of arrangement also gives client a local throat to choke, as it were, in case anything goes wrong.
The third type are those clients to whom outsourcing truly isn’t well suited. Clients in this situation actually turn out to be quite rare, but I have definitely encountered them. These clients usually have a very formative product idea and are counting on the developers/consultants to help them finalize their ideas in real-world brainstorming sessions and what are effectively on-site “hackfests.” I’ve spoken with start-ups like this in the past, and I’ve never hesitated in telling them that an off-site (to say nothing of off-shore) team is probably not the best for them.
Fighting harmony and avoiding “too good to be true”
The next two bits of advice for selecting a firm to work with are slightly counter-intuitive. They both stem from the fact that the Indian culture of business places tremendous emphasis on preserving the appearance of harmony. Indians are constitutionally loath to tell a client “no,” for fear of offending or causing embarrassment. There are a number of painfully subtle ways in which Indians may communicate “bad news” and “no” to each other within their professional culture, but they are unlikely to be detected by a Westerner. This means, especially if you’re talking directly to a provider in India, that you’ll get a lot of knee-jerk yes-saying, which you have to work hard to cut through and figure out what’s just harmony preservation and what’s really an enthusiastic affirmation. To that end, be wary of shops that claim expertise in everything; it’s best to find a firm that has built a reputation in one particular community or with one specific technology. It’s nice to have people who can do work here or there in related technologies, but when it comes to the core of your project, find folks who know your specific platform inside out.
This relates to my second bit of advice, which is to try to find the most expensive and accomplished provider possible. When you’re already saving money working with an offshore (or at least partly offshore) team, it’s very easy to get greedy and go for whoever bids the lowest rate. But if a team promises they’re going to give you great work for what sounds like an insanely cheap price (and, believe me, these folks aren’t hard to find), red flags should go up immediately; they probably have no idea what they’re doing. It took me a few bad experiences early on to learn this lesson, but it’s one I’ll never forget.
Two last canaries in the proverbial coal mine are firms that are run with a sweatshop mentality and firms that don’t contribute back to open-source. You don’t want a team that is driven too hard, working through nights and weekends for example, because this inevitably leads to a compromise in quality. A significant indicator of this is whether the firm allows its employees to blog. Because of the fairly fluid and competitive labor market in the IT world in India right now, many Indian employers don’t allow their developers to blog or make contributions to open-source, for fear of losing them to competitors who might contact them directly. And if an employer doesn’t permit his or her employees to contribute back to the platforms they work with on a daily basis, it means they’re probably more obsessed with billing every hour possible than in building up their team and technology.
Working with your provider
Although there are cross-cultural issues to consider when working with an Indian team — just as there would be for a British firm working with a French one — it’s worth observing that many of the issues that are likely to come up when working with an Indian team are common to all remote work. Don’t be too quick to blame miscommunications or collaboration glitches on trans-national issues. When people have a bad experience with a domestic firm, they rightly blame the firm, but if they have a had experience with an offshore firm, people are always quick to blame the country first. This is both irrational and unfair.
Most of the issues for Westerners working with Indians revolve around this issue of yes-saying and the need to preserve the appearance of harmonious relations. Most American entrepreneurs are (quite rightly) accustomed to saying what they think, being challenged by contractors and subordinates, and doing the same in reverse. Indians tend to be somewhat more reticent to express reservations openly about a plan that seems like a bad idea. So make sure you encourage push-back. Encourage your Indian partners to be what they would call “extremely blunt.” Lest you should fear this is encouraging rudeness, rest assured that “blunt” on the Indian scale often equates to what most American start-up entrepreneurs would regard as fairly deferent and polite.
When you start to assign tasks to a provider that you’re not used to working with, you should ask him or her to re-state the task back to you. It is not uncommon for Indian workers to say they’ve understood something even though they haven’t because they don’t want to suggest that the speaker hasn’t explained himself properly. The provider will then go confer among colleagues and try to figure out the request, rather than putting the questions they have to the person who actually assigned the task. You should always verify that your requests have been understood clearly and let your provider know very clearly that you won’t be offended if clarification is requested.
Another useful piece of advice is try to have individual conversations with your providers. Because of the need to preserve harmony, multi-person meetings (or conference calls) become rife with peril for the Indian employee. Not only do they have to worry about offending the client, but also saying something that might offend their bosses. To encourage frankness, it’s best to limit the number of people involved in the conversation and either go directly to the supervisor or directly to the person doing the work, not both at the same time.
I have cribbed much of this advice Craig Storti’s excellent Speaking of India, which details these cross-cultural differences very astutely, while simultaneously managing not to resort to single-minded stereotypes. I highly recommend that book for those considering working regularly with Indian providers. Becoming aware of these cultural differences makes one realize that some behaviors which can at first come off as incompotence — or even malevolence — are often due to insidious cross-cultural differences. What’s worse is that these differences often go ignored by both parties because of the illusion of shared culture created by a common language.
To be sure, finding and working with a good Indian team takes a bit of work and some cultural flexibility, but if my experience is at all indicative, it can be more than worth the effort — and not nearly as frustrating or scary as one might think.
Resources
Elance, oDesk, and Guru are good starting points for finding providers in India.
Speaking of India: Bridging the Communication Gap When Working with Indians, Doing Business in India, and The Black Book of Outsourcing are all wonderful books on doing business with Indian partners. For guidance on outsourcing in contexts beyond web and software development, see my article series at 43folders.
For a bit of comic relief, see Sandeep Sood’s Doubtsourcing, an excerpt of which I included in the article, with Mr. Sood’s permission.
