9 Reasons Why Software Offshoring Won’t Work (and Why You Shouldn’t Believe Them)

Speaking as the head of a service provider, I’ll be frank: We often get CEOs coming to us saying, “We need to get started outsourcing offshore. We need to have an offshore strategy. But my VP of engineering is not on board with it. Can you convince him or her?”

I’d love to say, “Yes, we can.” However, if that VP is responsible for delivering a product, and he or she doesn’t want to do any of it offshore, it’s not going to happen. If your engineering team is putting out all the new features your clients want, answering all of your clients’ needs, continually helping your company add revenue, beating your competitors out the door with new features — and all within the existing budget — you don’t have anything to worry about. But if they’re not, maybe you should be worried about the reasons they give you for not offshoring or putting your development budget to better use. In this article, I share nine of the most common excuses you might hear for not offshoring — along with actions you can take to determine if it’s legitimate or not.

Excuse #1: “We can’t separate out the different parts of our system or application to give an offshore team something to work on.”

What this means: Dividing up the application is necessary so that the offshore service provider won’t have access to all of your source code. If it did, it increases the possibility of intellectual property theft — the service provider might steal your code.

Actions to take: Determine what your competitive advantage is. Is your source code your competitive advantage or is it your customer base or your process? If you answered your customer base or your process, you can feel more confident giving an offshore team access to your source code (while still taking steps to protect yourself as you should in any outsourcing situation, whether onshore or offshore). Your process and your customer base are much harder — if not impossible — to replicate unless your service provider sets up a sales and marketing and management structure similar to yours. If you answer that your source code is your competitive advantage, see Excuse #2.

As part of your discussion with your VP of engineering, you should understand that it’s almost always possible to assign pieces of development to a new team of developers. The instructions might state, for example, “This module will call this particular function, send this data to it, and get this data back.” The external developers should be able to write the code that will call this function, send this data and get this data back, without actually testing the execution of the real function. This approach limits access to your source code. Final testing then can be done onshore by your in-house team. There’s nothing wrong with this, particularly at the beginning, when you’re testing how the offshore team performs. Your engineering staff may refer to this as writing a “stub.”

Excuse #2: “They will steal our source code.”

What this means: The offshore service provider will start a competitive business on its own or sell our source code to our competitors.

Actions to take: If you’ve determined, based on Excuse #1, that your source code is your competitive advantage, then discuss with your management team the following:

  • The ease with which a new company can start selling to your market. Will others be able to start up from scratch to build a reputation? How many competitors do you have? Is this market so small that everyone knows each other? If so, it’ll be obvious when a new competitor surfaces.
  • Will they be able to sell your code to your competitors — such as in the SolidWorks Plus case in India? If your competitors are other domestic companies, would they buy it?
  • Can your outsourcing provider take your source code and start selling your product or providing a similar service in the market where the development is taking place? Is there even a market for what you do in that offshore location? Many offshore locations lack mature business markets that need high-end software, nor are they demanding it. Discuss the possibilities and risks upfront.

Explore steps to protect your intellectual property with your management team and your service provider. (The same can be followed even if you have your own office in another country.):

  • Find out if your service provider uses activity monitoring software, and whether someone actually monitors the reporting coming from the software.
  • Require that your source code be uploaded to a server in the US, your server, or to a server of the partner companies in your country, at a minimum of once a week — if not more often. This includes all code that is currently in the process of being written.
  • Inquire how intellectual property is viewed within the service provider’s company. Do they educate staff on intellectual property and how it should be protected? Does this include educating people on social engineering?
  • Ensure proper legal protection by assuring that your offshoring partner signs non-disclosure agreements (NDAs) directly with each of your team members and that you also sign NDAs directly with each of team members.

Excuse #3: “It takes too much time to explain to someone far away what we need to have done.”

What this means: Specifications for features, enhancements, etc., should be written down, defined, and diagramed so that the programmers know what to do.

Actions to take: Discuss with your VP of engineering how he or she handles training for new software engineers. That person needs be brought up to speed on existing code and the new features to be added to the code. Is it just an oral explanation and a few words about where to start looking — in what modules to start looking — in order to start making changes? Your new team can start in this same manner, even if it’s offshore, with the understanding that it will take no more time for those people to understand the application than it would for a new software engineer brought in-house. That new person would have to hunt around for a while in order to understand the structure of your application and to determine where to make changes, but eventually he or she would move up the learning curve. Oftentimes a good way to get new people started is to have them perform maintenance tasks, bug fixing and making small enhancements to the code. If you begin working with a new team in this manner, very detailed specifications won’t have to be done initially.

Make a rough estimate, together with your VP of Engineering, for each project in the pipeline; establish how much time it will take to write specifications vs. develop/test each project. Chances are none of them will be exactly equal in the time needed to write specifications vs. the time for development and testing of the final product. Alternatively, if no one in the company has time to write the specifications for each of the projects, this is work that could be done by an outside firm. Many of them have staff in the client countries as well and can bring a person into your organization to gather and write requirements.

Excuse #4: “We have to be working when the remote team is. We have to be up at the same time they are in order for this to work.”

What this means: The concern is that if we’re not working the same hours they are, they’re probably not really working.

Actions to take: Engage in a conversation with your VP of Engineering revolving around the following topics: Do you often answer questions every hour for your in-house software engineers? Does he or she trust them to work on their own, even with lingering questions? Few questions should stop a remote team in its tracks. The same is true with the in-house software engineers; they’re able to grasp concepts and move on and work on their own. In most cases, after proving themselves, offshore engineers will do the same thing — take initiative and show independence in their work.

I know people who think they have to be working at the same time as the offshore staff. I have managed remote teams for years, and I never do this. It defeats one of the major benefits of having a team working at opposite hours. It could be doing work while you sleep and vice versa. There could be testing going on in one location and writing code in the other — or writing requirements in one location and reviewing them in the other location. If you’re working opposite hours, you can always have results waiting for you in the morning. It also doesn’t wear you out. It’s not easy to keep an overnight schedule and still keep up with your family and personal obligations. The same goes for the offshore location: Don’t force the service provider people to overlap their entire work day with yours (unless, of course, it’s a call center and they’re supporting customers during the workday in your country). If you try, you’ll lose a major advantage.

Excuse #5: “We need a special person to manage offshore.”

What this means: Managing remote people requires effort and special skills.

Action to take: Managing remote resources, no matter where they’re located, takes extra work. A rule of thumb I see is that for each team of five people working offshore on two different projects, somebody will need to dedicate about eight hours a week to managing that effort — writing specifications, checking in daily with the team, monitoring their progress, answering questions, assigning tasks, and so on. At 25 to 30 people, it may take one person full-time to work with this team, depending on how many individual projects they’re working on. It may end up that the best solution for your company is to have another member of your in-house team and not the VP of engineering communicate daily with the offshore team, write specifications for them, answer questions and fully engage them in your development process.

If in-house resources are stretched thin, another option might be to have your service provider manage the offshore team, doing all of the interface work. The downside of this approach, of course, is that you lose oversight of daily governance . If you do start this way, plan with your service provider a path towards your company eventually taking over the interface role with your offshore team.

Excuse #6: “We don’t have anyone in the company from that country, therefore we won’t be able to relate to or work well with an offshore team from there.”

What this means: Only people from the same country can relate to each other and successfully work together.

Actions to take: Engage in a discussion with your VP of engineering and ask the following: “Why do you think this is a requirement?” The most common answers are: “Because they won’t be able to understand the nuances of what we’re asking them to do,” or “It’s better to have a native speaker of a language speaking to another native speaker.”

While being from the same country has its upside, it doesn’t guarantee success. In our experience if you don’t speak the same native language, you won’t take communications for granted. You’ll work harder at reducing misunderstandings. If the onshore and offshore staff members are from the same country, oftentimes more assumptions are made about the type of work to be done and the expectations.

I’ve also seen occurrences of “us vs. them” syndrome when the onshore manager or coordinator is from the same country as the offshore team (“us” being everyone from that country and “them” being everyone else in the company. These “situations can lead to the offshore team not integrating into the company, their work not being seen as important or visible enough, and more difficulties surfacing in trying to roll out more work to the offshore location from other parts of the company. So while it can be helpful to have people on both sides who speak the same language, it should not be a requirement for getting started offshoring; it can bring as much downside as upside.

Excuse #7: “We’re not mature enough.”

What this means: Sometimes it means we don’t have anything written down — no specifications, no definition or structural details of our application; sometimes it means our code isn’t solid enough; sometimes it simply means we don’t know what we want to outsource yet.

Actions to take: If you hear this from your VP of engineering, always ask what he or she means. Engage in a working session with that person as well as the rest of the management team and determine what the issues really are. You may find that — for some of their concerns — you already have answers by virtue of some of the other topics already discussed in this article.

If the sense is that “We’re not mature enough,” or “Our code isn’t solid enough,” look at where the internal group is with its software development lifecycle. If your team is currently in the middle of putting out a new release and it’s all-hands in, the plan is going well and the existing team will get the new release out on time, it’s actually a good time to get started with an offshore team. Why? Because it’ll take them time to get up to speed on your system. They can be ready to start doing real work by the time the final release is delivered and you need to start supporting the current release and planning the next one. Waiting until you put out the new release and you have to support the existing release and start working on the next one will mean, once again, that your team won’t have enough time to better plan their work with an offshore team. That could result in it being put off again. It might be better to brainstorm how you can get started within your current situation and how an offshore team can be used for the long term.

A sense that the team isn’t mature enough and doesn’t have the structure of the applications written down (and that it would take a long time for someone to learn) is a typical issue in many companies. Coding typically begins before a design is fully written down; or if the product was defined in detail initially, as client validation goes on, it tends to morph faster than the documentation. A good first task for your offshore team could be to have it define the structure of your current application. If the team has experienced programmers, they’re used to diving into code and finding out how it works, what it’s meant to do, and how modules, libraries and databases are linked together. Having them write this down at the beginning is a good knowledge transfer process and will benefit both the offshore and onshore teams.

If your VP says he or she doesn’t know what to outsource yet, it may mean that person is compelled to define a special project to outsource and doesn’t have time to do it. If yours is like most companies, your firm has a number of projects waiting in the pipeline — special requests from clients, features you know you have to add in order to be competitive. In other words, there are probably more projects than you can possibly complete. When considering offshoring development work, especially that first project, it’s important to move carefully, but it’s also important to realize that it doesn’t have to be perfect.

We’ve started with some clients on small printer projects, lasting only a couple of weeks. Normally, we recommend that your first offshore project be at least a month long, to give you a good feel for the process and to test the skills of the offshore team. But if a month-long project isn’t available, start with the next best thing. Waiting for that perfect project will just postpone progress. Look for a project with the following aspects:

  • It isn’t mission critical.
  • It’s brief — four weeks or less.
  • It’s something you’ve been putting off, but that needs to get done.
  • It can be verbalized to the offshore company, which can then define the specs.

Excuse #8: “Let’s support the workers in our own country.”

What this means: Offshoring only helps the offshore location and won’t help us.

Actions to take: This is a sensitive issue and needs to be discussed openly. In part, whether or not this question arises — and to what extent it arises — will depend on the culture of the company. Are we open to working with resources no matter where they’re located? It’s a good opportunity to engage in a frank discussion with management about what is necessary for the growth of the organization. If your competitors are working offshore and are able to do more with their development budgets, then find out from your staff what they would like to do in order to be able to compete. Their answers and involvement in a solution can be extremely helpful. In the end, if you all decide that offshoring is best for your company, team members will be more on-board with the decision and not fighting every step of the way. This particular conversation can do a lot to open you up to other options and eliminate unnecessary speculation and worry for your staff.

Excuse #9: “I don’t want an offshore location responsible for applications that need to go in to production here in our own country without having someone in-house who can also work on them in a pinch.”

What this means: As a business supporting clients who are using your product or service on a daily basis, usually 24 hours a day, you will, no doubt, need first-line technical support to slap down critical bugs found in the system.

Action to take: Discuss options with your VP of engineering and other personnel engaged in serving your clients and developing the product. Possibilities include:

  • Having people in-house who handle this critical product work. It may be engineers who solely work with clients and also know the code.
  • Having the service provider provide onshore resources for this work, either in person, on demand or as an offshore resource that works your domestic hours.
  • Ensuring that you have a technical support communications plan with such information as the types of situations in which someone must be contacted offshore, who will be contacted, and by what means they’ll be contacted; the period by which the offshore person has to respond to the critical message; and how they’ll begin working on the problem — whether from a home computer or back at the office.

It’s Your Call

Ultimately, a variety of factors go into the decision to take application development offshore. You’re not the first executive to have to deal with leading your company through strategic change. CEOs trying to implement ERP systems deal with many of these same issues. Change can be difficult and isn’t always welcome. If, after evaluating all aspects of the question, you decide this is the best decision for the firm, what you also have to decide is whether those around you are the right people to help you move the process forward.

Useful Links


Coverage of the SolidWorks case in India