Working with remote teams is often difficult. I attribute this primarily to difficulty communicating in ways that we are not used to. With remote teams, we can’t walk over to a coworker’s desk and quickly work out how two components integrate. Even with modern VoIP and video conferencing tools, there seems to be a higher barrier to usage than in person communication, resulting in less efficiency in solving problems and difficulty integrating the work of remote teams.

These lessons and ideas may help to improve efficiency and decrease the sense that other teams aren’t doing their job, which seems to be a common symptom of poor communication (assuming that the remote team is a professional software team). The main idea here is to define expected communication channels, set expectations around the responsiveness, and provide detail oriented responses.

Lessons

Most communication with remote teams should be treated as TCP, not UDP. There are few things more frustrating than asking a question and not receiving a response. When working with teams over multiple time zones, not receiving a reply often means an entire day of lost productivity. When a team member receives a communcation from a remote counterpart, if it can’t be answered right away, it should be acknowledged and an expectation set for when a follow up will occur. While I prefer for it to be assumed that a response or acknowledgement is required, teams can define whether a reply is desired or not by default. Depending on what the team decides, team members can then specify in their communications if a particular case is an exception to their default.

This leads to the next point - in engineering situations a communication may contain multiple questions intended to gather detail about a complex situation. In my experience it is rare to get answers to all the questions posed, leading to the aforementioned problem of a day wasted waiting for another reply. It is helpful to go over a reply before sending to make sure all questions are answered. I have also found that when I receive replies inline to my questions they have been more complete, so teams may consider making this a habit.

Overall the ideal fix for these communication issues is for the teams to set expectations for each other and to adhere to them. Teams should define what communication channels are acceptable and team members should check and respond to all channels in a timely manner. Teams should also set their expectations for the hours during which they will be reachable and the expected response time during those hours. Different communication channels can have different expectations - email may have a one day turnaround time, while a Slack message is expected to be answered within an hour during business hours. Strict requirements around response times may be set during critical periods such as during integration work that is important for an upcoming release.

When using chat with remote teams it is important for efficiency to lead with the question. Though it may seem polite to open with a greeting and wait for the other person to respond, time zone differences could easily mean that the other person does not acknowledge the message for hours, then by the time they do the initiator may be offline, causing another several hours delay. In this sense, chat messages should be treated as UDP - the question or comment should be sent without waiting for an ACK.

Some additional miscommunication I have noticed may come from not understanding the expectations that certain phrases imply. For example, the following phrases should be considered to require a reply: “let me know if…”, “please review this”, and “please comment on…”. This case might come up on code reviews, where the requested reviewer may actually review the code but provide no comments. This leads to the requestor to not know if any review took place at all. In some cases I have specified in the request “Please review and add comments or a LGTM” to indicate that some type of acknowledgement is expected.

Another source of communication failures seems to be a misunderstanding of the case when someone reaches out for assistance. When someone asks a direct question about an area in which the receiver may be considered an expert, in engineering situations the requestor is likely asking for a judgement call. The recipient should answer the question if they can. If not, it is recommended to provide a suggestion, outline various aspects of the topic related to the decision, or seek more information from the requestor in order to provide a suggestion.

Finally, though it may seem obvious, as a way to better manage integration, I recommend versioning and checking into source control all dependencies and integration points. Although this leads to the pattern of “the software looks like the teams that worked on it,” versioning is important to allow the software to evolve gracefully.

I hope these points can be of use to others and welcome additions to this list.