If I tell you that you can purchase a brand new iPhone for $5, what do you think? Yet if I tell you that you can hire an outsourced developer for $10 / hour, somehow we set aside our dad’s advice that “nothing is free” and “you get what you pay for”.
Over the years, dozens of companies have asked me to join their company to help them “clean up their technology organization which they have unsuccessfully outsourced”.
Tell me if you’ve heard any of these before?
- You should outsource that projects because engineering resources overseas cost about $10 / hour.
- Our engineering team is buried for the next 12 months, just outsource that project.
- That project is a one time project, don’t hire full time resources, just outsource it.
- We outsourced all our engineering 3 years ago, it isn’t really working and now we need someone to come help us clean up.
- You can hire a few outsourced resources to augment your core engineering team.
So while I believe that you may know of someone who has successfully outsourced a project, there are some real challenges to getting it to work well. I’ve learned quite a few lessons along the way – here are some of these learnings.
As you know, communications is always a critical factor in any business – outsourced or not. Communications in an outsourced relationship, especially offshore, is a very big challenge that is most often completely underestimated. Not only are there usually language challenges, even if the outsourced team speaks english, but there are time challenges. You should be prepared to manage workday offsets, sometimes by as much as 12 hours. Outsourced companies will tell you that their resources will use technology to help communicate efficiently – Skype and Hangouts work poorly in many global scenarios – delay, echo, drops, etc… Using Wikis, Basecamp, Slack, ticketing systems and email just like you probably use with your core team is helpful, but is not a great substitute. Outsourced companies will also tell you that they will assign an on-shore resource that will manage the offshore team as a solution to communication and timeshifted work hours. This approach helps, but again it is not great and at best it will add lots of cost. It adds the cost of this onshore resource, but it also adds the cost of inefficiency in having a relay system in place.
In addition to communication, there is a very large issue of resource stability over time. For whatever reason – maybe because they pay their resources poorly, outsource companies don’t seem to retain resources for more than a month or two. The costs of changing resources is very high, as usual. You will pay for the lost productivity of having to bring in a new resource and bring that resource up to speed. Also, if the onshore manager, communication relay that I mention above happens to be the person who leaves your team then the impact is enormous. Finally, keep in mind that if you reduce your demand for resources, of course the outsource company will move the resources and so starting another phase or even supporting your existing product will become very, very expensive – so manage your demand wisely or the supply will go away.
In my opinion, there is a big difference between engineers and coders. Coders, simply implement – write lines of instructions to tell a computer what to do. Understanding a problem and designing an approach to solving the problem using computer instructions is a totally different animal. Designing an end-to-end platform that involved many, complicated interactions requires even more experience, education and skill – engineering is very, very different than coding. I have yet to work with an outsource company that employs engineers and never an architect. The results that I have routinely seen is giant pile of code, mostly undocumented and never, ever efficient. By this, I mean there is never any use of modern object oriented constructs such as inheritance, if a routine is needed elsewhere – the code is copied and pasted elsewhere. So when you have a bug, you probably have that bug in 10 places. To make matters even worse, I’m just describing simple procedural routines. I never, ever see good use of more advanced engineering concepts – for example, multi-threading or distributed processing. All of this leads to a maintenance nightmare. Sometimes you can lower the impact of this by hiring a full time employee as your architect, but even this is not foolproof.
The above are very serious landmines that are not easy to circumnavigate – you are not going to write an iron clad contract and secure a fixed bid contract to avoid all of this. And while you may conclude that you should never use outsourced development, that is not really my mission here – you can use it, but it will be far more expensive than advertised and you will need to invest significantly in avoiding issues that will turn your project into a big problem.
One response
[…] While he acknowledges that we “all know of someone who has successfully outsourced a project,” (including himself with Aeturnum) he also cautions about some of the common misperceptions and assumptions companies make when deciding to outsource. Click here to view his post. […]