(note to self: stop with the jokey bad grammar, peoples might think you cant be writing good)
I’ll say this quietly because I’m a little apprehensive but, for the next few months, it looks like we will have extra resource in our team. Basically we are ahead of the curve when it comes to recruiting so, until the rest of the R&D team catches up, we are one technical writer up!
Which means that we are taking the opportunity to both get ahead with some things, and catch up on others, and one of the things we’ve never tried here is to have a formal editoral review of the content. Peer review is one thing and whilst the technical content we produce is excellent, the differing writing styles and approaches each writer has does show through.
I’ll be the first to admit that I’m not all that bothered by this, simple business reasoning dictated that we concentrate on improving the accuracy and timeliness of the documentation and so, now we have done that, we can turn our attentions to other areas including findability and clarity.
The latter finds me taking on the role of Editor (I want to write Editor-in-chief just to conjure up images of a smoke filled newspaper office in the 50s), casting an eye over all of the content we produce and using our lightweight Writing Style Guide to prod and cajole the content towards something that, without being too restrictive, has a level of consistency for the reader.
As we haven’t had anyone performing that role before, it’s taking a bit of adjustment and the jokes about the “red pen” are already flying. Thankfully I work with smart people and it’s not taken long to see the results come to fruition.
What we need to figure out is how we change this model in the future so that we can all consistently edit each other’s work, lest I become a bottleneck in this process.
When I worked in a TW group that had a formal editing process, the head editor had developed an editorial checklist with 3 sections. A copy of the editorial checklist was attached to the final review copy of every document and filled in and signed by the editor before it was released.
One section had a list or organizational issues to be reviewed, the second had a list of grammar and stylistic nits to check for adherence to the specified style guide, and the last section was a checkoff section that appropriately versioned archive copies were saved in the appropriate directories, and that copies of the release information were sent to the required parties.
If the Editor was unavailable, or when there was more work than the editor could handle, others who didn’t regularly edit documents could also use the checklist to make sure they covered all the required items in their edits.
I recommend that you create such a checklist appropriate for your organization’s documentation review process.
The checklist is a good idea. Also might be a good idea to develop an in-house stylesheet to resolve the differences between writers’ approaches. Editing the documents will give you better documents in the moment, but a stylesheet that provides guidelines will help you going forward as well.
We’ve suffered a bit from the lack of editorial time. It’s tricky to juggle the quick pace of Agile and the need for a solid editing cycle. I usually get my work reviewed by at least a business analyst or product manager, but another tech writer’s eyes on the content would be great. We talked recently about getting an intern on the team to help in part with editing our work.
As you’re doing, I’ve taken some lighter times to go back and make sure I’m following the style guides we use.
Comments are closed.