Our New-Year Pairing Experiment

InVision is a distributed company with a good number of engineering teams. Because of the remote nature of the work, it’s easy to start feeling isolated or disconnected unless you put something in place to help combat those feelings. In our case, somewhere around mid January, my team got the crazy idea in our heads that we might be able to curb feelings of remote isolation by finding more ways to work together instead of alone.

As we talked, we began to realize that, by and large, members of the team either really loved pair programming, or were open to trying it more frequently. So we decided to set up an experiment. We determined that over the next few weeks, we would try to pair on everything as much as possible. We didn’t make pairing fully mandatory. But if there was a task that seemed in any way 🍐-able, we were strongly encouraged to make a pairing session out of it.

About a month later, we believe our efforts have been markedly successful. Weekly retrospectives are consistently surfacing a general sentiment of deep enjoyment over the time we’ve spent pairing. Many of us have felt more connected to the team and our personal relationships have grown. We also had one brand new InVisioner (myself) who benefitted like crazy from being able to work closely with others while getting his feet wet.

From a business-oriented perspective (although we don’t have rigorous statistics to back this up), our efforts do not seem to have hurt our efficiency. Our sprint velocity appears to have remained right in line with what it has been in the past. But that’s not really what we want to focus on here. More importantly, we learned a lot about effective pairing during our experiment. So now we’d like to document what worked well for us on our team, in hopes that you’ll have a solid foundation for building even more pairing experiments in the future.

So what exactly do we mean by “pairing”?

When we initially started the experiment, one of the things we considered was the option of “pairing” vs. “mobbing” – the key difference being that pairing is usually thought of as two people working together whereas mobbing is usually thought of as the whole team gathered around a single “driver” controlling the code editor.

What we quickly discovered is that caring too much about these definitions and the conditions for when each technique is more appropriate is a pretty useless endeavor. We figured we could probably just launch our experiment without participation rules and see how it went. If we needed to revise, we could always do so at any time.

With that in mind, this was the breakdown we saw for organic participation over the course of a month:

Between January 14, 2020 and February 14, 2020…

• 32 “visible” pairing sessions occurred. (These were calls posted in our team’s private Slack channel, as opposed to calls posted in direct messages between team members.)
• 20 (~63%) of these sessions had only 2 participants.
• 9 (~28%) had 3 participants.
• 2 (~6%) had 4 participants.
• 1 (~3%) had 5 participants.

As it turned out, the number of people involved in a pairing session sometimes grew organically based on the difficulty of the task, the length of time it had been in active development, and how many previous pairing sessions had already occurred related to that task (probably because, as those numbers grow, so does the desire for more help to get it done). In our case, we never struggled with any kind of paralysis due to having too many cooks in the kitchen.

Given these numbers and the participation scaling we saw, we’ve sort of adapted the word “pairing” on our team to apply to all of this. Whatever happens with regard to participation numbers happens. We usually just call it all “pairing” and that’s what we mean when we use that word in this post. So now, without further ado…

How to get your team pairing

Based on our numbers, we think that a lot of teams will probably discover that some of their members will spend more time pairing than others. We believe this can be ok, but it’s also surprisingly easy to end up with the same couple of folks pairing on everything while everyone else hangs back and works independently. To solve this problem, we came up with a couple of tricks:

Try not to start private calls.

In the beginning, many pairing sessions will likely begin with a private Slack message between two team members in which Member A has identified Member B as the person who likely has the most complementary knowledge base for the task at hand. However, getting the task done more quickly is only a small part of why we pair. We mainly do it for knowledge sharing, bond building, and exposure to other people’s ideas and techniques. So on our team, we tried to move away from starting a pairing call within that private Slack conversation, and instead we started opening our calls in a team-wide channel. This way, anyone who wanted to join was allowed, and if someone else became interested in an ongoing call, they could jump in at any time.

We don’t have an official number on this, but of those calls with more than two participants, many began with only two 🍐-ers and then accumulated the others along the way.

Explain the call when you post it.

As your team gets more comfortable with pairing and with each other, our guess is that this will become less and less necessary. But in the beginning, it’s good for every pairing call you post to have a quick explanation of the goal for that call. While you’re at it, there’s no harm in explicitly calling out the fact that anyone is welcome to join, if for no other reason than that some team members may be a little more reserved. Here’s a quick screenshot to illustrate:

It doesn’t need to be complicated. 😃

Make personal invitations to broaden your pairing partner horizons.

Things like shyness, newness, introversion, lone-wolfishness, health problems, and all sorts of other things can lead to a situation where some team members are pairing less often than others. Again, if this is a personal preference, it’s absolutely ok. But if you spot this, you’ll probably want to just reach out and make sure. One way to work toward ensuring that equal pairing opportunities exist is to take a look at the pool of team members you’ve paired with over the course of, say, a week, and determine which people you’ve worked with the least. Once you identify those people, make a point to personally invite them to pair with you on something. We think you’ll be glad you did.

Preemptively attack the awkwardness.

Even among seasoned engineers and friendly team members, imposter syndrome and a general fear of being judged can make pairing a little awkward. When you’re controlling the code editor and taking suggestions from your pairing partners, those feelings can be amplified. If you have much experience pairing, you’ll probably be able to recount numerous occasions where someone you knew to be highly skilled and fully competent struggled to figure out where to begin, or how to code something that was conceptually pretty simple. And you probably also knew that this was entirely because they could feel you watching them. And this person was probably you, more than once.

Because this experience can make some people a little more hesitant to jump into pairing (and also for the benefit of everybody’s general sanity), we suggest explicitly calling out the fact that these are universal experiences and that we all understand and accept them. Here are some example points to call out:

• A pairing session is not a job interview.
• When you pair, your employment and position at InVision are not on the line.
• We all understand that being the driver is a little weird, and that’s totally cool. No pressure.
• If somebody finds a weakness in your code, it doesn’t mean they think less of you as an engineer.
• Pairing should be fun. Definitely work on your task, but also, it’s ok to hang out and chat a bit.

Embrace multi-person pairing sessions.

One of the things that surprised me personally about our experiment was the fact that more than a third of our publicly posted pairing sessions had more than two people in them. This kind of group work can be great for new hires as we mentioned before, but it can be similarly beneficial for anyone who’s recently changed teams. It provides opportunities to work with as many experienced team members as possible, providing insight into how they reason about challenges within the team’s codebases, areas where the gotchas lie, and the team’s preferred coding styles. The 3-person pairing dynamic is particularly good for allowing a new team member to be a little less active on the call while absorbing knowledge and jumping in to ask questions at sticking points.

Another benefit to multi-person pairing is that having more voices in the room can lead to a smoother code review process. Code can often come out of a pairing session more polished than it would have otherwise been due to real-time feedback and debate. Plus, pairing tends to result in multiple team members already backing a given approach to solving a problem by the time a pull request is opened. Whether or not you want to allow anyone who was involved in pairing to actually review the resulting code is totally up to you. In our case, we feel like we did a pretty good job of judging it on a case-by-case basis.

The hidden benefits of pairing

As our number of pairing sessions grew, we began to dig up a few gems we hadn’t initially expected to find. As it turns out, the added time we spent sharing thoughts and ideas led to a lot of meaningful upgrades we are now making to our team’s systems and practices. We’ll try to categorize some of those hidden benefits here.

Confirming meaningful tasks

Have you ever been bothered by something in the code, but weren’t sure if it was worth the investment to go and tackle? Maybe you let it go because you worried your opinion was the odd one out. Or maybe you weren’t sure it was really worth bringing up in the format of a more official meeting when other priorities seemed more pressing. Try asking what your pairing partners think when the problem shows up during a multi-person session. They may give you just the push you need to get it taken care of.

Multitasking

Have you ever noticed a bug while working on something unrelated, tried to remember to make a ticket when you were finished, but then completely forgot about it? Try asking a pairing partner to make a ticket the moment you notice it, while you and another pairing partner continue to focus on the task at hand. You may end up making your QA engineer’s work a lot easier.

Philosophy upgrades

Have you ever wondered why your team always uses some particular technique that seems strange to you? Try asking about it during a pairing session when you see that technique come into play. Maybe your teammates know something you don’t. Maybe it’s the other way around. Either way, it can make for some enlightening discussion and a great venue for upgrading your team’s philosophies and approaches to problem solving.

The future of pairing

Throughout the course of our experiment, we didn’t spend a lot of time testing out apps and tools specifically designed for pairing. Instead, we relied mainly on Zoom and Slack calls, and whatever conveniences they provided. In the future we plan on digging into this area a lot more, testing out all the apps and techniques we can find. Hopefully we’ll have some updates for you soon.

In the meantime, stop by on Twitter to ask us more about our experiment. Or even better, feel free to share some of your own experiences with pairing. With your help, maybe we can further solidify a culture of knowledge sharing and building relationships in the industry that will last for years to come. If that sounds interesting to you, let’s 🍐 on it.