Why I left contract technical writing

Photo by Franck V. on Unsplash

I spent a large part of my technical writing career working as a contractor. It was a formative part of my career where I got to focus on doing the work and got experience working in such industries as telecommunications, financial services, and even worked in an NGO. I’d work on a 1099 or W2 contract often through a third-party contract house but sometimes not.

Continue reading “Why I left contract technical writing”

Simple guidelines for running technical document reviews remotely

With some clear expectations and a little planning upfront, running remote writing and document review projects can go smoothlyHere are some lessons I learned when I was a freelancer about running remote writing and editing projects:

Continue reading “Simple guidelines for running technical document reviews remotely”

Building the better technical editing and QA cycle

Photo by Avi Richards on Unsplash

It’s rare when I don’t hear complaints about the technical editing and reviewing of documents and the QA cycle in general. It’s unfortunate because building a document QA process that’s supportable and replicable

Here are some considerations to keep in mind when building a technical editing and QA cycle for your documents:

Establish standards and styles

Technical editing is about standards — you need to put some document writing standards and styles in place if even informally. Writing a style guide can be a major commitment.

Set expectations for document reviews

I always recommend that organizations set expectations for technical editing and reviews. With today’s harried schedules, my recommendation is an iterative review cycle. Just give your reviewers expectations for the document at the end of each review pass.

Manage and use document templates

Microsoft Word documents can be both a boon and a drag on productivity. I recommend that you and your team both manage and use document templates for all your documentation. Managing templates includes documenting the styles writers should use; being responsive to any template issues, and promoting proper template usage.

Use document versioning and workflow

Use Microsoft SharePoint or some other online collaboration platform for document versioning and workflow adds security and transparency over the process that sending email back and forth cannot touch. You can always roll back documents to a previous version.

Have the editors use the technology

Anybody you task to edit your technical documentation needs to use the technology. Nothing can go further to discredit the technical editing of a document than changing the meaning of technical content and the out and out introduction of technical inaccuracies. While this may not always be feasible, being hands-on with technology is one thing I strongly recommend for all technical publications people because it helps them be more self-sufficient among other things.

Instill the importance of technical accuracy

Somewhere along the line, the myth that technical writers and editors don’t need to be technical somehow began to perpetuate itself. This tale is just not practical and wrong on so many levels especially in today’s down economy where all project team members have to carry their weight and then some.

Attention to technical accuracy throughout all phases of the technical editing and quality assurance process means no last-minute rush of having to edit where the editor has changed the technical meaning.

Develop a constructive dialog between editors and writers

Technical communications is a team effort whether it is publishing a user guide, technical article, and about any technical content. Neither the writer or editor is the last bastion of quality (or at least they shouldn’t be), so it is prudent to foster a constructive dialog during a technical editing and QA cycle.

Questions back and forth between the editor and the writer are a good thing. You want them to resolve issues upfront that leads to changes in technical accuracy in the document.

Manage and take ownership of the process. Locking a technical document up in an endless review cycle doesn’t do the document or the team any good. Build a transparent process that is easy for all participants to follow does wonders for putting out a quality document.

My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.

4 reasons why your document reviews aren’t working

I’ve long been a student of technical document reviews. So much so, I worked as a technical reviewer for some computer book publishers to learn more about this critical element of the technical communications. Back then I thought I could do a better job than the reviewers where I was working at the time). Editorial and technical reviews are integral parts of the technical publications process. Unfortunately, so many organizations fumble through the review cycle.

Continue reading “4 reasons why your document reviews aren’t working”