Leading a Globally Distributed Team
CTO at Redica Systems
My company has offices in San Francisco, US and Bangalore, India. I’m intentionally using the term office for the Bangalore team because we don’t believe in the offshore model as such. Obviously, having the Bangalore office entails some cost benefits, but we are primarily interested in attracting talent. So we look at it as a pool of talent we can tap into and which allows us to be competitive in the world market.
I’ve been working with teams distributed across the world throughout my career and spent significant time working both in India and the US. Some of those experiences came in handy when I joined my current company and when we decided to build a globally distributed team. But nevertheless, there were still many challenges I had to navigate in order to set our distributed team up for success.
Of all challenges that a globally distributed team implies, time zone difference gave me the most trouble. My past experience with time zones was East Coast vs. India, but that had a better overlap in one side of the day in comparison to West Coast vs. India time zone, where inevitably collaboration time spills over both AM & PM hours. So I had to start planning and thinking one day ahead. Notable time zone difference particularly impacted senior people who had to communicate much more, stretching their working hours from morning till night.
It didn’t take me long to realize that handoff had its cost. It took a lot of communication and occasional swinging over to ensure alignment and smoothness of communication. Though we were aware of how costly that could be, we didn’t have enough people at the early stages to approach it differently. So many people were sacrificing their personal lives to make that communication possible.
Their distress made us more aware that we should be more effective in our communication. I tried to co-locate the work as much as I could, given the resources we had, and reduce the number of meetings, especially those involving people from different time zones. But that is not always doable and depends heavily on the size/phase of growth and type of work.
Therefore, the most reasonable approach at that moment was to identify a number of senior engineering managers both in the US and India who could take on most of the communication and thus spare the whole team from sitting through multiple long calls. We also added some more people who could help with communication through targeted hiring at both ends. In a nutshell, those people would sacrifice significant time to communicate and bridge the gap between different time zones while shielding the rest of the team.
Not surprisingly, different time zones had their cultural implications too. Many people were not previously exposed to a culturally diverse environment and struggled to navigate that. For example, some people didn’t feel comfortable saying no to their higher-ups, and that included saying no to early morning/late night calls, even if that would heavily disrupt their personal or family time.
We had to call this out and explain the cultural roots of this behavior and make stakeholders more mindful when scheduling meetings. I wanted to separate everyone’s calendars into green, yellow and red zones, so people should know if they were booking a call during appropriate times. I couldn’t do that due to lack of configurability in our calendar tool, but at least we published the acceptable overlap meeting hours with time zones and asked people to keep that in mind when setting up a meeting. The problem was culturally conditioned and, as such, took time to change.
Also, we had to reduce the number of meetings. We relied on a set of collaboration tools that allowed for asynchronous communication. For example, we moved some of the standups that involved the global team to Slack bots. The team would still have to meet in real-time, but instead of doing it daily, they would do it once or twice a week.
Investing in processes from the start helped immensely. If engineers could understand the process well, from check-ins and code reviews to continuous integration and continuous deployment, they would be set for success. Then with little effort, one could use tools like Jira or Slack to collaborate. For us, investing early on in processes was critical. Sometimes startups postpone that and keep processes manual, which makes it far more challenging for the team.
- Make sure that the team on both sides feels integrated. For example, if a meeting is scheduled during the US working hours and the US team joins in from one conference room, while the India team attends through a conference bridge, pay enough attention not to have local discussions within the room that makes the team on the conference bridge disconnected. If you don’t know how to run global meetings efficiently, hire someone who does or arrange training. We had some people with experience who helped train the rest of the team how to run global meetings more effectively and how to make remote teams more included.
- Remove unnecessary meetings. I call a person who does that a meeting ninja. You shouldn’t be the only person to question the validity of a meeting; the whole team should be empowered to ask why they need that particular meeting. Early on, when there is a lot of ambiguity, people need to communicate more but don’t know who should be included. We created a process that helps us define a meeting’s objectives and set up a clear agenda. Educate people to say no consistently if they feel it wouldn’t be a productive use of their time.
- Cultural awareness takes continual education. Identify cultural champions on both sides who would help the entire organization navigate cultural challenges.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.