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.

I can't help but wonder, however, if the new flush of starry-eyed social Web entrepreneurs, intoxicated by a desire to follow the gilded paths of companies like MySpace, Facebook, Match.com, and YouTube, are aware of some awkward truths at the heart of the social business model.

My own, admittedly rather niche, social networking company (the first personals site for relationship-minded gay men,) has been going for two years now. If Lovetastic has taught me anything in that time, it is this: social networks aren't like other Web applications. Social networks can have tremendous value, but they are not themselves "products" in any traditional sense, and they ought to be handled as the special case that they are.

Give me differentiation, or give me death.

As a general principle, the first businesses to define a new market tend to dominate that space as it grows. Unchallenged, Microsofts and Wal-marts will only grow larger with time. In most industries, however, countervailing market forces tend to cause fragmentation and specialization over time. Small niche companies seize territory by catering to a specific subset of users with specific passions.

This is one of the most aesthetically beneficial side-effects of capitalism: the success of a flavorless mass market generally breeds a host of creative, artistic, and specialized sub-markets. Communities of passionate users spring up. Competitors begin to focus on craftsmanship and taste to attract the more discriminating consumers, and the quality of all products in that realm tends to go up. Innovators like Amazon, 37signals, Tom Bihn, and Target have wrought great companies within existing industries out of this elemental economic drive. As the old Business 101 saw goes: differentiate or die.

In a market loomed over by great mountains like MySpace and Match.com, the path of generic mass appeal is now largely closed off to small social networking start-ups. So we would expect to see the same cascade of successful specialization in social networking that we would see in other industries. Except for one little problem. A paradox at the core of the social business model fundamentally breaks the otherwise universal economic mechanism that makes differentiation a valid business strategy.

The cupcake paradox and a taxonomy of Web applications

Nobody wants to be the only person to show up at a party. Not only does it make you look like a loser, but it undermines the whole point of going to a party in the first place. Nobody gives a damn how good the cupcakes are; if scarcely anybody shows up, your party is a failure. Equally, nobody goes to MySpace or Match for the cupcakes—or, to be more precise, the quality of the user experience. People flock there because that's where everyone else is.

The day that I launched Lovetastic, I knew I had built something that was totally different from any of the other trashy dating sites out there for gay men. It worked elegantly and intuitively; it was beautiful; it had a warm, welcoming aesthetic (in stark contrast to the harsh meat-market feel of our competitors;) and it didn't reduce its participants to a demeaning set of "stats." I thought surely guys would jump at the chance to be a part of something like what we were doing.

On launch day, I found that traffic was very strong, but hardly anybody was signing up. I literally got more e-mails from people saying "what a great site!" than I actually got sign-ups. Same for the following few days. So I decided to try an experiment. I put up a preview screen saying we were taking sign-ups and allowing customers to build their profiles, but I hid the page that allowed site visitors to browse other profiles. In this way, nobody was able to see how many (or, more accurately, how few) other members of the site there were at the time. The next day, sign-ups multiplied by several staggering orders of magnitude.

I learned from this experiment early on a lesson that would repeat itself for the next two years: a social network isn't a product as such. Rather, the product that a social network provides is access to a large pool of other people. Every social network, whether it be a subscription-based dating site or an advertising-funded general community, must grapple with this ineluctable fact. It's what makes the rules for social networks different from utility applications like Basecamp and BlinkSale.

If a new member signs up for Highrise today, she can use the application, put in some contacts, appreciate the app's interface and functionality directly and, if she likes it, leave a happy paying customer. Highrise with one customer is a product with one happy client who might just become an evangelist to others. On the other hand, a social network with one customer, even if it were infinitely better than MySpace in every regard, is a company with one bored and angry customer, which is to say: an utter failure. In the taxonomy of Web applications, social and utility applications are entirely different species.

Niche communities will inevitably form within a large social network as a function of its size, but the value of the network itself rests solely on the diversity and number of potential connections a person can make. This is the tragedy of the network effect. Attempting to address a niche from the outside — to provide an alternative to a large existing network — means you have to start at zero in a market where the only things that matter are numbers. If your objective is to use a social network slowly to build a business around a base of happy, paying customers who sincerely care about your product itself (probably the most noble goal in all of business), then, sadly, you're doomed from the outset.

A race for numbers

And herein lies the tragic paradox for the social networking start-up. If you can't compete on quality, simplicity, beauty, or ease-of-use, you have to compete on numbers, which often translates to costly advertising and PR. It's a race to see who can gather and sustain the largest party. This is why the largest social networks are fetching absurd amounts of investment capital, overshadowing the thousands of floundering competitors futilely attempting to climb the lop-sided distribution that characterizes the traffic of social networks.

As of April 2007, MySpace got 80% of social networking traffic, Facebook just over 10%, and the other top ten social networking sites each hover around only 1% each, and the curve only drops way off from there. The thing about large numbers, of course, is that they are incredibly expensive to gather all at once. It's a very long tail indeed, and it's going to take any would-be competitor a pretty penny in Google Adwords to climb it.

Now that we have thousands of members instead of none at Lovetastic, people aren't quite so reticent to put up a profile as they were when I first conducted my early experiment. But we're still many times smaller than our much larger (and, I would argue, more distasteful) mass-market competitors. We have focused on quality and philosophy rather than building huge numbers fast. Yet we have noted the unfortunate fact that this often leads to a "leaky bucket." People may sign up, they may love the site, they may write us nice letters telling us what a refreshing and wonderful concept it is, but they often also write a month later to ask us to cancel their account because there just isn't enough people on the site "yet."

At Lovetastic, we make some decent money on the sale of what are essentially premium accounts, but in order to keep our numbers-hungry community happy, we have to keep pouring that money back into costly publicity and ads. It's a vicious circle, and quite frustrating to the entrepreneur who is reluctant to either go into a pit of advertising and publicity debt or to sell out to a larger company who can leverage existing access to the target market and drive them to the site.

To compete with a large competitor like MySpace or Match, you have to differentiate and target a smaller niche. But to be a successful social network you have gather as huge and broad a group of people as possible. The two business needs are fundamentally at odds with each other.

And so what is one to do? Bemoan the death of social networking start-ups and let MySpace define the social landscape of the Internet in perpetuity? It's clear that if you want to build a Web application business around a traditional product model then utility apps are the way to go, but are social networks too much an uphill battle to be worth the time? Hardly.

Looking for value

I have always admired the willingness of the folks at 37signals to call out the naked emperors of the Internet. Jason Fried in particular has been reminding us for years that real business is about creating value, not just taking a gamble on a buy-out. Their products are splendid examples. And I agree. So if we're going to take creating a social network seriously, we must do it with a full awareness of all the dangers I've mentioned here. If it's going to be hard to build a water-tight bucket, as it were, without constantly outlaying cash, spamming like crazy, or being absorbed into a larger company, we need to ask precisely what the value is we're trying to create, and whether it's worth surmounting the obstacles that lie in our path.

Value, of course, can be defined in many ways. (Merely planning to sell your company to a bigger sucker is not one one of these ways.) The most obvious perhaps is actually making money. Corkd is very interesting in this regard. They've figured out that a social network around wine will generate affiliate commissions on wine sales, with the added advantage that oenophiles have strong real-world social ties, which help to spread the word about the site organically.

An example of practical product-style value can be found Kevin Rose's new social network Pownce. It layers useful collaborative software functionality on top of the social component in a way that de-emphasizes making new connections and puts the focus on the ways it empowers you to interact with your existing friends (see also Twitter.)

But there are other forms of value, too. Many social networks like Zaadz, MakeMeSustainable and my own were created to address what we saw as social problems. We wanted to give people more socially responsible and personally fulfilling alternatives. In some sense, our very existence is to act as a critique of our major competitors and to empower our users to demand more of the mainstream sites. Huge sites like Gay.com end up being forums for facilitating hook-ups, and at Lovetastic we wanted to offer something more holistic. I got to experience the value of that enterprise first-hand in a way I could never have imagined when I started the company: I met the man who would become my husband on Lovetastic, something that would never have happened on one of the mainstream sites. And I've heard from many other members who have made similar connections. Working to make people's lives better carries its own sort of value.

But this sort of social critique is not entirely a non-business concern. Only recently, we've come around to the idea of potentially selling Lovetastic to another larger personals or media company. We set out to create something of an alternative site with an innovative, appealing interface. So we've realized that if our company goads our major competitors into doing things differently — including by buying and absorbing our site and philosophy into their organization — then we will have succeeded by our original criterion of rallying and serving an under-served niche market that we considered ourselves a part of. This kind of aspiration is different than having a single-minded devotion to getting big fast and selling hard. For companies that want to change the marketplace and create a different sort of value, I think this is as worthy a goal as any other.

My next project will be a utility app, partly for the reasons mentioned here. But I don't regret for a second what we're doing with Lovetastic or the time I will continue to spend on it. We're changing the topography of our little world, and there is plenty of value in that. But, notwithstanding the multi-million dollar headlines we keep seeing, I would caution any entrepreneur who believes social networking is the path to quick riches. It can be a rewarding, and ultimately market-transforming undertaking, but one ought to go into it fully aware of its peculiarities and perils and a clear vision for the precise kind of value one hopes to create.