How to manage a remote team

Our approach to managing and building remote teams

Introduction

Remote work is no longer a trend, but a reality. One that is here to stay. People nowadays work together, and create amazing products together, without ever meeting face-to-face.

Here at Imagile, we have offices in Germany, Brazil and South Africa, plus independent and talented people working remotely from other countries as well.

This post is another one in the series of posts about remote work, where we share our experiences and approach.

Challenges of managing remote teams

When you work with a remote team, the first thing you need to accept is the lack of control. You can’t just go up to a person’s desk and talk something over. You don’t really know what is happening or what each person is doing right now. You can’t invite someone over for lunch to clarify a misunderstanding. The risk of miscommunication and misunderstandings in this environment is extraordinarily high. Miscommunication leads to conflict, conflicts leads to delay and frustration, which ultimately, leads to the dark side.

It is also important to stress the fact not everybody can adapt to any team. Each team creates their own culture by themselves, when they are well-intentioned and capable people. Some teams prefer chatting over long emails, some teams prefer Agile, others Lean, some teams estimate things in a certain way, and bringing in a person who doesn’t fit in this team, is an invitation for disaster.

Communication is king. When bringing people in, you need to make sure they can communicate and express themselves clearly. If they are unable or unwilling to provide very good feedback, you may find yourself with your customer, and have no idea what the status of the project is. Also, I have met and worked with many programmers who were technically very good, but who could not clearly express what they meant, or could not cope with conflict very well. In the long run, these people tend to abandon the project suddenly, create problems, or even worse, become negative leaders, diminishing the morale of the team.

To avoid the suffering, you need to set up the right processes, tools and communication channels. Not only that, you also need to invest time in the people, and make sure they invest in each other. The main challenge here is transforming a picture and a name into an actual person, which isn’t easy, and takes time. Let’s go through these points.

Work synchronization

The most important aspect of the daily work, is to find the “Team’s time zone”: a time window in which everybody in the team is available. This should be at least a few hours long. I strongly advise against hiring someone that cannot be available in the same time as everybody else.

An effective and efficient team happens when everybody:

  • Receives the information / requisites he needs in order to do his work
  • Provides detailed feedback about the work performed
  • Have an idea on what tasks their peers are working on
  • Knows in advance when something is expected of him/her

Ticketing system

Our main goal with a ticketing system is to have full transparency on the work being done, both between team members, and also, the customer. Depending on the complexity of the project, team size and what kind of reporting is needed, we use either JIRA or TRELLO.

TRELLO has the advantage of being simple and lightweight, very fast to handle and transition tickets. Its compact interface provides a quick glance on the overall state of the project.

Example of how this looks like:

With an own app, good notification systems and easiness of jumping from one project to another, Trello is ideal for simple projects that do not require a lot.

We use and love Trello to start new projects / products. It is straight forward to create a backlog and start working without big setups. This works very well until the product is production and being used by customers. From that moment on, you start needing more specific processes, maybe some customer support or helpdesk, as well as advanced reports. At this time, we switch from Trello to Jira.

JIRA is a very complete albeit expensive solution, that can be customized down to the last detail according to your own specific needs. As a product grows, it inevitably requires more advance tools and controlling.  JIRA has built-in time tracking tools, which helps you generate reports and even invoices directly from the platform, there are tools to provide customer support, helpdesk, testing cases, and so on. Another good reason to choose JIRA is the active community giving feedback and providing very extensive documentation.

Independent of the tool, it is important that every new team member receives training on it. It is also your task to constantly monitor your team to make sure everybody is using the tools and using them correctly. Writing good feedback and fiddling with ticketing systems can be a real bothersome, tedious chore, so be ready to hammer this on your team’ heads.

Feedback, feedback, feedback

I will repeat again: writing good feedback can be tedious and bothersome. And the only way of doing this right is by doing it again and again. The feedback should serve two functions: notify the present team about the progress, and remind your future self what happened back then.

Most people don’t come with a feedback culture, however, and they need to learn. You need to be patient and teach them by example. Rewrite their feedback with information you consider useful. Ask them to include information you consider missing. With time, they will get the hand of it. That is also why it is important to try and hire people that can express themselves very well. People with difficulties to express themselves will have a much, much harder time trying to understand what is wrong with their feedback.

The art of protocolling decisions and changes

Documenting decisions, changes and meetings is another bothersome and tedious task, that absolutely needs to become part of the company’s culture. It goes without saying that all negotiations should be in written form. But the negotiations are a small part of what happens in a project. Most projects tend to change during their implementation phase. You realize things you didn’t see before, new information comes, new feedback. When the project is already in progress, these changes inevitably create chaos.

In the perfect world, we would finish the version in progress, and only implement changes by the end of the project. This ensures the highest quality, as any change becomes an indivisible chunk of work. However, in the fast-changing Agile world of today, we don’t have that luxury.

When starting a new project, we always have one document with the entire concept in one place, shared with the whole team. This can be as simple as a Powerpoint shared via Google Docs or Office online, up to a folder shared via Dropbox. It is important, at any given time, every stakeholder in the project can refer to the most up-to-date version of the document. But only this, is not enough. Every time we make changes in the document, we also notify all the stakeholders, regarding what changed exactly, from what, to what. This helps people to incrementally change their internal organization.

One mistake many companies do is accepting changes without changing the timeline. Such is the life in media agencies, where everything must be delivered yesterday. Such attitude, however, is very damaging to a long-term product, as it forces the developers / designers to go for low-quality-but-fast solutions. Especially when working with remote teams, you can also have other problems, like having to renegotiate the budget and the timeline.

Communication channels

The effectiveness of your team will depend on how well they communicate with each other. Each individual has their own personality and prefers one or another way of communication. Some prefer chatting more, some prefer quick calls, some prefer longer emails. The trick is finding out something that works for your team, and add team members that can fit to your team’s culture. For new teams, this process is usual a trial and error.

Slack for instant messaging

SLACK is a great tool for instant messaging. It allows you to create teams, create private and public discussion rooms inside each team, and more importantly, it integrates magnificently to Jira, Trello, Confluence, Github, etc.

We create one Slack group for each product we are building, to focus all discussions about that specific product in there. This allows us to have separate teams, without mixing them up. We do the same in Trello, and then integrate them both together. It looks like this:

This way, all team members are notified of the relevant changes. In case of subprojects (for example: main product, infrastructure, website, blog, etc) we create different Trello boards and different channels. This setup prevents team members from being distracted with alerts that are not relevant for them.

We do the same for Confluence, JIRA, and other platforms we use, that are relevant for that particular project / team.

Skype and gotomeeting for Video conferencing and phone calls

We use SKYPE as often as possible, when text is not enough. We also try to booster a culture in which people talk to each other. Skype also allows you to have it on your phone and receive calls regularly, which is a great help. Now Skype also allows for group video calls, which is great.

Video calls are essential for team building (more on this below) and interviews. It allows you to see how the person acts and reacts during a conversation. It is also exposure for all involved, and not all teams are comfortable with this. So it really depends on your team culture. Video calls are not a substitute for face-to-face, but it makes the gap much smaller.

Github for code

When working with multiple people, and especially remote people, protecting your code and intellectual property should be #1 priority. We use GITHUB to store all our code, and we give each programmer access to this code for the duration of that person’s participation in the project. We do not accept private or third repositories. Every code a programmer has done that is not on Github, is the same as work that didn’t happen.

Github also allows you to monitor the activity of your developers, and integrates with most Continuous Integration tools, allowing you to automatize your development and delivery processes. It also integrates with Slack.

Dropbox and WeTransfer for file sharing

DROPBOX is very convenient for storing folder structures, and share it with others. You can also share image galleries or download links, which is very convenient. One current shortcoming of Dropbox is that you cannot share only a subfolder with someone. You need to share the entire folder, which forces us to separate files of the project to different folders (for ex: we don’t want to share sales pitches and contracts with everyone).

WETRANSFER allows you to securely share a link with an expiration date with someone, which is also helpful in many cases, where you need to transfer a file sensitive file.

Team building

When you work with someone remotely, there are many challenges to overcome, but in my opinion, none greater than recognizing your team member / employee as a person.

You see, when you get to know someone online, we don’t immediately identify them as a person in our brain. They are nothing more than a combination of a name and maybe a picture. We don’t immediately see their mannerisms, there is no cantina to make small talk and learn random things about their lives. We don’t connect. When you don’t connect with someone, it is difficult for you to care about them. When hard times come in a project, and come they will, having an engaged and united team makes a big difference in terms of morale, performance and burnout prevention.

From nickname to person

Depending on your team’s communication culture, it is very likely that the team members will spend the majority of their time instant messaging each other, rather them calling or emailing. This is a generally a great way for people to communicate, but focus, at the same time. However, when messaging is the only communication channel, it presents problems.

The first and more practical problem, is that certain things are difficult to communicate via chat. Type too little and you leave room for misunderstanding. Type too much and you become a burden to read. The second problem is that chatting is a very terrible way to convey feelings and attitude. Your request might be interpreted as an order, your suggestion might be interpreted as criticism, your joke might be taken literally, and so on.

For these reasons, we like to clarify things via phone/skype calls as often as possible. Some cases, especially of a very complex technical nature, are better for chat, that is true, but differences of opinion.

Promote internal bonding

When someone is new in a remote team, they tend to prefer a central point of contact. Most people rather communicate with just one person, who coordinates the work of everyone and gives feedback from one side to another. However, this is a very time consuming activity for the coordinator. This works well for quick projects, but on longer projects, it means you need one additional team member just to coordinate the work of everyone. We prefer a more sustainable solution.

We strive to make people work together as much as possible. Especially that we have our own core team, but work with many people across the globe. As I mentioned before, creating a “team timezone”, a time windows in which every team member is available. But only that is not enough, you need to actively connect them together. We start by setting up calls between the team members and we moderate these calls. Make they come up together with a solution for something, and see how it goes. If they work well together, you can gradually become less and less available, making them more comfortable to working with each other without your intervention.

However, don’t just leave them abandoned working together. You need to monitor their satisfaction with each other. Constantly ask if everything Is fine, how is it working with person A or B. If you feel there could be a conflict forming, you should act to eliminate this before it becomes a big problem.

We are currently working with our partner CCSYS to create a questionnaire and a methodology to monitor the satisfaction inside team members. I will write another entry and update the link here when we finalize this.

Conflict resolution

Most conflicts will come out of miscommunication or lack of protocolling decisions. If you want to embrace remote work, you also need to embrace conflicts. The good news is that most conflicts can be avoided by doing your homework properly.

Resolving conflicts before they happen

You need to remember that, if you hire a remote worker via a platform, your payment will usually go to the platform first, which will hold the money with them, in case of conflict, and will be the final judge in case you and the remote worker cannot reach an agreement. If you ever find yourself in this situation, you will want to have as much documentation as possible to prove your point. This may seem like an extreme scenario, but it happens and should not be underestimated.

Another potential source of conflicts are compromises, and especially technical compromises. Very often, you will find yourself in the situation when someone tells you that something can’t be done, forcing a scope change. It doesn’t matter how much you trust this person, you should always document not only the change, but also the reason. It turns out very often that people are wrong and what you wanted can, in fact, be done. By documenting everything very clearly, you can protect your budget by conflict resolution with this person. The remote worker should not be able to charge you for such mistakes, and most conflict resolution platforms will defend you in this case. However, you should always have someone in your company that can judge such topics, as to avoid headaches.

Be honest

Be honest with the people you hire. Always. Even if it hurts. If a project has a chance of being abandoned, if there is a chance of a budget cut, if you are planning layoffs, if someone is not performing well, or not fitting the company’s culture, be honest with them.

This is a very difficult thing to do, in fact, most managers and employers in this day and age do not do this. We take a great amount of time to hire someone, as you can read IN OUR PREVIOUS ARTICLE. This means we want to work only with the best. It is difficult by keeping them working with you if you lie to them. They deserve to know that you might run out of budget next month, so that they can plan their time. The biggest fear is that they will just leave the project, due to lack of confidence in not having a job coming month, but in reality, this rarely happens.

Conclusion

To manage a remote team is to face many challenges that you simply do not face with local teams. Depending on your leadership skills, charisma, budget and location, having a remote team might even not be the best idea.

On the other hand, you also don’t face many of the challenges you would face when working with a local team. There is a lot of homework to be done in order to keep a remote team functioning properly and without conflicts, but once your structure is set, it gets easier and easier. Your reference as a remote employer grows, and you will get access to other talents via network.

Do you also have experience with managing remote teams? Or intend to? Let us know in the comments below.