Experimenting with a Global Team

My company has had teams in Vietnam for years, but during the pandemic we decided to experiment with something new for us: a truly global team with two engineers in the US EST time zone, one in US PST, and two in Vietnam, all working on the same project.

Adding two engineers in Vietnam would double our capacity for a core area of the product. I we could make it work. A big IF because everything hard about regular remote working turns up to 11 with a global team. The risks are obvious:

  • Wasting time: waiting for clarification on requirements, for code review from tech lead, to be unblocked by a password reset, for design feedback...etc

  • Low trust: Limited time together makes it hard to have the direct, honest discussions essential to quality

  • Lack of context for the underlying user needs => engineers don’t have the confident autonomy to decide on solution => more waiting / boredom

But six months in we’ve avoided these problems and the team is thriving. How?

We got two things right:

  1. Choose people who are both decisive and talkative

  2. Create team culture of flexible, asynchronous communication

People:

Selecting engineers who are decisive eliminates a surprising amount of the waiting problem. As long as they’re also loud when they do need more information or do spot a problem.

Of course finding the best people isn’t exactly scalable, but if you nail it for the first person/first team they will set the culture for the next person.

Communication Culture:

The most important thing is simply for the PM and Engineering lead to pay a lot of attention to the team communication culture, especially in the first month. The specific tactics matter less as long as you’re frequently evaluating how to make the team discussions candid, fast, and high context.

The most useful tactics for mitigating time/context challenges: 

  • 20% more detail - in requirements, in designs, in reviews, as a motto for the team

  • Using Loom to narrate requirements, mockups, reviews 

For trust building:

  • Starting project with a Pre-mortem

  • Regular retrospectives

  • Reverse roles

    • Engineers drive planning, product reviews, grooming

    • Give autonomy over decisions

  • Detailed test/QA cases => helps create mutual taste standards

In retrospect I should have invested even more time in the first month in modeling and tweaking fast, candid communications. Once you get that system running, context and trust will keep building.