Building a New Team in a Foreign Country
23 November, 2021

Director of Site Reliability Engineering at Skillshare
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
6 February
Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.

Balki Kodarapu
Senior Director of Engineering at SupportLogic
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.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
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.

Mrunal Kapade
Director of Engineering at Inspire Energy
26 June
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
13 June
Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Roland Fiala
Senior Vice President of Engineering at Usergems