Out of all the tools in my training kit, pair writing is my favourite. It is such a radically simple, but deeply powerful way of unblocking writing. Maybe writing is blocked because you’re staring at a blank page, wrestling with how to get your ideas down on paper. Or maybe the blockage is in the collaboration: technical experts and comms experts struggle to come together to agree on what good looks like. Either way, I’ve seen pair writing shift dynamics, and do it fast.
Here’s what it is: two people work together on a piece of content in real time, taking turns to write. It’s really that simple. So how do you make it work?
Pair writing is often seen as a technique for content people to collaborate with technical people, and it’s absolutely good for that. But pair writing can be used for any situation where one person is closer to the subject matter than another. It works just as well when collaborating within a team. If you have to ask a colleague to write some content with you in real time, then you’re pair writing.
As long as it’s just the two of you. Neither person’s manager/wingman/cat is invited. You want a direct, open exchange: no backseat writing.
If you do need to get feedback from a group, techniques such as content crits can help. However, pair writing is more often efficient. There’s less room for group-think, and fewer people involved, so pair writing is less resource-intensive.
Choose your location carefully. Giving and receiving feedback makes some people feel exposed, so try to find a meeting room or a cafe with some privacy.
Do pair writing remotely if you have to. What’s essential is you have a shared view of the draft that you can update in real time — GatherContent or google docs can give you that. You’ll also need a live coms channel: phone or video.
Both people need to know what to expect going into the first session. If you’re introducing pair writing, you can do this by:
- Running a workshop with the team to demonstrate pair writing
- Meeting with the participant (and their manager) to talk through pair writing
- Sending an email before the session
Whatever approach you use, cover:
- how pair writing works
- why it works
- goals and standards
- what piece of content you’ll work on (choose something fairly short, or chunk down larger content)
- what to bring to the session
If there’s anything you need to work on the content, remind your colleague to bring it along. This includes print-outs of reference materials, or a computer with network access.
Both participants need to be on the same page about what good content looks like. That means agreeing on the purpose of your content. User stories are a great touchstone for this – they orient each participant to a person with a need, rather than their personal agendas or preferences.
Also agree on acceptance criteria for your content:
- How you’ll know if the content meets user needs (readability standards, or common user questions answered)
- What writing style guide you’ll follow (having this open during the session is good for referring to best practice)
- Any information that must/must not be included to meet legal requirements
Go into the session with something ready. If you go in with a blank page, you can spend too long finding your feet. This could be a structure (defined in a previous session), or an earlier draft.
Start with one person in the writers’ seat, and the other person sitting close enough to see the screen. It’s often useful to ask the SME to start writing, so they feel a sense of control, and the comms person can model good feedback.
After about 10 minutes, or whenever one of you feels stuck, swap roles.
Allow 1 hour per session – any longer, and you’ll start to burn out.
Use appreciative enquiry
The language you use makes a huge difference to the quality of your collaboration.
When you’re giving feedback
frame your comments in a way that gives the other person room to choose how they respond. Don’t use directive language (like ‘change this’) or interrogate them (‘why did you do X’). Phrases you can use instead includes:
- Have you considered X?
- Tell me more about X
- Is there another way of saying X?
- What user need does X meet?
When you’re receiving feedback
Stay open. Don’t dig in and defend your position. Techniques from Improv theatre can help here. When one person makes a request, try not to respond with ‘No’ or ‘Yes, but’ – these words block the other person’s feedback. Instead, try ‘yes and…’ – accept the other person’s feedback and extend it. There’ll be plenty of time after the pair writing session to review the draft and remove any ideas that are genuinely unworkable.
The best results will often come from an option that neither of you could have considered.
You usually won’t finish a complete draft in the one session. And that’s okay. This isn’t a closed-book exam, it’s a real-world collaboration. Next steps could be:
- One person coming back to the draft to tidy it up
- Scheduling another pair writing session
- Sharing it with stakeholders for feedback
- User-testing it
Other people may need to see the content — senior managers providing clearance, for example. However, this needs to be managed carefully, otherwise all the gains from pair writing will be undone. Ways to manage this include:
- Putting tight parameters around the type of feedback sought (eg, ‘please comment only on technical accuracy’)
- Including a brief with the content on why certain decisions were made