Why outsourcing works, and what we should learn from it.
By: Dallas Caley
Tags: Outsourcing, Time Managment, Software Development, Insourcing

Mars “Opportunity” rover

Anyone who has worked in software engineering for long enough has encountered the phenomenon of the outsource development team. Time and time again companies in wealthier parts of the world have turned to “outsource” teams to get projects completed faster and or cheaper than they would have otherwise. Sometimes this strategy doesn’t work, but sometimes it does. There is enough success with this method that companies often make this choice knowing the risk.

When it works:

When this strategy works, it seems fairly obvious what the reasons are. How can an engineer in Silicon Valley who demands $200k/year possibly compete with a team of 5 engineers in India who earn on average $30k/year? The stark difference in pay alone is enough to drive the Silicon Valley engineer to despair and anger in the fact that their job is so easily replaceable and will lead them to fight this idea at any cost. They will come up with many valid reasons why the India team will fail and ultimately cost the company more money than if they had just built it in-house in the first place. Many of these reasons are valid, yet still the cost/benefit analysis born out, many companies still opt to outsource.

When it doesn’t work:

When it doesn’t work, the reasons can usually be summarized as poor communication, but what does this mean exactly? Are we referring to the fact that there are language barriers or something else? Sure, there are times where the native languages between the core members of the team are enough to cause confusion, however, in my opinion it’s usually not this that is the real cause of the problem. The problems usually arise because the work which is being requested is not properly documented or encapsulated into digestible chunks that can actually be acted on.

Knowing what to outsource:

Those with experience in successful use of outsource teams have learned that there are certain types of work which can be outsourced successfully and other types which you typically cannot outsource. The type of work that can be outsource is usually categorized as:

Documentable: Your directions have to be clear and unambiguous. Any room for misinterpretation must be eliminated Repeatable: The type of tasks you give to an outsource team need to be ones that they can do over and over again, otherwise, as a manager of the outsource team you will spend an inordinate amount of time writing clear documentation Accountable: There must be a system where you can verify the work which is being done by this team. Git pull-requests are one good way of doing this, and/or having separate teams of developers and QA who are not beholden to each other.

Given all of the above, what you generally see is outsource teams doing the “gruntwork” of development or doing tedious manual tasks such as manual QA and regression testing.

Ok, so what does this all mean? Well, one thing that this indicates is that the true benefit of outsourcing can not be calculated by simply adding the cost of the individual developers on the domestic team and comparing those to that of the outsource team. Sure, the outsource team may get you twice as many developers and a lower rate, but now you have to add the extra cost associated with creating good requirements.

Those requirements will most often have to be created by someone locally who understands the business needs of the software to be developed. Extra time is going to have to be invested to convert those requirements into written documents. It will no longer be sufficient to have a quick meeting with the developers to explain what they need to build. Without well written requirements the chances of failure increase exponentially.

Hidden benefits of outsourcing:

Much of what I’ve described above is still very obvious to anyone who has actually worked with such teams. The difficulties of working across multiple time zones alone necessitates certain measures be taken to ensure that communication is accurate. We usually see this as a detriment, but is it?

Consider your typical in-house developer. They start their day at 8am get their coffee and prepare for the daily scrum. At the scrum (which is usually poorly managed) they have to listen to the status updates of every other developer and also the often the lengthy details about whatever problems that developer is having which may or may not concern them. When they speak, they give a quick update and are possibly directed to do one or another thing for the rest of the day or to continue on their current path.

After the scrum they sit down to work and opens their code editor but then notice several emails which are actively going back and forth between various members of the team. Because they are a senior developer everyone CCs them on anything even remotely important in case they have an opinion, so they spend some time going through those messages to make sure that nobody is about to walk off a cliff.

Finally, after the email they get to focus on the work of the day, however just then a new meeting invite comes in from a product manager who wants to set up for a discussion in the afternoon which, for the most part, is just managers and stakeholders talking about what they want to deliver to the client. They are there simply to observe and interject when someone says something that is factually incorrect, or someone makes a guess on timelines which is way off base.

At the end of the day, this developer, if they are lucky, has dedicated perhaps 4 hours of focused time to the work at hand.

Meanwhile, in India, the team starts their day and one of the developers on this team sets up for the days' work. There are several emails waiting in the inbox with instructions on how, specifically, to do the tasks at hand. The developer thinks to himself “Wow, these Americans sure are condescending sometimes” because of the level of detail they are getting with some of the requests, “it’s like they treat us as children, and we don’t know any better, of course I’m going to write the unit tests first, duh…”

At the end of the day however, they are grateful for the work. Most days are the same, read the emails then get to work. There is a certain cadence with the work. Everyone is expected to complete a module every two days so you are fairly confident that things are going well when you can see that you are getting done the necessary tasks.

Sometimes there is even a little competitiveness between the developers to see who can get done first and head off to the after-work socialization which happens among this team often. This happens because they know when the work is complete that there will be no more work coming in for the rest of the day because the Americans are still sleeping and haven't had time to compile their next list of requests.

What is the takeaway?

The takeaway is this. The in-house developer does not get proper time to focus on their work and is ever in fear of last-minute changes to what they might need to do. They must work the full 8 hours every day because they never know when they need to change direction, while the overseas developer is much more confident in what they must accomplish. Is it any wonder why, the developers overseas seem to do better with the time they are given?

This paradigm is not unlike the problem faced by NASA when directing the Mars Opportunity rover to perform tasks on the surface. NASA knows that the messages they send to the rover take considerable time to reach the craft so they spend a lot of time before they even send the message to ensure that it is a well-formed message and even if something unexpected happens the rover will know what to do. But what would happen if we used this same concept with our local teams?

A new paradigm:

What if we changed the way we think about local development? If taking the extra time to properly document our requests is a good thing for overseas teams, would it not also benefit our in-house teams? Also, if having specific time to focus on work and not be bothered by last minute changes or impromptu meetings is a benefit for outsources wouldn’t this also be a good thing for everyone?

Here is my suggestion, and I dare any company to actually attempt this. What if we changed to 3-day work week? Monday, Wednesday and Friday. Developers would be expected to show up to scrum on those days, go to meetings, respond to emails, slack, teams, calendar invites etc… but only on those three days. On Tuesdays and Thursdays, there will be no communication at all. Any messages sent to developers by any of the many channels of communication would be put into a queue and held for them till their next scheduled communication day.

This gives the local teams some of the same advantage that the outsource teams have. This gives them an unstressed, focused two days to get done whatever they need to get done, wherever they choose to do it. It also gives them an incentive to get work done early which they did not have before. Before, if they got done early the only reward was being able to sit at your machine and browse the internet for cat videos or whatever else strikes your fancy while patiently waiting to immediately respond to any and all incoming requests.

I suspect managers will hate this suggestion because it implies that they cannot monitor what the developers are doing at all times of the day. This may be true, but until someone actually tries this we will never know if this is actually a benefit or not.