Quite openly, we cannot be a completely neutral party in this post. Full disclosure requires us to state up front that we are an offshore IT services vendor. And we “drink our own Koolaid”: we think we do very well what we work so hard to do every day, which is to deliver IT services to our clients under an offshore business model. Now, we learned our trade the hard way, making many mistakes that cost us a lot of time and money. If not anything else, we hope that the fact that we have suffered through a learning process , gives us the authority to transparently discuss the risks we see in IT outsourcing, and how we have learned to control them. That being taken care of, our opinion is that the single greatest risk to outsourcing abroad is communication, or rather, a lack thereof. A software development project is only partially about technical skills. In fact, technical skills can be found worldwide by the dozen. Any smart person can self-teach him or herself how to code –the information is free and readily available on the internet, in almost any language. Why is communication so important? Think about it. When you are developing software you are trying to express intangible concepts and ideas that will become and automated tool or process after they are coded. Contrary to hardware, which once it is tooled or built, cannot be easily changed, software is (almost) completely “fungible” (malleable).
This degree of freedom is both a blessing and a curse. A blessing, because things can adapt to a changing market and environment. A curse, because if you do not get things right in the first place –at least get things heading in the right direction—the cost of change, of refactoring, can be very high, to the point of killing your project and even your career. Communication is key at the beginning of a project, so that the software development engineers offshore can grasp the overall idea, and be guided by their own intuition in expressing that idea in code (no matter how explicit the client is, engineers will always have to make judgment calls when coding). Communication is also key throughout the software development project, when new insights arise and the code has to be unmistakably tweaked, retooled and repurposed over and over again, until a finished version is good enough to launch. Now, what are the challenges of communicating abroad? Any attempted answer to this question has to be highly multifaceted –communication includes speech, written content, gestures, cultural attitudes towards sharing information, cultural attitudes towards hierarchical power structures, and many more variables too extensive for this post. Here are some communication challenges we consider key:
- First, there are basic language skills. If your counterparty does not understand the words you articulate, or you do not understand what he or she says, there is no subject left to discuss. It’s not only about knowing the syntax and grammar of a language. It’s also about accent and intonation. Some countries natively have stronger accents than others and this is a fact of life. Only you will know which accents you can deal with. Even within a particular country, some people have a stronger accent than others. This can be remedied, but requires the attention of the client who we recommend be straightforward in letting the vendor know which developers are acceptable on the language front.
- Second, there are cultural norms about what is appropriate to communicate. Many clients –especially in the US and Canada—come to us with a history of frustrated offshoring engagements with certain cultures and countries. They express their frustration about the fact that the development teams deployed abroad were, for example:
- Always saying “yes” despite the fact that the sometimes meant “no”, or meant “I don’t understand”. In certain cultures, accepting that you do not understand is taken as an insult to the person who was explaining the issue. This is, of course, very dangerous.
- Other cultures are ashamed of saying “I don’t think what you are proposing is feasible” or “this is plain crazy!”, because they are afraid their counterparty will take this as an insult. Double dangerous, as the client expects the expert vendor to be, at a minimum, a sounding board, if not a demanding filter for tech related ideas.
- Some cultures have a difficult time accepting mistakes. This can be extremely harmful to any complex software development project or other IT services undertaking. All software projects face challenges. In all software developments mistakes are made. The quicker the problem surfaces and is taken care of, the better the health of the project. Cultures that are afraid to communicate red flags can subvert a project in the long run. Cultures that do not see a mistake as learning opportunities that should be socialized with the group so that “all learn from all’s mistakes”, often commit the same errors again and again. Cultures that are afraid to “fail forward” with the best intention, do not take the creative risks necessary to make the difference between delivering a “killer app” or delivering a mediocre product.
- Third, there are cultures that only communicate well under certain circumstances. This is especially prevalent in highly hierarchical cultures, carrying mores from chaste systems, for example. In such cultures, a person might say one thing when alone, and say something completely different when in the presence of their boss –or worse still, simply not have an opinion but remain completely quiet when the boss is present, despite having openly expressed an opinion that is completely different from that of the boss. This behavior can become critical during a project, leading the team to stop to a standstill until “the boss” defines this or that.
- Fourth, some cultures are less predisposed to being proactive. One is always threading treacherous ground when making generalization, but this in particular has been an observation our clients have pointed out over and over again when comparing our IT services to services provided in Asia. Many of our clients complain that in past outsourcing projects they had the experience of the development team being very obedient, but seldom proactive. Yes, people would do exactly what they were told, but: a) they would not go beyond what they were told to do; b) they would often reach a cross-road and simply wait until it became an obvious crossroad, and the client expressed an “order” about what to do. There was no pizazz to move ahead and tread new ground, to come to the client not only with a “what should we do here, we have this problem” but with a “we have this problem, here are several alternatives to what we can do to solve it, what do you think?” Docile is not necessarily an attribute when it comes to software development.
