Inspired by the extreme programming movement, at Articulate we put two writers on every project in a process we call 'pair writing'. They do research interviews together, then one writes and the other edits, flipping back and forth until the copy is just so.
Pair writing: the heart of our process
Learning how to edit is an essential part of good writing: behind every great writer there is a great editor.
Ego-less feedback is an important part of a writer’s development but on a more practical level, it is almost impossible to proofread your own copy immediately after you have written it. A second pair of eyes is actually a necessity.
There’s more. Pairing people on writing projects provides other benefits:
-
Resilience. We can still hit deadlines if one person is sick because there are two people who know what’s going on.
-
Higher quality. Two brains are better than one – that’s why they put two pilots in the cockpit.
-
Shared practices. We harmonise our working practices and share experience.
-
Training and development. Pairing a new writer with an experienced one is good mentoring.
-
Nobody is more important than the work. Everybody writes. Everybody edits. The boss gets feedback from the most junior intern and vice versa. This is our culture.
-
It's more fun. Writing can be a lonely business. Sharing the work means you have shared experience of it.
-
Good for fact checking and sourcing. Having two people on every interview, both taking notes, means you have better coverage of what people said and better notes. This helps with getting quotes and attribution right.
Ground rules
There are some formal and some unspoken ground rules to the process:
-
Be gentle. We give feedback, not criticism.
-
Positive feedback is essential. Writers respond well to praise (who doesn’t?) so we highlight things we like and we give lots of positive feedback.
-
Change control. We use Word’s change control feature so that everyone can see what’s changed. This is a useful learning tool for new writers. For blog posts, at least in WordPress, we use the brilliant EditFlow plugin.
-
Style standardisation. We have a company style guide that covers a lot of routine questions like ‘do we use single or double quotation marks’. This is important for consistency.
-
Subediting vs. editing. Often, an editor will make changes to the text directly. Mostly this is subediting – just light changes for style, concision or emphasis – along with proofreading. Sometimes, they will make broader changes to the structure or content of an article but this is rarer. More often, if something needs reworking or isn’t clear, we use comments to give the writer some idea of what we think is going wrong and some suggestions for improvement.
-
Version numbers. We add v1, v2, v3 and so on to the end of the file name so we can track versions. For complex pieces, v1 is just a list of points, data and sources, v2 is a ‘shitty first draft’ and v3 is the first editable version. (And if you’re wondering, the highest we’ve gone is v22 but that was a piece that was being reviewed by HP, Microsoft and Intel’s legal departments so we had a lot of feedback to process!)
-
We take turns. Only one person works on a document at any given time and there’s a formal handover in Basecamp from one writer to another. (Committee editing in Google Apps is the opposite of this approach. If it works for you, great. But for us, it’s incredibly frustrating because there’s no ownership, accountability or versioning.)
We're great admirers of Pivotal Labs. For them, pair programming is part of their marketing as well as being at the heart of what they do. We believe that pair writing plays the same role for us here at Articulate.