Integrating a Team of Offshore Contractors
Sr.Director of Engineering at Rakuten
We had a team of offshore contractors based in India that did most of the development and owned the domain knowledge entirely. At the same time, Product, Marketing, Sales, and about everything else was located in the US. As is often the case, communication between Product and Engineering was not satisfactory. Much of the product development was top-down, and the lack of collaboration and knowledge sharing was staggering.
Due to time zone differences and the India team’s employment status, the situation overall looked rather discouraging. With no documentation in place, the transfer of domain knowledge looked impossible. In addition, because all of them were contractors, it was hard to grow the team. They felt detached from headquarters and would approach the work as merely handing over deliverables.
Then I was brought in one day, tasked with managing that team. I had to ensure the smooth transfer of domain knowledge and improve collaboration between Engineering and Product.
The first thing I did was to inquire if we could hire people who worked in India as contractors. It was quite a bureaucratic hassle, but it was possible if we would acquire their company. However, other business units felt that it would still leave Development stuck in their own silo and advocated that we build a team in the US.
As I started to learn more about the team, I realized that there was almost no documentation. The entire domain knowledge was in possession of the team based in India. Therefore, we brought in the most senior engineer from India to the US and hired an architect and product people to work with them and help them build the documentation from scratch. It took between two to three years to complete it, but we could already better understand bits and pieces of the development process within the first year.
Then we had to think about what was that we needed in terms of people and their skill sets. We had to define hiring criteria and skill set metrics that would allow us to evaluate potential candidates. We also did a budget analysis -- could we bring all 20 engineers, or should we need to reduce that number to only 10 of them. We decided to go with a hybrid model. We would pick some of their best engineers, bring them to the US, and thus transfer most of the domain knowledge. They would also help update documentation and spread the knowledge across the team.
By being close to the other units, especially Product, a collaboration between the two departments improved, making the development process more bottom-up and participative. We also evaluated the performance of people who stayed in India and made personal career plans. In the end, we kept around 25 percent of people who didn’t have to interact with the business operations and could focus on pure development.
We were doing multiple things at the same time. We were trying to expand our business in several countries and were developing a platform that would enable us to do that. We tasked the team in India to work on the platform, and then we let it be. We never made any serious migration plans, nor we made sure to keep an eye on documentation. When I was brought in, the situation looked dire. But I was not after quick fixes. I was after a solution that would make everyone happy and the company even more successful. This is why I balanced throughout the process what is best for the people on the development team and what the company would benefit most from.
Be notified about next articles from Koushik Gattu
Sr.Director of Engineering at Rakuten
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.