how to manage a distributed team

# How to Manage a Distributed Team

So you have made the choice to build a remote team. As a consequence, you have been able to get a bunch of talented individuals distributed across a few countries 😎 . Now comes the difficult part of actually managing a brilliant team - while they might be good individual performers, you would like them to collaborate and become a great collective unit. It then becomes important to know how to manage a distributed team.

A few critical factors need to be executed successfully for the overall remote initiative to yield the desired results. Let's get into each in detail:

# 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!

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 available to 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) Focus on Output

C) Choose the right channel for communication

# 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: Link (opens new window)

"We 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 following manner:

  • 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 that statements are not misinterpreted (and hence should be had on video call rather than on chat) and in an environment where they don't feel cornered (therefore, the 1-on-1).

  • Be super specific on output: Break the tasks down to a manageable granularity and make the expected work 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 deadlines of shorter durations. This allows for any lapses to be immediately corrected and to set the right expectations soon. As you might have figured, the idea is to "micromanage in terms of output" NOT their working style.

# C) Choose the right team communication channel

Not all conversations are equal or of the same kind. Therefore, a single mode of communication doesn't work nor does a haphazard choice of channel. Putting some structure around this helps, so that team members find it easy to decide the appropriate channel to communicate on for a particular 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 as the individuals who should be marked for a particular conversation, the right 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 to async. 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 or ongoing project conversations would likely be on slack with the concerned individual or the project management software being used, while in the initial planning stage all information would be in a centralised document.

  • Urgency: How time-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 channel that 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 rather than 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 written communication often the spirit behind the message can be misinterpreted, emoticons help in reassuring the recipient of the nature of the message. 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 and often unproductive. Therefore, other than for project beginnings and scheduled checkpoints, a call for a large part of the team might not make total sense. One important thing to note about managing a distributed team is that it is best to break challenges into smaller problems and to have micro conversations around them. For larger team discussions, slack or organising it around a project management tool might make more sense.

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

"..in a fully remote environment some interesting cultural dynamics evolve that make this remote shoulder tap a bit more complex. People aren’t as keen to ask individuals to jump on a call as quickly – it is quite interesting. Now, this isn't science...this is just my observation......and sometimes you all would have been better off just jumping 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 turn around and ask your colleagues. This is the luxury that individuals have in a co-located setting.

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

For example, Gitlab's handbook is a staggering 3000 pages, and has been collaboratively built by one and all at the company from its very beginning. This has ensured that learnings from its inception haven’t been lost and that almost all answers can be found by relying on the handbook, 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 during video chats is encouraged. If they are human, ask them to wave at your remote team member to say ‘Hi.’

- Gitlab Handbook (Excerpt 1)

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

- Gitlab Handbook (Excerpt 2)

As we can see, not just common topics such as Onboarding new employees or Appraisals have been covered. Situations that are peculiar to remote working have been covered as well as parts that are unique to Gitlab's culture, so that anytime a Gitlab employee is unsure about what they need to do in a particular situation, they can just resort to the handbook - the single source of truth! What's more - if it can’t be found, the onus is on the person to find the answer, and to then document 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 you communicate with another person, whether over chat or video call, it is important to condense the necessary information and transfer it to the relevant 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 through extensive interactions

“The biggest thing is documentation. And people like me coming in a few years into the 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 within GitLab front to back, even cultural processes. Everything is documented. And so, even people coming in now can look back at what was documented at the very beginning and it is very easy to get onboard instead of getting 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 (opens new window)

# 3. Onboarding Checklist

One of the most exciting as well as difficult of times for any of us is when we join a new company. There are numerous expectations and aspirations, however, the element of unfamiliarity at the very outset is a huge mountain to climb. To overcome these challenges, there are few onboarding best practices or onboarding checklist that have worked for distributed 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 having colleagues around you, this becomes that much more critical. It allows the new employee to be more informed and prepared mentally about what they can expect.

# B) Introductions with the wider team

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

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

"On someone’s first day they get set up on all our tools, sync up with their 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 can reach out to for any help that you need. Doist tackles this by pairing each person with a mentor. They have found that these relationships should last between three to six months.

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

"Mentoring is critical. Working remotely can be isolating, and asking questions can be intimidating. To counter this, it’s important to make mentorship and feedback loops as explicit as possible. Conversely, you might not need an explicit mentor in a typical office setting. You’re sitting sitting side by side with your peers all day, every day. Mentorship is implied, even if undefined, throughout the numerous face-to-face interaction day in and day out. This difference makes it even more important that this challenge 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 different team. This allows new hires to acquaint themselves with people from other parts of the company too, ensuring that they don't just interact with the same set of people everyday.

It is clear that teams are still figuring out new ways of implementing the mentorship concept. These are some ideas around onboarding best practices that you can borrow 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 in ensuring that all is well with them both professionally and personally and should always be a part of your new employee onboarding checklist.

For many, this might be their first experience working remotely too. This might lead to a feeling of loneliness and isolation. Conversations with such 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 more importantly 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 an important part in itself, we will cover the topic of building a culture in a remote team in a separate section. Hope this section has answered your questions on how to manage a distributed team thoroughly.


PARTNERS
       
Made with ❤️ by Remote Tools.