Back to resources

Integrating a Team of Offshore Contractors

Remote
Collaboration
Team Processes

4 October, 2021

Koushik Gattu
Koushik Gattu

Director of Engineering at Rakuten

Koushik Gattu, Director of Engineering at Rakuten Rewards, details how he managed to integrate a team of offshore developers based in India and helped with the transfer of domain knowledge.

Problem

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.

Actions taken

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.

Lessons learned

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign