Collaborating with a remote software team?

These three lessons will help you on your way.

David Pellerin is a Senior Tech Lead at TWG. This article is based on a presentation given by Pellerin at TWG #FridayDemos.

We recently completed a project with a fast-growing e-commerce company that needed support for a social media platform integration. Based on what we learned, here’s some reflections on the best ways to integrate with remote technology teams.

For this project, the team consisted of:

  • 3 full-time Rails devs (1 client, 2 TWG)
  • 2 part-time Tech Leads (1 client, 1 TWG)
  • 1 part-time Product Manager (TWG)
  • 1 part-time Front-End Developer (client)
  • 1 part-time Product Manager (client)

Lesson One: Teamwork makes the dream work

We love working with other software companies. Technology is in their DNA, they have a defined roadmap, talented engineers and product managers who care deeply about their teams. They also have an exceptional level of trust between their teammates, and their own well-defined processes and ways of doing things.

Our goal for this project was to be completely transparent. We wanted to slide seamlessly into our client’s team, working alongside them as fluidly as possible to help them out with this integration. That meant breaking down as many barriers between “them” and “us” as possible, making sure that everyone involved with the project really felt like they were part of the same team.

Lesson Two: Face-to-face is still ace

The bulk of the work that happened on this project happened remotely. Some of the collaboration tools we used are listed here. Products like Slack mean that integrating with remote teams is easier than ever, but we’ll always be fans of the real getting-to-know-you that happens in person.

  • The strongest partnerships will always be the ones where teams can meet face-to-face. The most important time for IRL facetime is at the beginning of a project. Learning what makes your teammates tick puts you in a great position to problem-solve together down the road.
  • Being able to quickly connect in person reduces the amount of time you spend overcoming specific hurdles. That’s one of the reasons our clients all receive an open invitation to come and work alongside us at our studio. For this project the client took us up on this offer, and we were able to sit side-by-side to solve some blockers that probably would have taken longer to address remotely.
  • When geographical constraints mean that’s not possible, the trust and rapport you’ve built with your team at kickoff will set the tone for a strong remote collaboration.
Nail the basics, and you’ll be cracking jokes together on Slack in no time.

Lesson Three: Create your collaboration toolkit

Different teams have different ways of doing things. The truth is, there’s no “silver bullet” for solving human interaction challenges. Here are some of the tools we use at TWG to make remote collaboration easier:

  • A private Slack channel. This is where everyone working on on the project hung out, and where the bulk of our communication and collaboration took place. We ran Slack Standups every morning at 10am to keep the team in sync.
  • A GitHub private repo for collaborating on code. This was owned by the client.
  • Google Hangouts also works well for screen sharing, and is a good group video tool that allows for up to 8 collaborators free with no plugins.
  • OTR Encryption Chat was our tool for sharing sensitive information. Adium has an Off-The-Record (OTR) mode that is end-to-end encrypted. (passwords & auth tokens)
  • We’re currently trialling some USB conference phones for our boardrooms, and we’ve been using UberConference for group calls.

Remote collaboration challenges and solutions

There are some of the biggest challenges we’ve encountered when collaborating remotely, and things we’ve done to help make things better.

  1. Audio issues
  2. Team resourcing
  3. Building with limited information

  1. Audio issues

Solid audio remains one of the biggest pain points when trying to collaborate remotely efficiently. Using headphones with a microphone has been the easiest audio win for us, but it’s still far from perfect.

We also made our studio space more conducive to remote working. Installing carpet tiles and sound dampening panels in our boardrooms to reduce echo has made a huge difference.

2. Team resourcing

Having a clear understanding of resourcing, and getting commitments from the client about their team’s availability at the start of the project, is important.

However, be prepared for things to change at short notice. Resourcing can (and usually will) shift unexpectedly. That front-end developer you thought you had? They’re gone. They were needed elsewhere, urgently.

Put yourself in your client’s shoes for a minute. Fast-growing companies have fewer resources than they need to do everything they want to do. Priorities are constantly shifting, and that means resources need to be deployed strategically.

Things happen when you’re building a gigantic piece of software that huge numbers of users rely on. Your particular project might be feeling the loss of a team member. But the reason they’re not around is because they’re off solving a bigger problem for your client somewhere else in their business.

Being a great team player means understanding that your project might not be the most important thing that’s happening right now, and stepping up to problem-solve when resourcing affects your project.

In this particular case we had less access to a front-end developer than we had planned for. So we kept things moving by making all of the data available as we went so that they could jump in and drop in the required graphics when they could. We also kept strong, open lines of communication with the client so they knew to what extent the project was being impacted by the changes. As a result, as the project progressed, our front-end friend became more and more available.

3. Working with limited information

With this project we were developing locally without access to the client’s vagrant image. This can feel frustrating when working on a product that’s been built a specific way, often for a number of years.

But there’s usually a silver lining: Approaching the project without access to the client’s Vagrant image opened up a new way of working with their system that they can re-use on future projects involving strategic partners.

Conclusion: Your client’s overall priorities and the project priorities might not always line up. And that’s OK.

Truthfully, none of these challenges really bothered us too much. We know that even the smoothest projects are never perfect. That’s why building rapport at the beginning of a project is so important. When everyone on your project team is comfortable being completely honest with each other, changes can be dealt with swiftly and efficiently, even if you can’t be in the same room.

One of the best things for us about jumping in to support a client on a project like this is that we get to build new, strong relationships with people who share our deep love of software. Physical interactions will always be the best way of strengthening these relationships.

Looking for a technical speaker for your next event? Contact us at to book David or another member of our software team.

Visit us at to learn more about our mission to build the most innovative enterprises and startups in the world.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.