The Software Purist |

TAG | Outsourcing



Software Outsourcing, Part II

If you have not read part I of this series, please check it out first:  My Experiences With Software Outsourcing. My first entry in the series discusses some of my experiences with outsourcing. In this second installment, I discuss these issues a bit deeper and provide my overall thoughts on outsourcing.  I’ve already gotten some great comments on the first article, which I appreciate.  One thing I should clarify is I’m not against outsourcing, just against certain approaches and motivations by companies who decide to use outsourcing.  In this article, I present scenarios where I think it may work.


As I mentioned in the previous edition, time difference can be a huge factor.  Teams that are intertwined often need to work closely and need more immediate feedback.  The only way to reduce this coupling is… well, to reduce the coupling.  Therefore, I am of the personal opinion, that in outsourcing, much like software, there should be a large desire for low coupling, high cohesion.  You have to trust your outsourced developers to do the work with the right instruction.  If you don’t have this sort of faith, then outsourcing is not for you, because the overhead can be high enough to defeat all discounts, and potentially, even be more costly.  Having dealt directly with this, I know from experience.  Ultimately, the goal is to desire economies of scale and avoid diseconomies of scale.

Low Coupling

High coupling occurs when any one person is free to contact any other person in the company.  Not only are they free to, but it is encouraged.  This can happen in one office.  The problem is if a single person takes direction from multiple sources, it’s more time cumulatively time consuming.  This can be deceiving, because to the person who made the request, they often got feedback quicker than if they had to go through channels.  However, for the person who served his 30th request of the day, it is well known that this is not efficient.  If this person who has been communicated to, by so many people, is a developer, all of this intercommunication prevents entry into “The Zone”.  This is one area where all of these channels of intercommunication can be the most costly.

The reason why this behavior is so prevalent is very simple.  It works extremely well when a company is small.  In a 10 person company, every person knows every other person and likely communicates daily.  But there’s a reason why this is so efficient: The company is small enough that there is likely no more than two managers, and everyone is strictly focused on work and completing their own tasks.  Then, each person merely talks to the person who he or she most needs to communicate with to complete his or her task.  The problem is that, as you likely realize, it does not scale well at all.  Putting project managers in place is a step to reduce that, since the project managers can act as the point of contact.  However, it doesn’t go far enough, unless the offshore project manager is given more authority, and the onsite project manager is more used for communication and just communicating ideas back and forth.  When it goes further that this, I believe it’s demotivating for the foreign employee to be working through multiple layers of management and messages being relayed.  And of course, it’s costly, resulting in a lot of rework, due to miscommunication.

My ultimate recommendation here is that each office should work on disjoint projects, with potentially different sets of standards and rules.  I think it’s tempting at first, to couple things tighter, because from a company perspective, it makes sense to not duplicate work.  As a purist, I feel that duplicate work is generally not cost-effective.  However, in this case, I think it’s sometimes acceptable, mostly because the alternative may be worse.  So, I generally feel that in order for the scheme to work, it has to be treated as almost two different companies.  The US location should act and be treated like a customer.  The foreign location should act and be treated like the supplier of the software.  In this scheme, I think it can be valuable, because you forego most of the overhead of the interoffice communication, except from the perspective of a client, who is concerned with functionality and not dictacting architecture.


The last thing I wanted to talk about in this installment is the motivations behind outsourcing.  The obvious motivation is saving money.  There’s no doubt about this, and it’s justified.  However, I see outsourcing as an opportunity.  You are getting developers for a fraction of what they would cost in the US.  Some companies take this a step further and even look for a deal in those countries.  I have to say, I think this is going overboard.  If you’re already getting developers at a fraction of the cost, why would you then proceed to also get inexperienced developers to save a few extra thousand per person per year?  If I was me, I’d pay highly there to get the most talented. It’s often cost prohibitive to get the most talented developers in the US, but abroad, it isn’t. I also feel that by getting the most talented developers, you get people you can trust to do the job, which also flows well with the concept of keeping overhead minimal.


Studies have shown that the cost benefits for outsourcing are often minimal, especially for companies who are seeking a deal. In pure cost analysis, because of the inherent overheads, it can provide little cost benefit, or in some cases, even be more costly.  I discuss scenarios where outsourcing might work, but it needs to be done with care.  If you’re a discount shopper, you may be fooling yourself.  If you use outsourcing to simply increase the pool of talented individuals who you may employ, the strategy has potential to be effective.

· · ·



My Experiences With Software Outsourcing

In this edition, I wanted to discuss the somewhat controversial topic of software outsourcing. I have now experienced it personally, having worked at one company that heavily employed this tactic. On a technicality, the company actually was doing more off shoring than outsourcing, since the company had a second office in Ukraine and any outsourcing done was also in this country, in an attempt to pool resources and minimize risks. Because of this, I think I’ve become pretty intimate with outsourcing and plan to discuss the scenario I saw and the results that I can see.

The first thing to note is that at various times I was either directly or indirectly managing and mentoring other developers in a foreign country. There were a lot of challenges I saw with this mechanism and because I this I think I can provide a somewhat unique perspective on outsourcing and how the company handled it.


I need to give some background as to how my company handled the structure. The offices were treated as two separate offices with parallel hierarchies. Neither office necessarily had authority over the other, except for the president and CEO. However, there were additional levels of implied hierarchy, where it was clear that if certain people were involved that they needed to be listened to, even if there were disagreements. I believe this implied hierarchy naturally occurred due to (or perhaps, in spite of) the company’s resistance to putting a more formal structure in place. Now, this was the official hierarchy. Unofficially, and unfortunately, the company appeared to have no faith in the Ukraine developers getting the job done without being babysit. So, a parallel structure of project management existed in both offices, where the US Project Manager’s job was to babysit the Ukraine Project Manager, whose job was to babysit the developers in the Ukraine office. I will discuss this is detail below.I personally do not advocate this approach, but this is the approach they seemed to use.

Time Difference

The first major issue I noticed and noted was the time difference. Ukraine is 7 hours ahead of the eastern time zone, and so it left only a two hour window during the work day to intercommunicate and coordinate. It is extremely tough to give a day’s worth of instructions with this small window. Furthermore, as a developer in a US office, when you come in in the morning, the Ukraine developer is getting close to ending his day. This provided a number of challenges for both sides, including the fact that you’re just getting started and they’re in a panic because they know once your office is ready to talk, that they may not be able to get much or any more work done for the day. Additionally, it’s ultimately very hard to coordinate when you give instructions that, if you were in the same office, could be attended to that day, but due to the time difference, it has to wait a night. The trouble of getting critical information and then letting it sit for a night can be different for everyone, but oftentimes the information can become only partially represented because it may not be fresh anymore.

If you have new instructions to provide, there’s a good chance the developer won’t be able to attend to them until the next day. This leads to two critical problems that I noticed. The first is that schedules will need to be stretched, because the critical communication, which often needs to happen at multiple key points during the day is uncomfortably crunched into two short hours. Because of this, the developer cannot not attend to a critical piece on the same day that you need it. The second is that they will take the instruction, but not have you for reference to verify a piece they didn’t understand for most of their day.


Furthermore, the majority of communication is done via e-mail, instant messenger or Skype. None of these means are nearly as effective as having a person physically there to communicate with. This situation was further compounded by the natural language barrier, speaking with people who natively and fluently speak Russian, but not English. This wasn’t immediately clear for a while after I first worked with Ukraine developers. Communication was frequently done via Microsoft Live Messenger, and it just seemed the developers were responding slowly. It turns out that they were actually translating the phrases using a tool, such as Google Translate, and then translating back before responding. This was an unfortunate tactic, because for a long time, it seemed that they just weren’t listening, when in fact, many of the issues stemmed from the simple problem of bad translation.

Cultural Differences

One of the biggest challenges of outsourcing is facing a vastly different culture. I would say the most noticeable cultural difference has to do with communication style. In the United States, a degree of modesty is part of normal and required etiquette. Rarely is it acceptable to send an email or direct communication to more people than necessary. However, in Ukraine, I noticed that their style dictated more directness, which took some getting used to. For the individuals I worked with, it was common to send an email with an issue about a person and CC the CEO, President, and the entire development team, even though this issue could’ve been resolved with a much smaller group of people. This took a long time to adjust to.  I’m not sure if this is common or potentially just an issue with certain individuals.

One issue I saw in my company was that the company never invested any time in damage control. If a colleage was badmouthed, the time wasn’t spent to correct the misinformation, so without a rebuttal, damaging rumors become accepted truths.  In addition, there was a different level of work ethic and responsibility. Deadlines often were not enforced equally among the offices. I believe this was mostly due to upper management’s approach. Upper management appeared to approach things as if, because they were cheaper, they would get more leeway.


In this post, I talked about and addressed some of the challenges with software outsourcing. In the upcoming part II, I will explore this further and start to draw some deeper conclusions based on what I’ve experienced.

When it goes live, Part II will be here:


Theme Design by