How Pairing Powers Remote Teams

Over the past few months, Customer.io has grown from ten people to almost 20, and our engineering team has more than doubled in size. With such rapid growth, getting everyone up to speed is a major challenge.

But it has worked out well so far! All our new developers have hit the ground running, learned how the product works, and made contributions in their first few weeks.

How are we making this work? Remote pairing.

As one of the new engineering hires, I’ve been really keen to pick up as much as I can from everyone on the team. So I’ve been pairing with other members of the product team, working together on building features, stomping on bugs, and writing tests.

Pair programming is normally done with two people at one desk, sharing a single computer. But because we’re a remote company with a team distributed throughout the world, that isn’t really an option for us.

So instead, we’re using our high-speed internet connections to work together virtually. Every day, we share our screens and text editors, discuss plans for features and bugs, verbalise our thought processes, and collaboratively iterate on new features for our product.

How to Pair Program Remotely

Remote pairing used to be tedious — fiddling with firewalls, forwarding SSH ports, configuring text editors, and fighting with internet voice quality. The result is that remote teams often avoid pairing altogether, instead focusing purely on asynchronous communications by chat, email, or issue trackers.

But real-time and face-to-face communications are really important, both for working happily and efficiently. Asynchronous and text-based communications can easily lead to misunderstandings, and the high turnaround time can lead to frustratingly long conversations. It’s often much easier to grab a colleague for 5 minutes to hash out a solution, which could take days to reach using email.

There’s usually some good overlap between timezones.

Fortunately, remote pairing is now really easy! We use Screenhero, which is a video-based pairing tool and is part of Slack. When a colleague and I want to work together, we just schedule a time via direct message — it could be in 5 minutes, after lunch, or first thing the next day. Two clicks and we’re sharing our screen and voice chatting.

From there, it’s almost exactly like working with someone at my desk. I can see their entire screen, we both have independent mouse pointers, and either of us can type. Video and voice over the internet work pretty much seamlessly, so we’re always in contact and on the same page. We take turns typing, suggest improvements or catch typos, bounce ideas off each other, and share knowledge.

Why It’s Important To Pair As A Remote Team

We’ve found pairing to be particularly useful in our remote team for lots of reasons. The biggest wins: better collaboration, more effective bug fixing, and faster feedback cycles.

Two-Point Perspective

It’s much easier to work on the product when you’ve got the benefit of two points of view instead of just one. Working alone is great for focus and one of the blessings of remote work, but sometimes it’s more useful to have a wider view. There’s huge value in having someone there with you to question if this is the right way forward, or suggest a course correction.

This can also be useful for building consensus in small teams. It’s easier to see the reason for choosing a particular solution to a UI or engineering problem when you’ve also been there to see the alternative approaches that didn’t make the cut.

Our habit of frequent pairing sessions helps establish a culture of collaboration. We work on our product together every day, not in isolated teams of one, and it’s much better for it.

Double the Brain Power for Squashing Bugs

Working remotely from the rest of the team can make fixing bugs particularly difficult. If you’re stuck, you can ask for help, but if everyone is working independently it could take hours to get a response to an email or a Slack message. When you can’t glance across the room to check if someone’s concentrating, there’s a social barrier to interrupting them.

Because we’re screen sharing and pairing every day, this is less of a problem for us. It’s so common to pair for just a couple of minutes that we don’t stay stuck without help for too long. Working together on a problem is normal, so there is no implicit expectation that one person must always be able to complete a task alone. This makes it much easier for each of us to ask for help when we need it.

Pairing is also great for preventing tunnel vision: getting so focused on a particular theory for a bug that you spend hours going in the wrong direction. Having someone else there to break tunnel-type concentration and suggest a different approach stops this from happening.

Reducing Latency

One of the biggest bottlenecks in a distributed software team is latency. No, not screen sharing lag, but the time taken for work to be reviewed. All of our software is peer reviewed, and the realities of multiple timezones can mean that a couple of iterations of feedback can take several days.

Jumping into a pairing session early on can really help with this. It means that our later reviews are normally just catching style mistakes, or suggesting small fixes. You’re much less likely to waste a couple of days of work going in the wrong direction if you have someone there with you to help with the big picture.

Because there’s no effort in getting started, we can easily pair up for a few minutes to help get unstuck, or for half an hour to explain a domain concept. It’s also great for a quick handover when timezones overlap. All of these kinds of communication are vital to keep us running productively, and screen sharing with voice is one of the most effective ways to achieve this.

Sharing Knowledge

For me, whether remote or in person, the most important reason for pairing is an obvious one: learning.

I’ve already learned a ton of things from my new colleagues, and I’ve been able to teach them a little of what I know too. This can be something as simple as a neat Vim trick, or as involved as the history of a collection of software components. Every time I pair with someone, I get a little better as a software engineer, and those tiny improvements add up to create a more effective engineering team.

Do you pair program remotely? Share your process with us on Twitter!