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.
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.
“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.
“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.
“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.
“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.”
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.
“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.