At Intalio, we started looking at offshoring part of our software development work in late 2004. During the first half of 2005, we focused our attention on India, flew there a couple of times, talked to about 20 firms, and finally engaged with one. After experiencing a significant turnover in the employee base of our offshoring partner, we decided that the model was not working for us and that we would be better off keeping all software development onshore, in-house.

Our primary goal with offshore had been to reduce costs, but cheaper does not necessarily mean better if you cannot capitalize on a team that remains together over a long-enough period of time. At least this is my personal experience with software engineering. In that game, your most valuable assets walk through the door at the end of the day, and this is true offshore as much as it is onshore. This post tells the story of what changed my mind about offshore, and how we are doing it today in a very successful manner.

In the Summer of 2005, I had long forgotten about my dreams of cost-cutting through offshoring, when an old friend of mine called and told me about his new job as CEO of an offshore development company based in Ukraine but headquartered in San Mateo, CA. The company had about 250 software engineers in the Western part of Ukraine and was offering software development and QA services to independent software vendors. He gave me a pretty convincing pitch, and after a thorough due diligence, we decided to give it a shot, starting with a team of 7 back in September 2005.

Four months later, I can say that I have been blown away by the results. It took our offshoring partner less than 3 weeks to get the team up and running, and they delivered a first working product two months later. We initially started with one project—a new management console for our process server, then added a second one—a brand new human workflow suite, and are in the process of starting two other projects. We now have 10 people working for us in Ukraine and expect the team to grow to about 20 people by the end of Q2 this year.

What makes it all work for us is that instead of having to provide detailed technical specifications to the offshore team, we just give them a set of marketing requirements and high-level architecture guidelines, such as using a particular J2EE API or adhering to a defined set of coding standards. The offshore team then goes on to designing the specification, developing the code, doing the testing, and writing the documentation. And because our partner accepted to adopt some of our standard development tools such as Jira and Confluence, we are capable of monitoring their progress in real-time, without changing our own development processes. We know each of their developers by name, had beer with all of them last time we went to Ukraine, and I can call their Bay Area based CEO if I have anything to talk about.

Such an organization is made possible for two main reasons: first, a large part of our offshore staff has a Ph.D. education, which grants them the level of creativity that is required for handling the software development process end-to-end, from specification to implementation and testing; second, with an employee turnover of less than 1% a year, they are capable of investing up to six months of training with each new employee, and up to a day a week of English classes. As you guessed, English speaking is not as good as with Indian firms, but written English comes pretty close, therefore most of our communication is done in a written form, either via email or Confluence, our enterprise Wiki. As a side benefit, we get an audit trail of all communications, something we would not get with conference calls.

From a pricing standpoint, Ukraine is pretty much on par with India now. Once you’ve added the cost of an offshore project manager, you get a ratio of roughly 2 to 2.5 developers offshore for the cost of one developer onshore. An other benefit is that we do not have to pay for a full-time onshore program manager. Because our offshore partner handles the entire product development lifecycle, we could start with a part-time onshore program manager working for us 20 hours a week, then reduced it to about 10 hours a week. Today, most of our communication with the offshore development team is handled directly by our Director of Product Development, and we expect that we won’t need any onshore help by the end of the quarter. That being said, other companies working with our partner feel much more comfortable doing all their work through an onshore program manager, and this is fine too. Pick the process that works best for you and make it evolve over time in order to get the best possible results out of it.

There is a lot more I could tell you about this experience, and I am learning new lessons every day, so if you want to know more about it, feel free to contact me directly and I will be glad to make a direct introduction to the CEO of our offshoring partner. Part of our success depends on their ability to maintain and grow a best-in-class team of software engineers, and nothing excites these guys more than a challenging project, so if you have one you ever thought about taking offshore, give it a shot!