The Best Practices of Working With Offshore Developers

Uma Subramanian has worked in the software industry for the past 22 years, most recently for GE Healthcare, a multinational subsidiary of General Electric that is headquartered in Chicago. The company is home to over 50,000 employees spread around the world, and Subramanian, who was a senior product manager there for four years, has worked with software developers in Israel and India, as well as in the United States where she is based. At one point, she was the product manager for six software development teams, defining user stories and managing project timelines for each team, which usually consisted of six developers and two testers. 

Some teams Subramanian worked with had a stateside product manager and scrum master, but entirely remote developers and testers. Other teams had a mix of local and remote developers. Still others were located entirely overseas, with Subramanian the only person working in the U.S. In her experience, whether or not any of these team structures were successful had nothing to do with where they were located.

“Actually it doesn’t matter,” Subramanian said, “You’re communicating, and that’s the main thing — whether you’re communicating over the phone or video conference, you’re communicating.”

But getting the communication right is often the trickiest part of working with offshore teams. To help with that, we asked a few product managers to share the techniques that work for them, including picking good meeting times, using chat and development tools and — most importantly — investing in team relationships.

Keeping everyone in the loop can be harder than you think

With people working across completely different time zones, information has a tendency to play favorites. Important updates might only make it to certain team members and not reach other team members until much later, if at all. Subramanian said this can happen especially in teams where there is a mix of remote and local developers.

She gave an example of a common situation, where local developers who share an office with her find out a new piece of information that they use to inform their work, while remote team members are unintentionally left in the dark.

“If I’m working and they come by my desk and quickly ask a question, and I clarify to them, then I have a feeling I’ve told the team,” Subramanian said. “If they don’t go back and tell the rest of the team, and we both forget who we spoke to, then the person remote doesn’t know what is going on, and they develop something that is not matching what we talked about in the hallway.”

“If I’m working and they come by my desk and quickly ask a question, and I clarify to them, then I have a feeling I’ve told the team.”

This type of scenario isn’t necessarily the result of existing bad team dynamics. Developers working at offshore locations can be off from the U.S. time zone by as much as 12 hours, so all communication that happens needs to be either written down or squeezed into a short time gap — either late in the day or early in the morning — when all parties are awake and online, which is usually inconvenient for at least one party. It can be easy to slip up and forget to pass along information that later turns out to be important.

If that kind of communication problem isn’t fixed, however, it can have a negative effect on team relationships. Subramanian thinks these problems can be avoided by not having mixed teams of offshore and onshore developers, or by putting the onshore developers in charge of communications with offshore members.

“If they’re an equal team member, just like the remote, the one that’s local will have a little bit of an advantage,” Subramanian said. She recommended that, in a mixed team, the local developer can act as more of a “liaison,” in charge of ensuring the smooth flow of information to all team members.

Newly Remote?Here’s How Effective Distributed Data Teams Operate

Pick meeting times that work for everyone

Rhea Ghosh, who used to work as a product manager at Infosys, one of the world’s largest software consulting companies, often worked on projects that consisted of a handful of local developers and a large team of offshore developers. From her experience, it was definitely possible to run a mixed team effectively, as long as an effort was made to nurture healthy team relationships.

Her manager at the time was very conscientious of team dynamics, so Infosys sent Ghosh, who lives in Chicago, to India for six months of training. There, she saw up close how the developers who worked offshore had to work odd hours.

“It gives you a lot of empathy to see what teams deal with over there,” she said. “In most projects, the offshore dev had to work kind of crazy hours to work around the onshore team.”

When it came time to manage her own project, Ghosh tried to schedule meetings in a more equitable way.

“We just made a concerted effort and figured out a schedule so that they didn’t have to be available all the time to us.”

“We just made a concerted effort and figured out a schedule so that they didn’t have to be available all the time to us. We were all working sort of unpleasant hours, but no one group of people were having to always adjust themselves,” Ghosh said. “We all had some inconvenient meetings, but it made for a more productive team in the end.”

The right tools help offshore developers keep up to date

Ghosh found that having those real-time meetings to touch base once a week worked well for her team, but noted that how often meetings should be held depended on the individual team. And meetings shouldn’t be the only time members of a team are communicating with one another. Today, chat apps like Slack make it easy for developers to keep each other up to date. A developer Built In spoke to for this story said that tools like Slack not only provided easy instant communication, but also allowed offshore developers to read through conversations that may have occurred while they were asleep. This ability to read through conversations asynchronously helps to untangle the reasoning behind any technical decisions reached while they were sleeping, which may otherwise have been confusing if communicated in a short email memo.

This ability to read through conversations asynchronously helps to untangle the reasoning behind any technical decisions reached while they were sleeping.

Platforms like Jira and GitHub also provide straightforward ways to document issues, which are discrete tasks that one or more developers work on during a sprint. “One of the most useful things is to make sure that you update your comments on Jira when you’re working on something,” Ghosh said. Keeping an issue board up to date gives insight to what’s going on in the project to everyone on the team, regardless of their role or location.

Laying the foundationHow to Create an Effective Work-From-Home Policy

Consider cultural differences and language barriers

Cultural and language differences can compound time zone challenges when working with remote developers. Laura Graves, a managing director at Devbridge, a software consulting company that works with Fortune 1000 companies in the U.S. and Canada, said that all these different things came down to figuring out how best to communicate. “That could be time difference issues with communication, it can be cultural differences with communication, it can be just expectation management and tone differences with communication.”

Even while working with employees in parts of the world where time zones are not a problem, such as Latin America, effort still needs to go into managing successful communication.

“In my early experience in working in Latin America, the way that business is done tends to lean much more heavily on interpersonal relationships,” Graves said. “There tends to be a pattern of starting meetings with genuinely getting to know the person on the other side of the phone. If you aren’t maybe culturally aware of that, you can get people who are trying to jump right in and get down to business. And that can be very jarring on the other side.”

Language barriers can also be an issue. Uma Subramanian, the product manager who worked for GE Healthcare, found that, in meetings with participants whose first language wasn’t English, typing up notes while sharing her screen worked well to get everyone on the same page. “I usually have Notepad out in the meeting,” Subramanian said. “And whatever we are talking about I write it down, so that they know exactly what I’m understanding of what they’re saying, and if the understanding is right.”

Her own background helped too. Because Subramanian is first-generation Indian American, she was often able to communicate with developers who lived in India more easily.

Trust helps offshore devs contribute to projects more fully

Beyond concerns over time zones, culture and language differences, however, there is another metric that is difficult to quantify, but one that is necessary for the success of any team — the issue of trust.

Graves said that, a lot of the time when companies work with offshore teams, the offshore developers are handed rigidly defined tasks to ensure the company “gets what they want” from them.

Developers understand the technical details best, so it’s important for them to feel that they can speak up when something isn’t working.

“But I think that’s really sad, right? Because that’s not how most good engineers work,” Graves said. “And in trying to be so meticulous and detailed in the communication you actually can make the situation worse, because the engineering team offshore is going to be working independently for such a big part of their day.”

Although it’s important for well-functioning teams to communicate clearly, it’s also important to build strong relationships so that every team member can contribute fully to the project. That’s why it was so important to Ghosh when she worked at Infosys that meeting times wouldn’t consistently disrupt the schedules of her team’s offshore developers more than the local developers. “If you don’t treat your developers fairly or evenly, then I think what’s hard is that your offshore team can feel like they don’t have a voice, and so they’re not going to be able to express their concerns,” Ghosh said.

As the people building the system, developers understand the technical details best, so it’s important for them to feel that they can speak up when something isn’t working or when there should be pushback against bad business requirements.

“There are going to be technical decisions [from the business] that don’t make sense, right? Or there’s going to be product functionalities that you’re asking for that are going to make huge compromises on things like system performance,” Ghosh said. “You want to know when you are making those compromises. If you don’t know, then you could be creating huge amounts of technical debt that you’ll have to go fix later.”

She went on: “I think the thing that is really pervasive is that you’re creating a problem for your company by not giving them the power to speak up. A lot of employers will treat it as if the offshore team was like a bad dev team, and that’s not true. I mean, if they felt empowered and didn’t say anything, that’s one thing. It’s different when they don’t feel like they have the ability to say, ‘This is a bad idea.’”

Coding works best in a collaborative environment 

If a development team consists of a mix of local and offshore developers, it’s also important for the developers to have trusting working relationships with each other. While tools like Slack and Jira are helpful for keeping team members up to date, mixed teams also need to carve out space for real-time conversations, face-to-face conversations and — for companies that can afford it — in-person conversations.

“I don’t think you can replace actual conversation with a text-based tool,” Ghosh said. “Realistically, when we’re all in an office, there are conversations that happen on Slack and everywhere else that are not work related. And that human element, to be able to build a relationship with your teammates, is equally important.”

Software programmers like to think of what they do as a purely logical activity, and for the most part it is. But development teams are also highly collaborative, and activities such as code reviews are rife with opportunities for misunderstandings and hurt feelings. Tools like GitHub are great for tracking commits and staying organized, but that same precision can be a problem for team dynamics. (GitHub has a button called Blame, which tattles on whose commit was responsible for changing a particular line of code.)

“It’s harder to build that relationship over a text-based communication, because it’s so easy to misread what someone’s intent is, or to misread someone’s tone, and to get offended,” Ghosh said. “If your team doesn’t have trust, it’s just going to be inefficient and ineffective, because people are going to be pushing each other all the time, and argumentative — it’s a downward spiral pretty quick.”

There are well-known ways to strengthen relationships between developers. Last year, a team of mixed local and offshore developers Built In spoke to made an effort to be more collaborative, and scheduled a few days of pair programming at the beginning of each project using Visual Studio Code’s Live Share capability. Not only did the pair programming help developers maintain a better understanding of design through the course of the project, it also was a good bonding experience.

Having a regularly scheduled time for all members of the team to chat through video also helps build a sense of belonging. For companies that can afford it, bringing teams together in person can help to quickly strengthen bonds.

Graves’ company brings the entire development team together every summer.

“The most successful teams are ones where folks are setting up dinners or showing people around Chicago, and hosting dinners at their homes, or different things to actually invest in the relationship,” she said. “And that pays dividends over time.”

Building inclusive culture starts at the top

In order to build a truly inclusive culture that encourages full engagement from all developers and trusting working relationships — that requires effort on all levels, from the developers all the way up to company leadership.

“I would say that it’s on everyone, everyone creates the culture around them,” Ghosh said. “If you don’t see it at a leadership level, it’s really unlikely that it’s going to continue through an individual level. If the leadership team is just getting really worked up about not getting anything delivered that they want and they aren’t able to communicate what they want, then that’ll just perpetuate down the system. If leadership is calm and understanding and corrective, it creates a whole different culture.”

“If leadership is calm and understanding and corrective, it creates a whole different culture.”

Product managers can help by encouraging open communication across their teams. “Being open to feedback is really important,” Ghosh said. “And then when they start asking questions, to be really open and receptive to it, instead of being defensive about the questions that they’re asking and shutting them down.”

Little things can go a long way toward helping offshore developers feel that they are members of the team. One developer who worked offshore suggested that, when companies form social groups on platforms like Slack, that they make an effort to include offshore members, or design activities that make it easier for offshore members to participate. Sending signed physical cards through the mail on anniversaries or birthdays to offshore members can also help people feel included and special.

When it’s done right, using offshore developers can be beneficial for both the company and the offshore developers. Companies can save time by using all hours of the day, handing off issues between onshore and offshore developers or between developers and testers. And many offshore developers enjoy the flexibility in their schedules, like the ability to plan errands or holidays during times that weren’t as busy.

Offshore developers aren’t different from local developers. All developers want to be learning and growing, to be a part of something, to feel that they are contributing to something, and to write good code. During the time of COVID-19, it’s more obvious than ever that being able to communicate across distances over the internet, with tact and warmth and humanity, is a skill that’s important for everyone.