Here at Cultivate we spend the majority of our time pairing, as it helps us to problem solve, share expertise, and craft solutions. We believe that pairing is a skill that can be developed and improved like any other, and that it takes active effort to do so.
In this blog I’m going to talk about some strategies that we are experimenting with to help us improve this skill and work more effectively together. Whilst suggestions to help improve pairing often focus on behaviours during pairing, I’m going to focus on things that you and your pair can do before and after pairing to plan and review how you work together.
Working with someone for the first time
There are a range of things that might impact on how well two people work together: differing communication styles, levels of knowledge about the domain, and approaches to investigating a problem to name a few. These differences are the source of both the benefits and challenges of pairing as having varied perspectives might lead to a better solution than either person would have come to alone, but working in a way that doesn’t suit your style of thinking can be frustrating.
One thing we can do to mitigate these frustrations is to try and understand each other’s preferred modes of working, learning, and communicating at the outset.
As mentioned in Erik’s post we have been experimenting with having ‘kick-off’ sessions when we begin pairing with someone for the first time. The purpose of this initial session is to try to understand what your pair needs to work effectively and vice versa, and then use this information to identify potential pain points and come up with strategies to mitigate them. Here are a few approaches that we have used to structure this discussion and found to be successful:
Bring a simple list of questions to work through
Create a shared document where you can both write any questions that you think it would be useful to answer before beginning your work together. Try to include questions that cover communication styles and how you prefer to investigate problems or approach knowledge that is entirely new. Here are some example questions to get you started:
- How do you prefer to investigate something that is new to you?
- In what conditions do you find it easiest to speak your mind?
- Is there anything you’re hoping to better understand through this piece of work?
Use the Searls-Briggs Type Indicator
I have used the categories in this blogpost about types of programmers to frame a discussion about working styles. It gave us a really useful language to describe how we work, as well as making us reflect on things that we may not have considered before. We went through each category and discussed which letter we most strongly identified with, and what this might then mean in the context of pairing.
Once you’ve talked about your individual styles, you can then come up with approaches that will help you work well together. One example of this might be that you and your pair have very different ways of investigating a problem: you like to experiment your way to understanding the big picture, without worrying too much about getting to grips with each small element of a potential solution. Your partner might prefer to thoroughly explore each of the key components before they’re comfortable moving on to thinking about the overall solution. By highlighting this difference up front you could avoid getting frustrated by agreeing that you’ll investigate separately before coming together to share findings.
As you work you’ll identify information that you would have found useful to ask at the outset, but didn’t. That’s ok! The point is to establish a foundation of understanding that will help you to be aware of how to get the best out of each other. As these sessions become ingrained into the way you work with other people, it’s likely that you’ll identify the most useful things to be discussing at the outset.
Starting a new piece of work
The suggestions in the previous section are most useful when you’re pairing with someone for the first time. In addition to these suggestions we’ve found that there are a few things worth discussing at the beginning of each new piece of work you’re pairing on, regardless of whether or not you have paired with the person before.
If you have worked with someone many times you may have an idea of their technical proficiency with the stack you’re working on and the domain of the problem. However, it can be useful to have an explicit discussion about your relative knowledge and understanding of the problem so that you don’t make assumptions about what the other person does or doesn’t know.
This can help ensure that you work more efficiently: working quickly through things that you are both confident with, and slowing down when one or both of you feel less sure. It can also aid you both in achieving any personal goals you have relating to the problem, stack, or domain that you will be working on.
Here are some sample questions that you could ask in this type of preparatory discussion:
- What is your current level of comfort in the tech stack?
- What is your current level of comfort in the system?
- What is your current level of comfort with the domain
- What do you want to achieve in the code that we’ll be working on?
- What do you want to achieve in advancing your understanding of the tech or system?
This approach can be particularly effective when there’s a significant difference in the experience levels of the pair. If you are less experienced, it can feel intimidating to work closely with someone who you think knows far more about the work at hand than you do. This can lead to an inadvertent student-teacher relationship where you defer to their knowledge and don’t feel equal ownership over the work. Similarly, as the more experienced person in a pair there can be pressure to supply answers even when you are not familiar with the domain or tech stack. Discussing this upfront should help to mitigate these issues, and make it easier for everyone to be an equal contributor.
Pairing Retro
The final piece of the puzzle is to ensure that you and your pair take time to review how you’ve been working together, and come up with actions for the future. At Cultivate, we have experimented with doing this in the form of a ‘pairing retro’.
The point at which you choose to do have a retro is entirely up to you: It will depend both on how long you’re pairing together and whether or not there are any pain points that need immediate attention. The important thing is that you focus on your pairing, not the work that you paired on.
Here are a few questions that could act as a broad structure for your review session: * Did we meet our goals for the session/time period in question? * Next pairing session, what are the things you might like to work on? * What did we do well? * What could we have done better?
One approach to a pairing retro that has worked for some people here at Cultivate is to start by explaining how things have being going from the perspective of your pair. Here’s an example of what that might look like:
Kate: “I’m Dave. I’ve found the past few days interesting but I got quite frustrated when Kate wanted to work slowly through a solution to understand it fully, when I was already sure it was the right approach to take”.
Although it might feel a bit strange at first, this can be an interesting way to explain the assumptions you’ve made about what your pair has been thinking, and prompt self reflection about how your behaviour might have impacted on them. It can feel a little easier to frame comments as analysis of your own behaviour and its impacts, rather than jumping straight in to highlighting things about your pair’s behaviour that you want to address.
This approach also gives you both a chance to refute assumptions your pair might have made, and so help to clarify the true intent behind individual behaviours. Sometimes just understanding why your pair has been operating in a certain way can ease an issue, without any changes to behaviour.
Whatever structure for the retro you choose, being open and honest with someone you’re working with can be really difficult, especially if you want to talk about something that didn't work for you. This is further compounded by the fact that you’re speaking to a colleague that you will be working with again in the future, or even immediately following the retro! To help us express things that haven’t gone well, whilst maintaining professionalism and empathy, we have tried is using the ‘Situation-Behaviour-Impact’ model of feedback discussed in Radical Candor:
Situation: the context or types of situation where you observed the behaviour
Behaviour: the behaviour that the other person exhibited
Impact: what effect your pair’s behaviour had on your ability to work well or understand the problem
Although this doesn’t take the awkwardness out of raising a problem with your pair, it might help keep you focused on behaviours that can be addressed, rather than personality traits. Having discussed these behaviours you can then identify approaches that will mitigate their impact in the future, as you did in the preparation session.
Summary
At its heart, effective paring is reliant on effective communication, which is a skill that can be developed like any other. The strategies above are tools to help you think critically about your pairing and improve how you work with others.
If you try out any of these techniques or if there are any other approaches to improving pairing that you’ve found effective, let us know!