Why communication and camaraderie are necessary for a distributed team
This post was co-written by Harlie Levine
Distributed teams are hard. It’s extremely difficult to have a group of people communicate and work together effectively when you have multiple groups in different places that need to collaborate and create software. Our team took this problem and turned it to 11. We had 20+ people working on a product in three different east coast locations, with a few other people who were entirely geographically isolated (not Antarctica level, but you get the point). While we identified some non-overlapping tracks of work and split the team along those lines, we still had to communicate effectively across the teams pretty frequently. Luckily, our pains are your gains! Here’s a list of some of the pains that we felt as a large, distributed team, and the tools, processes, and general team norms that helped mitigate them and allowed us to move fast and kick ass.
Organizing the team
With up to ten pairs, keeping track of who was pairing with who and where to find them became onerous. To remedy this we created a Trello board. Each person had a card with their picture on it, and each pair was represented by a list on the board. Every morning during standup we were able to drag the cards around until we found a pairing arrangement that worked for the day.
To further ease the pain of daily pair rotation and team distance we created a dedicated Zoom meeting for each pair. This Zoom meeting was indefinite, and we created bit.ly short links for each meeting (i.e. bit.ly/blogtrack_1). The path for the bit.ly short link also lived on the title of the Trello list. So, in the above example, after standup Daria and Bob knew to go directly to bit.ly/blogtrack_1 to join the Zoom meeting and start pairing.
Keeping the lines of communication open
Slack was heavily employed to keep communication open among the team. We made a point of using Slack channels over private messages to ask questions of each other so that answers were shared more widely and more easily discovered when they came up again. Tools like Slack polls made group decision making simple.
Having dedicated and easily discoverable Zoom meetings also facilitated real-time communication. If a face-to-face conversation was the most effective method of communication, all that someone needed to do was pop into a pair’s Zoom meeting (which could be found in the pair rotation Trello board). For that reason, we also kept Zoom meetings open even when co-located with your pair. This way, even if a remote teammate needed to talk to you about something, they could still drop in on the co-located pair almost as if they were co-located themselves.
Even though we were part of a larger distributed team, local communication was still important. To make sure we could hear one another when co-located, we made sure the headphones we used were open-backed. Treating everyone as remote didn’t stop us from having local conversations, but it made us more cognizant of our remote teammates. Open-back headphones allowed us to overhear conversations and interact with our co-located teammates, but if a conversation was more than just a second or two then it was off to a Zoom meeting so that our remote pairs could still be a part of that conversation.
When we began the project, team meetings on Zoom often meant that the team in New York would gather in a room and join the meeting, while team members located elsewhere would join individually or in smaller clusters. After some time we realized this was causing reduced participation and exclusion of those not in the larger room. Switching to a system in which everyone joined individually increased engagement across the board.
With such a large group we also found that meeting moderation was necessary. People frequently talked over and interrupted each other. We moved to a system where people raised hands when they wanted to speak, and it worked surprisingly well. The meeting facilitator would be responsible for keeping track of who should be talking next, though often fellow teammates would organically share that responsibility. In the event the facilitator of the meeting was also sharing their screen, they would join the Zoom meeting on a second computer so that they could have one screen for sharing and one for viewing Zoom participants in the gallery view.
As with the pairs, having a dedicated Zoom meeting for the team with a bit.ly shortcode made finding the meeting easy. Additional tools that further eased the pain of distribution were digital whiteboards like RealtimeBoard, and lists on our Trello board. The digital collaboration spaces gave everyone the same level of access to contributing to the conversation, which meant people felt more agency to share.
Remote screen control
Since we spent most of our day pairing, having the right tool for sharing screens and control was critical. Unfortunately, there is no silver bullet to this problem. Having multiple options and a willingness to experiment was critical to minimizing the pain that comes with pairing remotely. Some days Zoom screen sharing with remote control worked better than the built-in MacOS vnc tooling. Other times that was reversed. Sometimes a pair even had one machine for screen-sharing and coding, and another for the Zoom meeting. Experimenting and doing what worked best on a given day heavily reduced the pains felt from virtual pairing.
As with most things in life, distributed teams work better when they’re rooted in friendship.
It’s easy to forget that those people sitting hundreds of miles away writing the code that caused your merge conflict are on your side. They’re your teammates. But more importantly, they’re your friends. By viewing your distributed compatriots through the lens of friendship, it helps create an empathetic attitude across the team. Small acts like in-person bonding time when remote teammates are in town, and photos of everyone on the Trello board remind you that you’re all in this together. It helps eliminate an ‘us-versus-them’ mentality, and it helps keep teammates mindful of everyone else’s pains that come from having a heavily distributed, large team.
Keeping the Lines Open was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.