Why Doesn’t Everyone Use Offshore Development

I’ve been working with offshore developers for many years and every time I meet a new person the conversation this question eventually comes up: If using offshore teams for building products provides so many benefits why doesn’t everyone use them instead of onsite developers?

So, why doesn’t everyone use offshore for software development? There are many reasons and the main ones are:

• Management concerns
• Quality concerns
• Language barriers and communication issues
• Culture gap
• Time difference
• Domain knowledge

Management concerns

Managing outsourced development is a skill, and it’s a skill that most companies and manager do not have. Managers who micromanage their employees may find it difficult to control a team abroad.

For a long time, I worked in the company ran by people who believed that if an engineer is working remotely, he or she is simply watching TV or browsing Facebook. At one point they even banned headphones because they thought that the engineers were listening to the radio instead of working.

These managers confuse time spent at the workplace with the amount of work done. I always use the final result as a measure of productivity instead of the number of hours billed. If the developer does quality work in the time expected, I do not really care how much time the developer spent – 2 hours or 10.

Micromanagement is the worst possible way of managing employees. Good people leave when treated like children and companies left with below average staff as a result.

Quality concerns

The concern about the quality of work produced is the main reason why companies hesitate to work with offshore development teams. It seems that everyone has a friend who has utilized offshore development team, and it didn’t work.

I can tell a similar story based on own experience too. The company I worked for decided to hire a team from another country in order to expand the local team. The primary reason for this decision was that we needed several dozens of engineers quick and the company wanted to do it as cheap as possible.

The leadership had experience with offshore before and they came up as they thought with an excellent solution. The vendor they hired promised to provide one onsite developer for each offsite one.

While the onsite developers were not bad, the ones that worked abroad were people who quickly learned to code in some boot camps. They didn’t have any real experience building software and they were brought in to add features to the existing system.

I understand why the vendor hired cheapest (worst) engineers offshore – it was the only way for them to make money because they had to pay US salary for onsite developers, but I was not happy about it. As a senior engineer I spent more time reviewing and fixing code made by those junior devs instead of adding value to the product.

Language barriers and communication issues

When I interview offshore developers the first thing I assess is their proficiency in English.

I am not expecting a lack of foreign accent, but if during the interview it takes several minutes for the engineer to explain simple things because he or she is trying to recall proper words to describe the problem, I automatically reject this individual regardless his/her technical skills.

Communication is hard enough when there is no face to face interaction, and you don’t want to make it harder by hiring someone who simply cannot understand exactly what you are saying.

I’d like to note that language is generally not a problem when interviewing candidates from the Philippines; they speak English very well, some of them even with North American accent.

By the way, the best design documents I’ve seen were from a guy who lived in Ireland and worked with our company in the US. He really understood that he needed to compensate for the lack of face to face communication by providing very detailed documents.

Culture gap

People in different countries have different life experiences. What we take for granted as common knowledge over here maybe not so common in another country.

For example, in the US we have a strong tipping culture and we always tip in restaurants which is not a case if many countries were waiters work for a salary. And if you are developing a POS software for restaurants things like this can impact the software design and implementation.

Another example is a habit of not questioning the authority in some Asian cultures.

I remember my boss told me how during one of his trips overseas he presented some solutions and invited engineers to challenge his problem-solving approach. And although some people may be didn’t agree with him internally none of them said a single word.

People in North America used to speak up, especially in IT companies, because we believe this drives innovation and can help to come up with creative solutions to various problems. Fortunately, this problem is generally not a case with East European offshore developers. Some of them may even try to teach how you should run your business, LOL

Domain knowledge

A large piece of delivering value to a business as a developer is knowing what to build, not just how to build. The entire team including developers, business analysts, QA and a product owners will sit together in the same office when discussing the product requirements.

Some startups require all their employees to spend several days in different departments, especially in customer service. The advantage of this approach is to make sure that developers understand customers pains which at the end results in a better product. This goal is harder to achieve with offshore developers who are generally isolated from customer problems.

If the development team isn’t able to understand the product requirements in the context of the customers’ problems being solved the only way to work with those team members is micro-managing and providing a lot of documentation.

Time difference

This can work for or against you, depending on what you want. Some companies like the fact the software is being built in multiple shifts – when we sleep, someone on another side of the globe is cranking the code.

On the flip side, one of the most frequently stated advantages of having in-house developers is that they can immediately react to any fire, they are always within reach, you can discuss everything face to face. It’s much easier to arrange a conference call when everyone is in the same time zone and working during the same window of time.

The last thing you want to tell your customer is that the only person who knows how to restore your database is not available during work hours.

I always suggest having some overlap in work hours between an onsite and offshore teams. While it is somewhat hard to achieve with people living in Asia, it is possible to have at least 4 hours overlap with East Europe. And being in the same time zone is the biggest advantage for teams from Latin America.

Finally, offshore development is not a right fit for every company

In the area I live, the majority of technology companies have government contracts and it means that the developers in those companies in most cases must be US citizens, preferably with security clearances.

Also, most small companies who have modest development needs can always find one or two developers locally. It wouldn’t make sense to switch to offshore because savings on 2 people are not as high when hiring a dozen.

In conclusion, I’d like to say that offshore development can work, if done properly. Over the past few years, I have built up a team of good, dependable developers in the Philippines. I’ve done this by working closely with the team, training them when needed, learning how and when to delegate tasks, and generally spending a lot of time communicating.

There are good and bad offshore programmers just like there are good and bad programmers in the US. However, I heard a lot of good things about the quality of offshore developers in Eastern Europe, Latin America, and the Philippines.

And finally, we all used to associate quality with the price. Higher the price higher the quality we think.

But nobody believes that a programmer in Silicon Valley is automatically better than any programmer in Arizona because the former makes 50% more than the latter. Everyone understands that the salaries in Silicon Valley higher because of the cost of living in California.

Same applies to talents from other countries: salaries lower there because their expenses are lower too. The trick is in pursuing savings on labor is to pay their version of market salary (or above) for your international team.

Related Questions

Why It Is So Hard to Trust Your Offshore Development Team?

Trust has always been a big problem in any business relationship. If it is not easy to trust someone who looks like you, talks like and thinks like you, then it twice as hard to trust someone who does not behave the way you used to.

When I first moved to the United States, I had some stereotypical opinions about people in America. When talking to other engineers in our company I was shocked to find more things in common than I expected.

I came to the conclusion that people who share similar passions (programming, art, business, etc.) view the world in the same way. If you are a passionate programmer, you will be surprised that you will enjoy the time with another geek in another hemisphere more than a conversation with your neighbor which whom you have different interests.

It takes time to build trust.

Which countries are best for offshore development?

There are many countries famous for being outsourcing destinations: India, Philippines, Ukraine, Poland, Brazil, etc.

But this year I would recommend looking closely at Argentina. With Argentina, you get people working in the same or close time zone as your local team. The second reason is the inflation rate of 47% at the end of 2018 which was the highest the country recorded since 1991.

When I interviewed a number of engineers from Argentina last year most of them said that they were looking for work paid in USD because their currency was unstable.

And again, as I mentioned earlier, do not try to exploit the temporary financial problems and get good developers for cheap. I am just saying that you have an opportunity to find outstanding talent that otherwise would not be on the market and I would even suggest paying pre-inflation rates if you intend to keep those developers.

Images used: Whitaker, Christopher. “Safer Communities Hackathon at Google Chicago”. May 11, 2013. Online image. Flickr. Feb 18, 2019. https://www.flickr.com/photos/91210421@N03/8732379514/