I lead an engineering team with members distributed across several U.S. states as well as Serbia, Thailand, and Japan. A couple of weeks ago, we all met at an in-person team event in San Diego, and we asked ourselves a question: if we had a choice, would we decide to be closer together?
The answer was: we wouldn’t want to change a thing.
Having to default to asynchronous communication suitable for cross-timezone collaboration means everyone on the team has equal freedom and flexibility to work whenever and wherever they want. We value this freedom and flexibility, and the impact they have on our well-being is making us a stronger, more resilient team.
We’re part of a larger geographically-distributed company that frequently reforms teams as priorities shift and grow. So we’ve all had experience working on these kinds of teams before. But our current group, formed in January, has really nailed the practice.
June 5th: The AI Audit in NYC
Join us next week in NYC to engage with top executive leaders, delving into strategies for auditing AI models to ensure fairness, optimal performance, and ethical compliance across diverse organizations. Secure your attendance for this exclusive invite-only event.
We’ve been very intentional and deliberate about how to succeed together from the start, and we’ve defined a number of best practices over the last few months — some inspired by tactics we learned from previous teams we’d been on and some we developed together based on preferences of the folks who comprise our team.
Here’s a curated list:
1. Overcommunication
One of the intentions we explicitly agreed on when our team initially formed was overcommunicating, and it has proven to be extremely useful. We hoped overcommunication would help us at least avoid not communicating enough, and, at best, figure out what communication level we need.
In practice, overcommunication helps when hesitating in daily situations like:
-
Is what I’m about to send via direct message to my team member relevant for them? Should I bother writing a message? Yes, overcommunicate!
-
Is the timing of my message right? It’s Sunday evening in my colleague’s timezone! No worries, overcommunicate! They’ll decide on how and when to react (“do not disturb” and “silent” modes are our friends).
-
My colleague may already know what I’m about to write to them about — should I stop? No, overcommunicate! Better to be safe than sorry.
-
I need to step away from the keyboard to change my baby’s diaper, does my team care? Yes, overcommunicate if you can (it’s okay to leave out details)!
2. Pairing/collaborating
From the beginning, our team was cautious about accidentally developing “microteams” of common pair-groups, split along time zones, and we were looking for ways to prevent this. Pair-programming, in which a set of two engineers work together to solve a problem in real time, has always been a part of our larger company culture. We decided to encourage cross-timezone work, so-called “ping-pong” pairing.
Ping-pong pairing is similar in principle to traditional pair-programming but asynchronous. Instead of the traditional method, in which one person writes code, and the other provides suggestions in real-time, trading off between these roles often, we let our respective daily schedules dictate the rhythm, sometimes letting some time pass between coding and commenting. This still retains the usual pair-programming benefit of knowledge sharing, while allowing more than two people to participate in the process.
To facilitate ping-pong pairing we found it useful to:
-
Limit our work in progress to three cards (number of engineers on our 10-person team, halved, rounded down). This encourages us to look for tickets already in progress before starting anything new.
-
Post work-in-progress Pull Requests (PRs) as soon as possible. It should be natural that, unless someone is actively working on a given task at the moment, anyone should be able to read through the PR (and other relevant communication) and continue working on it.
-
Hand off work in progress, either asynchronously on Slack, or in video calls when people’s working hours happen to overlap, especially at the day’s edges as one person’s day is ending and another’s is just getting started.
3. Chat usage
Our entire company uses Slack to communicate. And as a distributed team, Slack is an important tool for our day-to-day team interaction. We use it to note our availability, request help when needed, coordinate ad-hoc video calls, etc. While my particular team has its own channel, it’s important to us that it is public to the whole company. Members of other teams are welcome to join and participate when they need our assistance.
To help us navigate all the different conversations happening in our team’s Slack channel, we have developed a few useful practices. We:
Use emoji to denote important messages. Especially when the whole team is overcommunicating, it may be difficult to scroll through all the messages on Slack at the start of one’s day, not to mention after coming back from vacation. To alleviate this and make scanning our channel easier, we started prefixing certain messages with emojis like:
- :mega: or :speaker: for PSAs
- :exclamation: for important warnings
- :information_source: for less important information
- :question: for… questions
- A custom “big red arrow pointing right” :status: emoji for taking breaks or signing off
Surface important decisions made in threads. Some important decisions are made deep inside Slack threads (starting with the :thread: emoji). These are easy to miss, so we decided to always try to send important messages up to the main channel, too.
Summarize video calls. We tend to jump into on ad-hoc video calls a lot to discuss pressing issues or hand off work when ping-pong pairing. This can sometimes make it difficult for people following the issue later on Slack, so we try to write quick summaries (starting with a cute custom :hug: emoji) of what was discussed and decided in a call after it’s finished. This helps ensure people understand what’s going on, even when they can’t participate synchronously.
4. Meetings
Because of our spread across time zones, meetings aren’t an option for us during a normal week. But we enjoy synchronous time together and make use of it for smaller groups. Here are a few ways we’ve made it work:
Embrace asynchronous standups. In co-located teams, daily standups are brief updates about what everyone did the day before, their plans for the day, and any blockers. On our team, there’s no one time all of us can gather on a call for this update, but these daily updates are still important. We had been using Slack messages for that (emoji :standup:). But now we’re experimenting with a tool called Range, which helps us track our daily progress asynchronously.
Define weekdays. It may be difficult to know what “Wednesday” actually means, depending on who’s speaking (from which time zone). We’re defaulting to “Wednesday” meaning “North American Wednesday,” regardless of context. So I’ll say “let’s talk about this during our retrospective on Thursday” even though I work from Japan and that’s Friday for me already.
Alternate time slots for retrospectives. Times for our retrospectives alternate every other week so that we have both US-friendly and APAC-friendly times and so that everyone is heard and can contribute to improving our collaboration as a team.
Record meetings by default and keep notes. For both planning and retrospectives, we make recordings (and notes for retrospectives) available for people who couldn’t attend.
Schedule sync meetings if there are any “missing links.” While our team’s engineers work from North America and Asia, our designer is located in Europe. Every week, we have at least one synchronous call with him and any others who can attend, and create recordings and notes for others. Overcommunicate.
These are some of the things that have made our distributed group work so well together. We’re always interested in hearing about how other teams stay connected, too. So if you have any good tips, reach out and let me know.
Marek Nowak is Engineering Team Lead at CircleCI.
