There’s been a growing trend in American business to do software development offshore. Because, hey, money talks. When you’re looking at a 50% savings for what – on paper – will be the same product delivered in the same time frame, doing anything else seems foolish. Take the difference and invest it in a nice beach vacation, right?

In conversations that I’ve had recently with both friends and clients, however, I’ve detected a new bias against this thinking. Something has changed. I think it’s the result of years of experience that suggests the following: offshoring is good for some things but is terrible for new product development.

To be clear, those in the technical disciplines have always had a bias against offshoring, both because it interferes with their livelihood (which is a bad reason to hold the bias) and because it’s readily apparent to the ground-floor engineers how poor the results have always been (which is a great reason for the bias).

But now business managers are coming around to the same conclusions. In fact, I’d argue that it’s currently considered en vogue to keep all software development local – you can almost hear the snickers when a product manager boasts of his cost savings from using a dev shop in Bangalore. This is a huge driver behind the phenomenon of U.S.-based software engineers being snatched up at historically insane compensation levels.

Why does offshore software development fail? And if you’re forced to do it, how can you make it work out okay?

Why offshoring fails for software development

If we’re going to talk about how to make offshoring work, we have to first accept the reasons that it typically fails so miserably. Then we can compensate for each deficiency as much as possible.

#1 – Long iteration times

The most important reason for failed development by non-local teams is that iteration times are incredibly long compared to a local team.

Every other deficiency can be mitigated in some way. But not being able to sit side-by-side with your development team is a killer. Interactions that would happen in real-time and result in a 30-second feedback loop (“yep, the button should be on the right, but you’re right, it does look better four pixels higher”) are instead dragged out over hours or days.

If you’ve never experienced this, a good way to understand it is to imagine that you’re playing pin-the-tail-on-the-donkey with your business at stake. You take a look at where you think you’re going, put on a blindfold, and take a few steps forward before you need direction. Someone is yelling at you to turn left, turn right, go back, reach out your hand. You have to make a tradeoff – either take a very long time waiting for perfect information from the guy yelling at you, or get “close enough” to the target after a minute of stumbling around.

On the other hand, you can do it the easy way with your eyes open, utilizing the lightning fast feedback between your brain, your eyes, and your muscles. Bullseye – and it took you 3 seconds. If the project is important, you’d pay a lot to ditch the blindfold, right?

Someday, we might get to the point that telecommuting technology is sufficiently advanced that being remote is no different from being in the same room. But we aren’t there yet. Until that day, coordinating a complex project remotely is going to require a significant time-versus-quality tradeoff – so don’t do it unless you have to.

#2 – Cultural and language barriers

This is the most often discussed hurdle with offshoring. I feel that cultural barriers are a bigger deal than language barriers.

With any offshoring that’s done in a country different enough from your own, there will be cultural barriers that impede rapid understanding of requirements and the feedback loop. For example, I once used a team in eastern Europe on a significant project that spanned many months, and one of the chief disconnects was that the team didn’t hold to American norms regarding feedback to their superiors (in this case, me). They were overly deferential. They would see problems and politely mention them once or, sometimes, not at all, assuming that “the boss knows what he wants.” This had obvious drawbacks, as I was frequently blind to what was happening on the ground, and it took a lot of time and effort to correct.

(NOTE: Great blog post here about this exact issue. It backs up my own experience with some science-ish stuff.)

Secondarily, language barriers can be an issue, though this is infrequent. If you’re a U.S.-based business, it’s practically guaranteed that the remote team speaks your language well enough to get the job done. That said, I’ve had situations in which an engineer or two didn’t speak fluent English and required an intermediary, and this did slow things down considerably, but it’s fairly rare. You can also mitigate this problem with a very strong project manager on the ground in the remote country, who should be very fluent in your language and can cover for you in case of misunderstandings.

Which brings up a point of caution: if you’re talking to someone in sales or project management in a software firm and have any kind of communication difficulty whatsoever, RUN. It’s unlikely that the rest of the organization can communicate any better.

#3 – Time zone differences

This may or may not apply, depending upon where the remote team is located. Lots of work for U.S.-based companies is now being done by teams located within one or two time zones (Puerto Rico, Brazil, Argentina, etc.) – so-called “near-shoring.”

However, a very common case is for the team to be located more than 4 or 5 hours offset, sometimes as much as 8 or 10 hours. This can be a nightmare and contributes to (but is not the main driver behind) the long iteration time problem mentioned above – it can turn nearly every issue into a multi-day ordeal of swapped emails and late-night phone calls. Even if the team agrees to slightly shift their working schedule, you’re unlikely to get more than a few hours of overlap each day. This isn’t enough time to coordinate on a complex project.

“Yes, but… money!”

Alright. You’ve heard the reasons not to offshore your new product or complex IT project. Your sensible self is nodding in agreement. But then your teary-eyed wallet looks up at you and whimpers, “Remember me?”

Sometimes financial realities are the only realities. I get that. Just don’t say I didn’t warn you, and get ready for a rough ride.

Here are the things you can do to compensate (somewhat) for the problems I’ve listed above.

Start with a strong technical leader

Do not, I repeat, DO NOT move forward without having your own technical leader in-house. This will be something like a CTO, VP of tech, or senior consultant. He or she should have done this kind of thing before and will see all the potential traps that are waiting to swallow your project whole. You should find this person before you start an engagement with a software firm – in fact, you should find this person before you even start thinking through the project in detail.

I’ve written about the importance of this in a prior post. If you ignore this bit of advice, the rest of it doesn’t matter. You’re on your own.

Consider a strong product leader

You need to have someone who owns the product, and it should preferably be his or her only job for the duration. This could be the CTO, or the COO, or even the CEO, but whomever it is needs to be fully connected to the business needs and should block off more than half of every day for the project. If nobody can do that, then hire someone.

This person will be working side-by-side with your technical leader every single day to ensure that the product being built will match the needs of the business. If the work was being done locally, I could see an argument for going a little bit loosey-goosey with this. But the nature of remote work means that it will be even more important to catch misalignments early in the project cycle, to the point that I’d consider it critical to the success of the project.

Demand always-on telecommunication

During negotiations with the firm, get a commitment from them regarding telecommunication.

You should press for always-on video, voice, and chat channels. Ask that it be a requirement for every member of the team to be connected at all times – not just “available,” but literally connected in to a group channel that allows for instantaneous point-to-point connections by video or voice. This is the only way to approximate the feeling of an in-person collaborative environment.

Make sure that your project leaders are committed to being in those channels as well. They should be available at any time for questions from the engineering team. One- or two-hour delays aren’t acceptable here – it needs to feel like the engineer has walked into the business person’s cube to ask a quick question before ducking back to his own cube. That’s how business gets done in a local environment, and you want to replicate it as much as possible.

Ask for working hours that line up with your business

Also during negotiations, seek to have the engineering team line up their working hours with the business as much as possible. This goes hand-in-hand with the telecommuting requirements – it doesn’t do much good for all the engineers to be in a chat channel with one another while the business person is asleep.

You can nearly always get some movement from the software firm to shift their work days by 2 to 3 hours. This is practically a foregone conclusion for very remote firms trying to do business in the U.S.

But ask for more – see if you can negotiate at least 5 to 6 hours of overlapping work schedules. You might even offer to pay a little more for this if they’re highly resistant, but it will be well worth it.

Invest in automation

Since you’re starting behind the eight ball with your iteration speed, you need to do everything in your power to shrink your feedback loops.

One very concrete thing you can do in this regard is to invest heavily in automation of your development. This means putting significant engineering and IT time into build processes, deployment processes, ticket tracking systems, etc. Everything that can be automated should be.

Now, when an engineer breaks the build, she sees and fixes it immediately instead of waiting 24 hours for an email-based feedback loop involving your fingers and a migraine. Compound that kind of thing over 6, 12, or 24 months, and it can be the difference between shipping on time and shipping “someday.”

Be prepared for low quality or long timelines

In the end, despite your attempts to follow all of this advice, sending your project offshore is going to be less than ideal.

As the saying goes, you can choose two from “good,” “fast,” and “cheap” – and you’ve already chosen “cheap.” Decide whether you’ll be okay with a sub-standard product or significant delays, then go forward under that working assumption. You’ll be happier with the result if you expect it up front.

Other ideas?

If you’ve ever done offshoring, you might have other ideas about how to make it work that I haven’t mentioned. Please leave a comment or shoot me an email – I’m always eager to hear new ideas.