9 tips to get your distributed teams to collaborate effectively

I’ve seen a lot of prior attempts to out-source work to remote teams fail, especially with teams in the Far East, and have always wondered what was the main reason for this. Is it a culture thing? Is it the time difference. So inspired by Mark Kilby’s talk “Agile Distributed Teams: Oxymoron or Viable Option?” he gave at the Agile DevOps East conference in Orlando this year, I started to contemplate on the things we do ourselves that have made our remote team endeavors pretty successful for the last 1.5 year or so.

Embrace trust

Nothing improves the efficiency of remote teams more than having mutual trust. Trust that the people in the remote location are doing what needs to be done. And trust for the people on the other side that they are empowered to do the right thing. There are a couple of things you can do to improve that. First of all, if you’re working remotely, over-communicate. If may feel awkward at first, but even when I’m working from home, I tend to be a bit more proactive in sharing on Slack what I’m doing. Whenever I leave the computer, have to run an arrant and when I return, I let the other side know. It really helps the people on the other side to know when I’m available or not and what I’m doing. It may be me, but when certain folks in my team work remotely but do not show any activity for hours, I can’t help myself from wondering what they are up to. Another thing you can do is to always assume good intent, which is similar to the Most Respectful Interpretation I talked about recently. Instead of assuming that remotely working people are doing the bare minimum to get through the day, be positive and give them the room to do what needs to be done. It’s very likely that a lack of activity on Slack is just caused by the developer being “in the zone”.

Permanent video connections

A nice way to increase trust is to make sure you can always see the people in the remote location. Because of that, I always recommend introducing a permanently active bi-directional video system. A 50 inch TV on a moveable stand with a high-quality HD webcam is all you need to increase the chances that the remote team feels part of the team. Even if the microphone is off most of the time, being able to wave to the people on the other side in the morning can make a huge difference. And since you can see somebody sitting on the other side, it will definitely lower the threshold for having a face-to-face chat instead of falling back to traditional email or chat. And obviously it works great for having virtual standups. Assuming the stand has wheels, it becomes really easy to take the whole set-up in a meeting room and having a more intensive meeting. We’ve used this very successfully while working with a team in Eastern Europe, but it equally works well for connecting our offices in Eindhoven and Leiden.

Work more or less in the same time zone

It may be obvious, but just like how the people in a team benefit from being in the office as much as possible, having enough overlap in working hours between remote teams is equally important. However, I never really knew how much overlap is sufficient, so I was happy that Mark did have an opinion on this: 5 hours. Because of this, a European country like The Netherlands has more chances of success with a popular Eastern European country like Belarus, Romania or the Ukraine than, let’s say, India. Interestingly enough, some of the outsourcing companies claim that a bigger time difference can be beneficial. You just schedule some work at the end of your working day which the other side will pick up while you sleep. But in my experience the importance of being able to have face-to-face discussions significantly outweighs any of the other so-called advantages.

Early code reviews

Something I’m trying to do pretty regularly is to check up with the developers to see if we’re still on track in terms of the architectural approach. Did they understand the boundaries within the architecture that is effected by their changes? Did they touch parts of the system that I did not expect to be changed based on the original breakdown? Are the changes still small enough to be able to smoothly get those through our review process. This is all very trivial to do if this only means walking to the team involved and asking some casual questions. But with a remote team, despite the permanent video connection, it’s a lot harder. Yes, during the daily stand-up there are plenty of opportunities to ask how things are going or whether anybody is stuck, but it won’t surface anything they are themselves unknown of. So if they don’t ask for any feedback themselves, I usually offer them to do an early review of a pull request. The purpose is not do a detailed code review, but just to see what is being touched and to grasp the scope of the changes. It has definitely helped avoid multiple review-and-rework cycles.

Onboarding process at the main office

The need to be able to feel part of a project or product team is something that doesn’t need explanation. So as a remote team, wouldn’t it be great to visit the main office and meet the rest of the teams? Absolutely! That’s exactly what we’re doing. Any new member that joins the remote team (after an extensive and rigorous hiring process), is brought in for a week or two or three. During this time, they join one of the local teams in their daily duties and stand-ups, attend several days of product and architectural training and get to meet the rest of the organization (IT Support, HR, etc). Just the ability to have lunch with the local folks or attend the Friday afternoon drinks is invaluable to learn the faces that belong to the names on Slack.

Ensure access to the same tools

Having your remote team getting access to the same build systems, issue boards, source control provider and package management tools may seem like a no-brainer. But regulatory rules may require your company to segregate internal and external networks and introduce all kinds of complicated VPN/token based tools to connect the two. Having a site-to-site VPN may help here, but may not always be possible. A cloud-based service that supports multi-factor authentication such like AppVeyor, Github, Bitbucket, JIRA and Slack may ease the burden here. But the point being (again), is that if you don’t treat the remote team as your own, don’t expect them to act like that.

Speak the language fluently

I’ve had many disputes with managers about whether a candidate’s lack of English fluency was going to be a problem or not. But I’ve learned first-hand how just how important this is. In fact, one of the agile principles reiterates that face to face communication is the most efficient form of communication. Sure, tools like Slack really help remote teams communicate, but even there being able to convey the subtleties of the English language is crucial to prevent people from misinterpreting your intent. The nuances in particular are a very important aspect of a language. Did the other folks really understand your concern? Or were they acknowledging something they didn’t really get. But not only that. You need to speak the language fluently enough to give you the confidence to feel a full partner in a discussion. Do you feel strong enough to ask the right questions at the right time? I’ve seen many discussions going haywire because the people in involved did not really understand the urban terms, the proverbs and sayings. And keep speaking that common language at all time. As soon as you fall back to your native language and not everybody in your team understands that, you’re excluding them from the conversation. That’s just as bad as using private conversations in your favorite communication tool.

Don’t let hardware get in the way

Did you ever see Tripp & Tyler’s parody on a conference call If so, you know it’s disturbingly close to reality. If not, make sure you do check it out right now. Nothing is more annoying than a bad connection that disrupts the ability to have a constructive meeting. Just being able to book a room with a decent screen, a good camera set-up and a proper Jabra or other professional should not be a difficult task. In fact, I would even recommend a room to have two screens. One to share whatever you have on your laptop’s screen and one to show you the folks on the other side of the connection. Being able to see those people on the other end is the only way to get some visual cues that the message is getting across. And don’t count on your laptop’s microphone to pick up the conversation in that meeting room. Most laptops are equipped with directional microphones which are designed to only pick up the voice of the person sitting in front of it. And all of these is not limited to meeting rooms either. Make sure every team member is also equipped with a decent head-set. The success of remote teams really depends on their ability to call each-other whenever there’s a need for it. Nothing should be in their way. Not even bad hardware.

Treat your remote teams like you want to be treated yourself

Just imagine you’re working for a client as an external contractor on-site, and you’re continuously kept outside of department meetings, not allowed to join the Friday afternoon drinks or given access to so-called social Slack channels. Will you feel part of the team and work as hard as the rest of the team. Sure, you are a professional, so you will do your job the best you can. But it’s unlikely you’ll do more than that. You’re not treated as equals, so why would you go the extra mile. The same can be said about remote teams. If you don’t do your best to treat them as full members of the team or project, don’t expect them to act like that. They may already feel a more isolated because of the physical separation. So invite them to join the trolling Slack channels, give them the same 10% of their time for experimenting alternative solutions and new technologies, and do ask them about their weekends and that conference they visited. Make them feel part of the team.

So what about you?

What are your experiences with working with remote teams? Do you acknowledge some or all of the things I mentioned in this post? And do you have any other great tips for effective collaboration? Let me by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.