Managing Distributed Teams

1. Team Communication

In an in-office situation, we have the benefit of having the physical presence of the person we are interacting with. We can convey information to one-another in bits & pieces. This is clearly inefficient, but we know that any person can easily reach out for additional context, so you're not really marring the team communication. Also, do you feel the need to ideate? Just grab a meeting room!

Slack is like coffee ☕.They both make you feel:💼 Busy🔬 Organised🔋 Productive*Two hours later*😅 Anxious

— Rodolphe Dutel (@rdutel) December 7, 2019

On the other hand, an aspect that gets affected almost immediately while working remotely, is communication between team members. None of the ease of collaboration experienced in a co-located scenario is availableto remote workers. Managing a distributed team can get really challenging due to this.

This could work advantageously too - having guidelines in team communication ensures that individual productivity isn't lost by poor planning, constant meetings, etc. However, what are these guidelines or tenets that we need to be aware of? Our guests on the Remote Working Show, Darren (Gitlab) and Scott (Invision) had a lot of strong opinions around this. We have used those conversations and our personal experience to break it down to the following:

A) Default to Asynchronous Communication

B) Be Result Oriented

C) Choose the right team communication channel

A) Default to Asynchronous Communication

Remote work allows us to hire across timezones and also empowers us to choose our own work timings. But, this also means that it is very likely your co-worker is not always working at the same time as you. So, what do you do when you need to clarify something?

Asynchronous communication (or async for short) is the answer. Async basically represents a situation when a person sends a message to another without expecting an immediate response, as opposed to synchronous communication in which individuals are exchanging information that is immediately consumed and demands a response.

So, what are the advantages of working asynchronously:

• Increased productivity: Constant interruptions from co-workers, which is a conspicuous feature of synchronous communication, is entirely avoided in async. Asynchronous communication allows you to plan your workday and to focus entirely on the current task at hand, without another team member breathing down your neck for a response.
• Improved communication: The realisation that incomplete context of a particular task would result in delays due to the unavailability of immediate explanation, incentivises all involved to communicate their thoughts in a clear and comprehensive fashion at the outset. This helps in better planning and leads to lesser unnecessary work and back & forth.
• Extensive documentation: Async directly promotes one of the other tenets of remote working - documentation. Putting down everything in writing ensures that there is a single source of truth that can always be returned to in case of any confusion and is an important answer to your question on how to manage a distributed team.
• Better work-life balance: Beyond just increasing personal productivity, having control over your workday and being able to time your responses, results in a superior work-life balance and less stress.

Pro-tip: One interesting nugget that Darren slipped in while discussing how they implement asynchronous through Slack, was that GitLab doesn’t subscribe to a tier that stores messages perpetually.This forces everyone to document information that is critical to the project or a later time in the future in GitLab project management/ issues rather than relying on a short-term convenient option on Slack.Listen to this specific section here on the podcast: LinkWe do not pay for a tier in Slack that would keep your messages perpetually and it’s intentional. We actually don’t want people defaulting to using Slack if they could convey project-related information through GitLab issues or merge requests which are much more permanent and are directly related to the work. From an efficiency standpoint, if you have solved something on slack then you have to translate that over to a merge request or to an issue to make something happen.

- Darren Murph, Head of Remote, Gitlab

B) Be Result Oriented

An infamous concept of the in-office setting is to 'Face Time'; i.e. to just spend hours in the office to impress your boss even if you are done with your work. Sounds like a ridiculous thing to do but it is highly prevalent.

In a remote work setting, by definition it isn't possible to 'Face Time'. Here is where things can get a bit tricky for people who come from a traditional mindset of clocking hours on the job. While working remotely, trust forms the foundation of working and the focus shifts entirely to the end output as that is the one tangible aspect that can be seen by all - spending late nights to impress your superiors helps no one. This means that your team can concentrate on things that actually matter - to get work done, rather than just posturing.

However, such a result oriented culture needs to be inculcated amongst all. In a chat with Scott, Director of Customer Acquisition at Invision, he mentioned how some managers could be tempted to use a remote corollary of the in-office 'Face Time' - checking the green symbol of being "Available" on Slack. This is an extremely slippery path to be on and can spoil the ethos of your team.

This attitude might become a reactionary measure to tackle individuals who are performing poorly. Scott suggested that such cases can be addressed in the followingmanner:

• Chat 1-on-1: Firstly, the person who is performing poorly needs to understand the spirit with which you are approaching to solve the situation, which is to get the performance on track and that you are going to be working constructively towards reaching that outcome.This is best discussed on a video call and also 1-on-1 - being a delicate conversation it is important thatstatements are not misinterpreted (and hence should be had on video call rather than on chat) and in an environment where they don't feelcornered (therefore, the 1-on-1).
• Be super specific on output: Break the tasks down to a manageable granularity and make the expectedwork extremely clear. The goal is to ensure that missed deadlines aren't due to lack of clarity in tasks.
• Keep short turnarounds: As a consequence of making tasks granular, you can now keep deadlinesof shorter durations. This allows for any lapses to be immediatelycorrected and to set the right expectations soon. As you might havefigured, the idea is to "micromanage in terms of output" NOT theirworking style.

C) Choose the right team communication channel

Not all conversations are equal or of the same kind. Therefore, a singlemode of communication doesn't work nor does a haphazard choice ofchannel. Putting some structure around this helps, so that team membersfind it easy to decide the appropriate channel to communicate on for aparticular context.

The parameters on which such a structure can be defined on are:

• Default mode of team communication: Align on what the default mode of communication would be: mail, chat or call. To implement async, it is unlikely that it would be call.However, even in the mail or chat situations, define guidelines such asthe individuals who should be marked for a particular conversation, theright method for follow-ups, etc. Most remote companies default to slack or a comparable tool.
• Information context: We discussed in the first point that it is important to default toasync. Hence, for most communication it is best to send written messages for which you don't expect immediate responses. However, even in async, it is important to categorise the information. For example, regular orongoing project conversations would likely be on slack with theconcerned individual or the project management software being used,while in the initial planning stage all information would be in acentralised document.
• Urgency: Howtime-critical is the information that you need from someone else? In the end stages of a project, it is likely that such situations can arise.At such times, it might make sense to recognise the need for a channelthat everyone needs to be available on - for e.g. phone, zoom, etc.
• Message sensitivity: Some conversations such as sharing of feedback are better done on video calls, where the individuals can also infer from verbal cues ratherthan just relying on words.

Pro-tip: On our podcasts with Brie (FlexJobs) and Scott (Invision), both mentioned the importance of using emoticons to soften the message while chatting on Slack. Since in writtencommunication often the spirit behind the message can be misinterpreted, emoticons help in reassuring the recipient of the nature of themessage. So, be generous with emoticons used in your conversations!

• Number of people involved: Getting a huge number of people on a call is always a challenge andoften unproductive. Therefore, other than for project beginnings andscheduled checkpoints, a call for a large part of the team might notmake total sense. One important thing to note about managing adistributed team is that it is best to break challenges into smallerproblems and to have micro conversations around them. For larger teamdiscussions, slack or organising it around a project management toolmight make more sense.

For two to three individuals, it has to be decided on a case-to-case basis. The default is writtencommunication which does work well most of the times, but could turninefficient. Scott, Director of Customer Acquisition at Invision,covered this point beautifully in one of his LinkedIn articles.

..in a fully remote environment some interesting cultural dynamics evolvethat make this remote shoulder tap a bit more complex. People aren’t askeen to ask individuals to jump on a call as quickly – it is quiteinteresting. Now, this isn't science...this is just myobservation......and sometimes you all would have been better off justjumping on a quick Zoom.

- Scott Hanford, Director of Customer Acquisition at Invision

2. Documentation

In an organisation, when you are unsure how a particular issue needs to be tackled or the details of a certain process, you naturally just turnaround and ask your colleagues. This is the luxury that individuals have in a co-located setting.

However, what do you do if you have adistributed team? Your co-workers are not around you and waiting fortheir answer is pretty inefficient. Documentation comes to the rescuefor a diverse set of such situations - the more detailed, the better.

For example, Gitlab's handbook is a staggering 3000 pages, and has beencollaboratively built by one and all at the company from its verybeginning. This has ensured that learnings from its inception haven’tbeen lost and that almost all answers can be found by relying on thehandbook, while also promoting one of their core values of transparency.

To just showcase, the varied nature of topics covered, here are a couple excerpts from the employee handbook:

Having pets, children, significant others, friends and family visible duringvideo chats is encouraged. If they are human, ask them to wave at yourremote team member to say ‘Hi.’

- Gitlab Handbook (Excerpt 1)

One of the worst things are approval processes. We should keep approvalprocesses to a minimum. Both by giving people the authority to decide by themselves and by having a quick lightweight approval process whereneeded.

- Gitlab Handbook (Excerpt 2)

As we can see, not just common topics such as Onboarding new employees orAppraisals have been covered. Situations that are peculiar to remoteworking have been covered as well as parts that are unique to Gitlab'sculture, so that anytime a Gitlab employee is unsure about what theyneed to do in a particular situation, they can just resort to thehandbook - the single source of truth! What's more - if it can’t befound, the onus is on the person to find the answer, and to thendocument it there, so that the next person looking for the same can find it easily!

Is documentation only for a handbook?

Not at all! Documentation and async go hand-in-hand. Each time youcommunicate with another person, whether over chat or video call, it isimportant to condense the necessary information and transfer it to therelevant tool for it to be available for all to look up.

Overall documentation helps in:

• Maintaining transparency and ease of access to information
• Improves productivity by reducing the need to reach out to others
• Reduces confusion during project execution by being the single source of truth
• Helps new employees get onboarded in an easier fashion
• Provides employees a way to identify with the culture of the company, given they don't have the advantage of being able to gain that context throughextensive interactions

The biggestthing is documentation. And people like me coming in a few years intothe company have a lot to be grateful for to our founders to think about documentation when the company was only 3 to 5 people. So, our handbook is 3000 pages long and it documents every process imaginable withinGitLab front to back, even cultural processes. Everything is documented. And so, even people coming in now can look back at what was documentedat the very beginning and it is very easy to get onboard instead ofgetting a hand me down of a hand me down of a hand me down.

- Darren Murph, Head of Remote, Gitlab

You can listen to this specific section here on the podcast: Link

3. Onboarding Checklist

One of the most exciting as well as difficult of times for any of us iswhen we join a new company. There are numerous expectations andaspirations, however, the element of unfamiliarity at the very outset is a huge mountain to climb. To overcome these challenges, there are fewonboarding best practices or onboarding checklist that have worked fordistributed teams, which are:

A) Pre-joining onboarding

B) Introductions with the wider team

C) Assigning a mentor

D) Regular check-ins

A) Pre-joining onboarding

Before an individual actually joins the team, it is pretty helpful for them to know more about:

• The team culture
• A broad plan for the first few weeks after joining
• Company's new employee documentation

These bits of information work in both a co-located and a remote scenario.However, in the latter, since there is a disadvantage of not havingcolleagues around you, this becomes that much more critical. It allowsthe new employee to be more informed and prepared mentally about whatthey can expect.

B) Introductions with the wider team

One of the immediate and most obvious steps after joining the team is tointroduce the new hire to the rest of the team. This is also animportant bit in your remote worker onboarding checklist. In anin-office setting, individuals can bump into one-another, however whileworking remotely it is important to be intentional about this.

This could start with anyone in the team giving a small introduction of theperson and welcoming them, followed by others giving them a warm welcome too! Other than messages on a public channel, personally messaging theindividual would make them feel more special and welcome.

On someone’s first day they get set up on all our tools, sync up withtheir lead and key points of contact, enjoy a robust welcome GIF party,and read through some key docs about our vision, mission, and values.

- Courtney Seiter, Director of People at Buffer

C) Assigning a mentor

In the early days of joining, it is usually nice to have someone you canreach out to for any help that you need. Doist tackles this by pairingeach person with a mentor. They have found that these relationshipsshould last between three to six months.

Taking the mentorshipprocess a step ahead, the team arranges for a "Mentor Trip", where thenew hire travels to meet their mentor and to work with them in-personfor a week. This helps in creating a strong bond between the two andalso speeds the process of onboarding.

Mentoring iscritical. Working remotely can be isolating, and asking questions can be intimidating. To counter this, it’s important to make mentorship andfeedback loops as explicit as possible. Conversely, you might not needan explicit mentor in a typical office setting. You’re sitting sittingside by side with your peers all day, every day. Mentorship is implied,even if undefined, throughout the numerous face-to-face interaction dayin and day out. This difference makes it even more important that thischallenge is acknowledged and proactively worked on.

- Gonçalo Silva, CTO of Doist

In a conversation with us, Brie, Career Development Manager at FlexJobs,mentioned how they have a similar concept of setting new hires up with a "Team Buddy". The "Team Buddy" is usually a person from a differentteam. This allows new hires to acquaint themselves with people fromother parts of the company too, ensuring that they don't just interactwith the same set of people everyday.

It is clear that teams arestill figuring out new ways of implementing the mentorship concept.These are some ideas around onboarding best practices that you canborrow and adapt to the needs of your team.

D) Regular check-ins

The onboarding of a person isn't complete on the first day or the first few weeks, it takes a few months. Therefore, regular check-ins help inensuring that all is well with them both professionally and personallyand should always be a part of your new employee onboarding checklist.

For many, this might be their first experience working remotely too. Thismight lead to a feeling of loneliness and isolation. Conversations withsuch individuals might address this feeling and also reassures them that they can reach out to you whenever necessary.

4. Team Culture

For anyone to contribute to your company at their best capacity and moreimportantly to work in unison with the rest of the team, it is important that they believe in the company & its values while also being able to identify with the company's culture.

Since, this is animportant part in itself, we will cover the topic of building a culturein a remote team in a separate section. Hope this section has answeredyour questions on how to manage a distributed team thoroughly.