This is Part III of my post on a how you might think about determining where to locate your offshore software developers.
I started in Part I with the Gartner list of top 30 IT offshoring destinations, and have been critiquing the applicability of Gartner’s ranking criteria for software development, as opposed to more general IT services tasks. Gartner has a criterion they call “cultural compatibility” that they use in rating the various countries. It’s one of ten criteria they use, but I’m wondering about its applicability in a “flat world”. Gartner doesn’t define cultural compatibility in much detail, but they say it involves “adaptability to multicultural approaches to support an international business environment”, and they also consider the time zone of a country, ease of travel to a country, and its proximity to the major home countries that purchase offshore development services.
Some of the potential attraction of South American countries (at least to a North American company contemplating doing some software development work offshore) is their cultural compatibility with the US (that, and the closeness in time zones to the US). So what about it? Should you consider cultural compatibility? I think so, but it might depend on the software products you are developing. I had a chance to visit South America recently, and one Argentine software development executive noted that “we watch the same TV shows”. I don’t think watching CSI is going to make a developer more productive (but CSI Buenos Aires might be a show I’d watch!), but of course that wasn’t his point. What he meant was that, with some common cultural understandings, Argentines could communicate well with Americans and more quickly gain a common understanding of what a project was about or, in Agile terms, what a user story meant. That’s worth something. What I’ve noticed is that when the project at hand is consumer-related, an Argentine firm might arguably have a better understanding of US consumer society than developers who live in farther-off time zones. I met with the head of an Argentine software development company last week and it struck me that his client list is very strong in advertising agencies, social media, and other consumer-oriented work, although they do work on business applications as well. In my case, I’ve spent most of my career developing business applications where developers learned the domain over a period of years, by working with their US counterparts. They didn’t come with an innate understanding of the business processes related to that domain (logistics) any more than a US developer does. So in cases such as this—business applications—I’m not sure culture is as important as training your developers on your domain, and finding a way to have a low turnover so you don’t fritter away the investment you make in training your people, whether they are your own staff or those of an offshore development company.
Let’s talk about work habits, which might be one aspect of “cultural compatibility”. Something I’ve heard more than once from US senior managers is, “…those Eastern Europeans are still shaking off communism, so how do you get them to work hard and show up every day.” Look, the Berlin wall fell in 1989. That’s almost 23 years ago. In Eastern Europe, your average developer is probably going to be about 28 years old. So the residual effect of communism on the average developer’s work habits is going to be negligible. Now, it’s true that bureaucracy continues to smother some of the less economically advanced economies in Eastern Europe (and for that matter, most major offshore destinations, such as India). As an example, I pointed out in my last post how difficult it is to pay your taxes in some of these countries. So bureaucracy is something you are going to need to deal with if you operate in those countries. But in my experience it has no bearing on your developer’s commitment to their jobs and their companies. If you can motivate them with interesting projects they’ll show up for work, try hard to understand your business and work hard to deliver (at least they will if you’ve recruited well).
In the long-term, I think it’s clear that the world is becoming flatter, and cultural factors may be less important when considering where to offshore, although it’s still a factor now. If you travel in these countries, you’ll see that everyone is on smartphones, using LinkedIn or Facebook (or their own local variants of these networks), so people are slowly growing more similar, not more different (at least when considering the major offshore development destinations, as opposed to, say, Saudi Arabia). Many years ago, I worked on a consulting project with IBM that involved some work with an R&D lab in France. Over and over, cultural differences came up. I think both the French and the US teams respected each other, but there were differences in how they approached development projects and in the processes they used to make decisions, and resolve issues. Today, methodologies like Agile are providing people with a common language for developing software. It’s a global language, and with more and more projects being developed across multiple sites and countries, people are developing a common understanding of that language. An Agile “Product Owner” is a Product Owner, regardless of what country they are located. Sure, people will bring their own cultural backgrounds to roles such as this, but I see the importance of these differences declining, as least as it pertains to software development. Twenty years ago, the idea of developing products using mixed onshore-offshore teams was daunting. Now, it’s commonplace.
CamiApp 