Pairing Retro

Back at my first job in tech, we paired 95% of the time. Many people were new to pairing. As it was my first job, I was relatively one of the more junior people on the team, which is an especially difficult position to be in for pairing. It was an incredibly intense experience for the whole team with many growing pains. There was a lot to navigate and no set-aside time or structure to do that, so I started having “pairing retros” with my teammates. It made pairing a lot more manageable and I started having better experiences with my pairs. It’s now something I’ve continued to do throughout my career.

The concept is fairly simple. Set aside a time when you’re not pairing, to talk about pairing.

Format:

Time and Location

Set a time, should be after at least two or three sessions, so you have something to talk about. You may want to set it at the beginning of a pairing session so that you’re talking when you’re away from the code and you have some distance from your last pairing session.

I tend to try to steer people towards private meetings if I can. This is especially important if there has been any contention, but even if there hasn’t, it allows people to speak more freely. Additionally, it allows distance from the work at hand.

If remote, I try to make sure to show my face to get a sense of facial reactions. Your results may vary. Maybe you find that it’s easier for both of you to talk about more challenging topics without seeing each other.

On average, I’d say you need about fifteen minutes for the whole session, but they run the gamut, and I’ve had more than one hour-long session that transitioned into whiteboarding.

Start with a few positives

Start with some “I likes”. Think of positive moments pairing together, whether it was sharing a joke or a good moment of collaboration.

Examples:

• “I felt like I was getting a little lost in the details at one moment, and you kind of pulled us back.”
• “I liked the task list we put together in the last story. I felt like that was a good way of attacking a big story.”
• “It was a lot of fun pairing.”

The purpose of this is twofold, one is that it primes your mind to think of the positives. The second is that it builds trust and helps each other know what’s working to build on. You’re aiming to go from something potentially awkward, towards something really positive. And even if you really like your pair and respect their work, that may not be obvious to them and it’s good to call it out explicitly.

Additionally, take this time to apologize if you feel like you haven’t been as good of a pair as you could be.

Examples:

• “I wanted to apologize, I’ve had a lot going on in my life personally and I haven’t been feeling as focused as I’d like to be.”
• “In our last pairing session, I felt frustrated with where the story was and stressed by the deadline. I’m sorry if any of that tension came through.”

Discuss a story

Pick a story or two and talk through them. Mention any decision points or places where you got lost.

Examples:

• “That story was really long and the requirements were not explicit.”
• “I felt lost at a few points and had trouble following what you were doing. I don’t think I understood your design right away.”
• “We ended up having to adjust our code after talking with the product manager. I wonder if we should have reached out to them earlier.”

Ask further questions

Then make sure to ask any of the remaining questions that you still might have.

Examples:

• “Is the tech working for us? It’s been seeming a little buggy. I have been having trouble hearing sometimes.”
• “Do you feel like you get enough time driving? I felt like you weren’t grabbing for the keyboard, but maybe you wanted to drive more and we can figure out a different way to switch back and forth.”
• “I wasn’t sure whether I could interrupt you. You were kind of looking out into space at some point and I couldn’t figure out whether you were thinking about the problem and needed space to think about it or whether I could interrupt with my thoughts on it.”

Problem solve

You can problem solve as each issue comes up, but make sure you listen first, problem solve last. In order to have a productive pairing relationship, you need to have trust to share your ideas, even your stupid ones. You need to have trust that you’re heard. You need to have trust that even if your idea was discarded, it was considered. What you need above all else is trust in one another and trust is built by listening. When you don’t get to some of the emotions, the root of the issues, you gloss over the problem. Problem solving is the syntactic sugar of pairing, trust is the core. So, solve your problems when you pair, but make sure that you’re listening fully before you dive in to problem solving.

Examples:

• “So you didn’t feel like you could participate as much as you’d like. Is that a tech problem where we could attempt to liveshare through our editors, or is it more of a process issue where we could potentially do better with the constraints we have.”

Voila! Pairing retro is done!

What a pairing retro isn’t

It’s not a place to give feedback on skills or career advice, unless specifically asked for. It’s not a traditional one on one. It’s also not a place to discuss your issues with their workflow.

It is a place to have a discussion on the blockers in the way of a better pairing relationship. Keep your discussion contained to issues that are potentially solvable and that get in the way. Keep your comments organized and focused if there are a lot of them, especially the first round. Don’t be afraid to use good judgement to reduce the topics to a small and manageable list of the most solvable issues and work through those.

A note about conflict

If you’ve had any tension or conflict in your pairing relationship, approach it in a very blameless manner, talking about what you felt and experienced, and definitely double down on listening. People have a lot of emotions wrapped up around code. It’s more than code for many people, even if they never admit it. It’s identity, intelligence, sense of value (to society, to the company, and monetarily). Don’t make the mistake of solving the “problem”, but not repairing the relationship.

Each pairing relationship is different and people have to find their own rhythm for working with one another. A lot of people try to read XP books or tech blogs for advice on how to be a better pair. In many cases, reading relationship books are one of the best things you can do to become a better pair, because pairing makes it ever so clear how much your work revolves around relationships and how much work that actually is. If you’re looking to have a more difficult conversation, I’d start with the advice in these blogs, to give you a sense of what not to do: https://www.gottman.com/blog/the-four-horsemen-recognizing-criticism-contempt-defensiveness-and-stonewalling/ and how not to do them: https://www.gottman.com/blog/the-four-horsemen-the-antidotes/

Results

If you’re wondering what topics you might end up discussing, I put together a list of common issues that come up during pairing.

Technology

• IDEs / text editors
• Remote: Headphones, call tech and other remote pairing tech. Background noise is especially a big deal.

Logistics

• Breaks
  • Do you forget to take breaks when you’re pairing? Are you finding the breaks disruptive? Do you think it’d be helpful to take breaks when you reach an impasse?
• Who’s driving?
  • Ping Pong pairing (one writes the test, the other makes it pass)
  • More junior person / newer person drives
  • Switch back and forth (sometimes with a timer)
  • Side along (code monkey / research monkey team, each with their own laptop)
• Discussions outside of the laptop
  • Whiteboarding problems or writing them down instead of coding them at the moment can be effective at getting everyone on the same page and understanding each other’s design.
  • Going for a coffee and discussing overall thoughts, instead of dealing with the file right in front of you.

Rapport / Relationships

• Remote: Not being able to see facial expressions or recognize cues means you don’t always know how someone is reacting to something.
• Understanding why people react to things the way they do, and understanding whether you’re reading their emotional reactions correctly.
• Articulating ideas and whether you’ve been able to both properly talk through your concepts and understand each other’s
• Understanding whether you’re both conveying mutual respect for ideas
• Conflict. People have a lot of emotions around code and when you pair with someone, that very clearly comes out.
  • Repairing a previous conflict, including apologizing when appropriate
  • Talking about the feelings around a conflict, however small, including when one pair felt unheard or unacknowledged
  • Talking about how to get through future incidences of frustration and tension in a more productive manner, including understanding when you’ve hit that state or are about to and how to de-escalate

Idiosyncrasies and personal working styles

• “All the tabs” versus “zero inbox” personalities
• Visual / Kinesthetic / Auditory learner
  • For someone who is a visual person, sometimes whiteboarding an issue can be a more effective way to work through an issue.
  • Some people find talking about a topic away from a keyboard to be more effective.
  • Some people need to touch a keyboard to understand what is going on and be involved.
• When to interrupt and not interrupt people when they’re thinking through difficult problems.

Illustrations by Lo Wheelwright.