Building a New Team in a Foreign Country

Problem

I had the experience of traveling to India to build a team for my company. It was honestly illuminating.

The company was based in Sweden; I was living there abroad for a few years. There were ten to twelve of us, all mid- to senior-level engineers, and we all had a certain level of experience prior to that. We shared the same level of technical understanding and capability. There were few surprises in terms of what people knew and what they did not.

Actions taken

Fast-forward to India. We started interviewing people, but I found that there was a significant cultural gap in terms of working style. I realized that, over there, there were two main types of organizations that people worked for: product companies and service companies.

Those working for service companies would typically be sent over somewhere to do a project. These teams are temporary and the projects are short-lived. There is no concept of ownership at the level of the individual contributor. They work together like a machine.

This was really interesting to me because things were quite different in Sweden. If you knew a lot of stuff, you had a lot of responsibility. That was the frontline experience that was required of you; you were thrown into a project and expected to figure it out.

In India, people were more used to having very clear instructions provided for them. Sometimes, the problem that we were asking them to fix would get lost in translation. My own morale was diminishing because I didn’t know how to solve the problem. There were even some really important tools that we relied on that they had never used before.

I had never even thought to ask about any of these things while interviewing for each role. I had just assumed that they would know how to do all of the same things that we knew how to do. It took a long time for me to work through a lot of these assumptions.

Recruiting abroad also proved to be very difficult. There were so many people, but few of them fit the profile that we were looking for; the signal-to-noise ratio was super low. We were eventually able to find one or two very solid candidates, however.

They were willing to adopt a lot of our preferred ways of working; we were able to train them up to that point. They had attained the base level of the skill set that we needed and we were able to build from there. It took maybe two years for them to assimilate fully into the team, but it was worth the effort.

After all was said and done, we had hired at least twenty-five people over there. We were pairing constantly. We had also instituted a much more rigid onboarding system, where, before, there was no system at all. I created a boot camp for everybody, which included demos and exercises that showed them what we were trying to accomplish.

Lessons learned

• Part of training our new recruits involved getting them to think more about test-driven development and software architecture. We were working in a distributed environment, which involved a different mindset than they were used to.
• We were able to give people the opportunity to attain a level of success that is difficult to come by in a competitive country like India. We were also able to give them the experience of more responsibility and more ownership over what they were doing. Making decisions autonomously is essential to the growth of an IC.
• Dedicated mentoring and pairing was what really helped us all pull through. Many were very new to the industry. It became a collective learning experience for everybody. We were taking people from the ground level and showing them what to think about and what to do.