Cultivating a Relationship Between Collocated and Remote Teams

Problem

My company in the US had a partnership with a business services team based in Pune, India. It wasn’t simply a remote site for us, though, it was actually a contract that we outsourced to do the work. We worked with them primarily for development purposes. They were actively developing our platform and due to the nature of the way we built software we needed to ensure that they weren’t a separate unit and that they felt like a part of the same company. As a result, I wanted to facilitate and maintain a lasting working relationship between the two international teams, one that would encourage trust and connectedness.

Actions taken

I approached the situation from three different angles in hopes that the combination of them all would create a positive, convivial atmosphere.

Working agreements

a. I have always treated the team in India the same as I would treat my teams in the US. I believe the moment you start thinking of remote sites as unequal, especially if they’re working on the same platform as the collocated team, then you start getting into unhelpful decision triage. Instead, normalize the work across the board and make sure you empower all teams to make their own decisions.

b. When working across time zones, especially those with 9+ hours difference, communication is key. Being remote while being asynchronous is very important. Timelines and information flow occur but usually with delay. So we had to be aware of this and know that the remote team wasn’t at our beck and call. Therefore, we maintained a varied version of time alignment to accommodate for the time difference.

c. I wanted to provide decision autonomy to the team in India. We initially had a team of developers but we later transitioned and started having cross-functional teams for design function, site reliability, and other functions that were not necessarily labeled software development. This allowed the team to use the information they had to make informed decisions which in turn helped close the decision-making loop and the time to get an answer and take action.

d. I began starting my day earlier than usual and began having one-on-ones with the team in Pune. This allowed me to get a feel for what they were experiencing and also gave me the chance to fully understand what we were doing correct and what we were doing wrong. There are some limitations with this process though. The people in India were under a different corporate structure than ours and so though I didn’t have control or power over their career growth, I was able to share inputs with their people manager who could then synthesize and convert it into actionable decisions.

Eliciting technical excellence

a. I needed to make sure that we were getting the same level of craftsmanship and technical quality that we would expect from our team in the US. This meant getting the remote team involved in the same things we were asking the US team to do. For example, once a week we had an architectural review session. This session was fairly open and anyone could contribute changes to the system or thoughts they had in the back of their mind. The team in India was asked to participate which gave them the opportunity to not only talk about what they were working on but to also be the faces of that work.

b. I was also constantly encouraging all teams to commit across the code base - cross commit across the stack and empowering anyone to come in at any part of the code base. This is also a measure of how practices get transferred as well as how different perspectives can get baked into things instead of two different styles merging later on. This cross pollination helped move technical traits around organically.

Company culture

a. A lot of culture is about systems and processes, but more importantly about the interaction of people. To facilitate this we of course had video calls, but we also had people from the US go visit the team in India and have people from the team in Pune come to visit our office in the US. The level of conversations that occur once you’ve met someone in person is completely different from chatting with them on Slack. So while we promoted this initiative a couple of times per year, the goal was for everyone to eventually meet each other, face-to-face.

b. We also provide company swag to those who came to visit the US. They were able to be representatives while walking through the office or the city. And even though they were not our employees, they were able to relate to our company and tangibly feel like they were a part of the team.

c. Another thing that we did to promote company culture was to extend the invitation for hackathons and ask the remote team to participate along with us. The time zone difference could be a bit brutal, but some of those who stuck it out last hackathon were part of the team where their segment actually won!

Lessons learned

• Treat remote teams the same way you would treat collocated teams. Give them the same business context that all employees get instead of throwing them a problem and expecting them to solve it, without any context. I believe this is the main reason why we had such a low turnover rate with the contracted team.
• With remote teams you don’t have the oversight you would have if you were collocated so you need to have the freedom to not micromanage. Autonomy unlocks doors.
• Folks on the team were very satisfied with the work they were doing, the confidence we had in their decision abilities, and the autonomy they earned.
• After implementing these techniques we had a very diverse team with similar sets of practices which drew on from what both teams wanted. Therefore, we established a good mix of different thought processes that boiled into a similar engineering culture.
• We are constantly in the phase of ramping up hiring so that we could meet our foreseeable goals but anyone in a growth startup knows that that isn’t easy. The team in India hedges our hiring risk because we know that we have a group of people that we could turn to in a pinch. Having them onboard was a very useful resource where we could bootstrap the team quickly, have them come online, and start working right away while also helping to smooth out our employee onboarding process.