The key to managing a global remote team

As a remote engineering leader, I’ve had the opportunity to work with and build teams of engineers beaming in from across time zones, geographies, and cultures.

And while remote and distributed work is a hot topic of late and getting it ‘right’ might seem intuitive, it takes a lot of intention to build an equitable, welcoming, and high-performing globally distributed team.

Ultimately, achieving alignment comes from effectively communicating about the challenges we’re facing, crafting the right problem statements, and ensuring we’re including everyone in the process. Here I’ll walk through some of my learnings on building for distributed alignment so you can empower your engineers, wherever they are.

The world is your Google calendar

Hiring engineers across the globe doesn’t make your follow-the-sun rotation easier. It enables you to bring incredible talent onto your team, introduce more diverse perspectives, and build a more well-considered and inclusive product.

But being all over the world also means a lot of time zones to manage – as well as different holiday schedules, cultural norms, and lifestyles to take into account as you figure out how your team can best operate together.

The loneliest time zone:

If you don’t have regional clusters of team members – for example, a team in Lagos, a team in New York, a team in Singapore – and time zones are disparate, it can be isolating for engineers who don’t have team members online at the same time. Being deliberate about overlap and ensuring real-time availability and face time can help close the gaps.

At my current company, Pipe, although engineers may not have a team member nearby, we encourage working hours with 3-4 hours of overlap time between reasonably situated regions. (For example, one group includes North Macedonia, Finland, Germany, and Kyrgyzstan.) This ensures engineers can have real-time collaboration with colleagues – an opportunity to solve problems, get a helping hand and guidance, and, of course, some camaraderie.

Meetings:

Related, and important, is thinking about how you’re scheduling meetings. Especially in a globally remote environment, people may be showing up at hours well outside a nine to five, which may be great for some folks and challenging for others. In my experience, keeping meetings short (say 25 minutes) and agenda-driven can help things stay focused and respect everyone’s time while making sure those precious overlap hours aren’t eaten up by a sprawling meeting that went nowhere.

When you’re looking to schedule larger meetings, look for ‘agreeable’ times (not too early; not too late) for as many people as possible, and consider rotating times. If, for example, your team members in India had a very late night in Q1, maybe the next meeting can be scheduled at a very early time for your Pacific Time team members to make it closer to the business day in India.

A global calendar:

Going beyond time zones, different parts of the world have different holiday and time-off norms, as well as different holiday schedules. Knowing what’s going on where and scheduling inclusively can go far toward helping team members feel seen, and ensuring you’re prepared for the workplace practicalities.

Consider creating a calendar for local religious and bank holidays in regions where your engineers work and live so you don’t just schedule with your own location as a default. Not only will this help your engineering and product leaders know when staffing might be tighter and what days are less likely to be ideal for an all-team meeting or a big ship, but it can also help you normalize engineers taking their time off – not your standard time off. I’ve found that a flexible paid-time-off policy, as long as it’s in line with regional requirements, can be another supportive way to give team members flexibility.

Communication across the globe

You can have all the inclusive scheduling strategies in the world, but they won’t mean much if you don’t communicate about them and the rest of the work you’re doing. I’ve found that in a remote, global environment, the quality of both your synchronous and async communication – not just the availability of it – can play an outsized role in how well you work together, and how empowered people are to get great work done.

Note that when I say quality, I don’t mean the perfect language and vocabulary. I mean clarity of thought, structured presentation, and giving the right context at the right time. When you work with a global team (or any team!), it’s expected that there will be misunderstandings, maybe more than if you were all co-located. And it’s especially important to catch those misunderstandings early on, as time zone gaps and less face time can mean longer periods where question marks linger or work goes astray.

That means putting tried-and-true communication tactics to work like active listening and documentation:

Listen up:

Good listening means the team knows they’re heard and understood – and that you’ve truly heard and understood them. A simple technique we use at Pipe is playback, or repeating back what a person said and asking follow-up questions, to ensure we’re crystal clear and have captured the meaning when taking notes. When you need communication to translate from sync to async and back again, you want to make sure you’ve heard the nuance, details, and feedback.

Documentation:

Relatedly, producing and surfacing solid documentation keeps engineers informed and aligned. Making sure that team members, wherever they are and whenever they’re working, have the same access to information helps level the playing field and unblocks their work. 

Here I’ll share some simple ways to build a culture of documentation, but you may also want to think through how documentation is organized so everyone can easily discover what they need, as well as how it’s surfaced (such as through annotating emails, Slack messages, etc.) so you normalize using the docs and create lots of visibility around them.

• Embracing a culture of documentation can start small. On teams that don’t get a lot of in-person face time, you could consider having engineers write up a document with their working styles, expertise (for instance, program languages, special skills, or interests), time zone, and working hours and linking them in your Slack profiles or other team documentation hubs for easy discovery. It’s a fun exercise that helps team members get to know each other and reach out to the right person for support.
• Collecting real-time information and surfacing it for asynchronous scenarios is another way to make documentation the name of the game, and it’s as simple as taking good notes during meetings. That means clear, structured, and detailed enough to provide the context and color readers need to understand what went on and feel tuned in. (Side note: rotate your notetakers and meeting leaders to make sure you don’t reinforce hierarchies or bias who gets the airtime.) Have the notetaker or meeting leader follow up in a Slack channel (or whatever you use) with the points you’ve covered, the next steps, and the notes/documentation from the meeting so team members who couldn’t attend don’t miss out on the context.
• Once your team is seeing the value of docs, you’re ready to go one further, making documentation core to the building process. At Pipe, before diving into the implementation of the product, engineers write up a Problem Statement, a Charter, and an RFC, and there’s a block of time for weighing in on that RFC. This gives collaborators and stakeholders the opportunity to understand the scenario in depth, share ideas, and even peek back at its evolution to solve future problems, whether or not they were able to attend a meeting or get face time with the project manager. We also document retrospectives when bigger projects are complete, and more broad-sweeping quarterly retros held with the whole team to discuss successes, challenges, and how to learn from our work. These techniques make documentation deeply linked to product development, enable team members to openly share feedback and collaborate, and only rely minimally on synchronous time together.

The key to managing a globally distributed team?

Ultimately, it boils down to awareness, thoughtfulness, and empathy in the way you build your team communication and collaboration norms. As a leader, step out of your own shoes and think through how you can best connect engineers to each other, empower them to solve complex problems, and use your distance and differences as a strength. A globally remote engineering team that’s empowered to work like one – and not like a more spread-out version of an in-office team – has every opportunity to thrive.