Outsourcing · Hiring engineers

Biggest Hurdles with Outsourced Development?

Marcus Siegel Product Design

February 24th, 2016

What do you think are the biggest challenges or drawbacks when outsourcing some or all of your development?

From my experience, here are a few:
- Lack of trust/authenticity (often times it's just a name behind an email, hard to build trust w/o more info)
- Lack of transparency (difficult to know what's being worked on and where you are in your dev schedule)
- Poor communication skills (not just language barriers but issues with concepts and terminology)

For context, I consult as a PM and sub-contract developers for startups moving from prototype to public launch. I have brought in local (SF) developers who are very expensive, as well as outsourced developers whose value is sometimes hampered by the issues listed above. I'm looking to build more structure and data into the outsourcing operation because the labor is around 25% local cost and I believe it could be much more valuable to US companies with the right improvements.

James Hipkin CEO, Managing Director at Red8 Interactive

February 24th, 2016

Love to chat with you about this. 

When I bought Red8 Interactive 5 years ago it had developers in China. The company provided dev resources to advertising and design agencies. I quickly realized that this wasn't working, for the reasons you already stated. But even though I live in the SF I couldn't justify the cost of developers. Plus they came with all kinds of attitude. 

I shut down the China team and built a new team in the midwest. High quality developers at a fraction of the West Coast cost, and no attitude. This solution also addressed your other concerns. 

I would be happy to share my experience with you.


Ajay Agrawal

February 24th, 2016




We are based in India and for the past several years have been working with project managers in USA, UK, Spain, Italy, France, Australia, Chile and Germany apart from India for repeat business.


Please allow me to present the views from my side of the table. I know that my utterances will not earn me any brownie points for getting new clients but we have our set of clients who are very happy with the way we are.


You have mentioned three (four actually) very vital ingredients for a successful outsourcing process.


Lack of trust:


From my personal experience, trust building activity is a two way street. It is equally important for the PM to invest sufficient time and effort to instill that trust in their chosen team. If you as the PM proceed with a positive thought process that your chosen team is trustworthy, more often than not, it will prove to be trustworthy. There are rotten apples everywhere, so be it in this domain as well. One has to learn to move on in a bad situation.


Lack of authenticity (often times it's just a name behind an email, hard to build trust w/o more info):


Just like in any other business, due diligence is mandatory before getting into a relationship, so it is here as well, and for both sides.

In our formative years, we got burnt because we did not do the necessary due diligence and delivered (or deployed the resources) for the project. Mid-way, the PM just disappeared without a trace and we were left holding the baby.

We learnt it the hard way and now proceed with utmost caution, keeping our financial exposure to the minimum in a manner that it is a viable proposition for both of us.



Lack of transparency (difficult to know what's being worked on and where you are in your dev schedule):


There are a plethora of tools available to monitor the status of the project. I don’t think this should be an issue at all to know where you are in the development schedule.

Though this comes with a caveat - the data being input by the developers is correct. I guess, any good PM should be able to spot fake status data very early in the cycle.



Poor communication skills (not just language barriers but issues with concepts and terminology):


This again is a two way street. Some PMs we have worked with have caused us immense grief.

I present my point through a very classic example of a driving instructor (read PM) sitting facing backwards and instructs the driver to take a left turn at an intersection. Having traveled a considerable distance after the left turn, the instructor says he meant his left and not our left!! Hence the candidate is failed in the driving test because he/she could not understand simple instructions.


In case the development team cannot understand the concepts and terminologies essential for the project, I think the blame lies equally with the PM who chose an inadequate team on the basis of cost alone. The power to choose a development team lies solely with the PM. One very good method to weed out the fake teams is to throw an odd ball requirement at a very lucrative offer during the discussions and if the team can refuse this offer by saying that they do not have the skill sets to deliver on this requirement, in all probabilities, that is the team that can deliver when they say that they can.



In my opinion, it is equally important for the PM too to see to it that each stakeholder is on the same page at the start of the project.


And that will be a major challenge.


If this can be ensured, half the battle is already won.


Ajay Agrawal

Adam Breen Digital Product Strategist at CPDone Pty Ltd

February 25th, 2016

I lived in Manila for about 12 months, and was instrumental in setting up our office there. I made pretty much all of the textbook mistakes you think you will avoid, but don't.

Some observations:
1. Cultural gap is a problem you will always need to solve for - which is actually the root cause of the communications issues you allude to. In any near-term timeframe, the lowest risk solution is to have a person in the offshore location with whom you are confident that you can communicate. As an Aussie, for me that meant a senior British BA with similar experience and shared values. You really want to pick someone who has lived in that location for at least 12 months, and has clear long-term plans to stay there, plus previous failures and more recent successes that you can leverage.

2. I'm not familiar with current SF rates, but I find 25% costs hard to swallow. The expectation of those sort of "cost savings" is endemic to the textbook mistakes that we made initially. The reality is that if you can make any significant cost savings, and achieve 1:1 output then you have found wage arbitrage that is worthwhile, provided you can deal with country and currency risk (pretty easy if you're in the USA). The best foreign operator I know in Manila gets 1:1 "velocity" (using a blended team), and typically saves up to 40%. Realistically, that's pretty damn awesome, and a much better mindset to approach offshoring with. Google "tanstaafl" for more insight :p

3. Your PM concerns are real. In the same way that a local consultancy is no silver bullet, neither is a cheaper one, in a different country, with a different culture, and probably a predominance of lower-skilled resources in the talent market. I always try to encourage my clients to think about projects from a Finance guy perspective: ie. if you're going to try to beat the market (which is what you are doing), you're going to have to do your goddamn homework better than the guys in the office next door. It's definitely worth it, but you're not just buying a gadget on eBay here. Give yourself a minimum 6 month ramp up time (and frankly, unless you're way cleverer than we were, you should be thinking 12 months, realistically).  Finding talent is going to be completely different to the processes that have worked for you, to date. It's incredibly important to develop an assessment framework that lets you maintain respect for your candidates and hires, despite your own personal frustrations. Managing the remote team will undoubtedly have a learning curve that you currently don't have any baseline for. But if you approach it as an R&D exercise initially, with an expected medium-term payoff, you can probably build a compelling financial model around the project that has a greater NPV than the local options. 

Good luck! What you're exploring is part of the future of work. If you're serious about it, there are good options in Asia, as well as Eastern Europe. Happy to jam on it with you sometime if you like - drop me a line.

Steve Owens Startup Expert

February 24th, 2016

Just as an FYI, we have never found the cost oversees to be any different than the US.  They often say they are charging a lower hourly rate, but it always seems to take many more hours to do the same task.  Over the years we have done many apples to apples comparisons, and the US always comes in about 10% cheaper.

From an economic theory point of view, this makes perfect sense, as arbitrages can not last for very long.  Markets determine price, not production cost.
Regardless, we use a lot of overseas resources, largely because they are good fit for what we need - but we also us a lot of US resources for exactly the same reason.

Jake Horn Principal, Founder at Volitas

February 25th, 2016

That's just it, business changes quickly these days.  I haven't done a project where the scope of work is clear and there isn't any ambiguity in requirements in about 15 years.  Clients typically don't know what they want, and they really don't know what is possible.  

Bartosz Nowicki Focused on delivering results at speed❢ Obsessed with creating applications that simply WORK❢

February 25th, 2016

This well-known cartoon shows it all http://www.sardiumservices.com/HowProjectsWork.jpg - most projects looks this way. You wait ages, pay a lot and at the end get something completely different than what you need.

Why it happens over and over again? Most companies never succeeded so they simply don't know how to build software. They'll hire anyone, just to fill the racks. Some nearly have to use electric shocks to drag their developers to their daily stand-ups ;) Very few have a recruitment process and hire only quality people.

There is a huge difference between an average consultant and a real software engineer. It's a mind-set difference. Software engineer thinks about building the SUCCESSFUL product that works. Consultant thinks about hacking something and then dumping it to the client, so it's not his problem anymore. In my experience easily 80% of people in software development falls into "hack it - dump it" category, which plays nicely with the statistics that show that 60% of Software Development projects fail.

How to solve it? You need a good development process, hire quality engineers and be eager to provide quality solutions.

If you'd like more information on that topic, we've addressed those issues in our report "Why software projects fail. Symptoms. Causes. Solutions.". Let me know if you'd like a copy - the website on which it will be available for download is not ready so I can't provide the URL yet.

We've also started publishing a series of posts on LinkedIn covering the topic: linkedin.com/pulse/you-part-failing-project-cezary-repecki?trk=prof-post and linkedin.com/pulse/you-part-failing-project-2-cezary-repecki?trk=prof-post

Justin Njoh IT Director - Mayfairworldwide, Lisol, teamable.co.uk

February 26th, 2016

Bartorz makes some very interesting observations which I totally agree with. With so many libraries and opportunities to cut and paste code, 'hacking' has almost become preferrable to the process of precision engineering that should be software development.

Marcus's follow up is particularly apt. In my experience, there is a huge difference between outsourcing for a start up, a small company and a large company. The margin of error for most startups and small companies is somewhere between zero and negligible compared to a large company.

As a small company making money, we made the huge mistake of outsoucing development. The quality of code from the first company was extremely poor. So when we moved to a second company, the first task was to try and clean up the mess left from the first. There was some marginal improvement in code quality. Needless to say, by the time we decided to end what had become a disaster of a situation the business had already suffered considerably and irretrievably.

The key lesson I came away with was that the outsource company did not have any material interest in the success of my business past the payment of their next monthly invoice. Of course, their literature emphasised how much their own growth depended on our success and blah blah blah, but this was not reflected in practice.

These were not small companies - they had (or boasted) hundreds of staff. However, staff turnover was a problem and there was no continuity with the people that worked on our product.

This has made me wonder if better outcomes for startups and smaller companies might be archieved in a scenario where the outsource company had an equity stake in the product, giving them a material reason to make sure that the client's product is successful.

I have since experienced other outsourcing situations and am satisfied that where the outsource company is based doesn't matter at all.

Steve Carlson Operations/Supply Chain Professional

February 24th, 2016

What I have seen as issues/drawbacks typically are due to a poorly written/incomplete SOW, with mutually understood comprehensive acceptance criteria. Agreed to timelines/phase gates, agreed to bug classification, scope change resolution and handling of cost overruns (with assignable cause) have all been problematic in my experiences. Accepting a name on an email instead of a relationship is unfortunate.   Outsourcing does not excuse the need for a strong relationship and strong program management on both sides.   I do believe outsourcing the right aspects of a design (including protection of IP) can be executed successfully in LCRs.  Best of Luck..steve

Naresh Nagarajan Advanced Analytics

February 24th, 2016

It depends on what you are outsourcing. Product engineering which involves rapid, agile, prototyping from UX to design and launch in 90 days are best done onshore. The project management should be split so that even where daily change in requirements from beta customers, custom Poc, core engg releases are triaged properly thro a CCB - Change Control Board. The CCB will help to triage must to have and nice to have so that the must to have requirements are correctly built into the patch releases that engg team or dev team will work on. UX should be outsourced not offshore but locally to a good design think and User Experience design firm. Program management should involve daily calls with

Jake Horn Principal, Founder at Volitas

February 25th, 2016

I have a colleague that is attempting the business model of providing what he terms as high quality offshore development services and he has found that he can't beat US prices in most markets.  He is now marketing his services based on the ability for teams to work at night while US folks sleep.  Most people have realized that outsourcing works in some situations and doesn't in a lot of situations.  I would say 50% of my work in the last 10 years have been taking over outsourced projects that have failed.