What is a Technical Author?

"So, what is it that you do?" A simple enough question, and one that I get asked just about every time I meet someone new. I personally consider myself to be a Technical Author (a.k.a. Technical Writer, Technical Communicator, etc.) but few people outside of the industry understand what this means, so my stock answer is usually "I write documentation." Unfortunately, this barely does the technical authoring profession justice.

True, Technical Authors do write documentation, but the writing is only a part of it. Before we get as far as putting pen to paper (or finger to keyboard), there is requirements gathering, audience analysis, document type selection, media selection, layout design, and possibly prototyping. Even the writing itself involves more than just writing. It encompasses drafting, commissioning illustrations (or, more often than not, producing your own illustrations!), facilitating document reviews, proofing, editing, rewriting, rewriting and rewriting again (following the inevitable last-minute design changes), and finally obtaining approval. Once the ‘writing’ is over, there is still the reproduction, binding and finishing, and distribution to consider. And once the document is finally released, there is still revision handling, version control; update distribution, and so on. All in all, there is far more to technical authoring than just writing.

A 'document' is any form of written communication

So much for the ‘writing’ side of ‘writing documentation’. What about the ‘documentation’ side? In technical writing parlance, a ‘document’ is pretty much any form of written communication. It may be a design document, a product proposal, or an entire suite of support manuals. It may be a user manual for a software application, or a user manual for a hardware product - with ‘hardware’ being anything from a mechanical pencil to a nuclear reactor. It may be a marketing proposal, a technical paper, or just about any kind of report.

On top of this, the written ‘document’ may not even be a traditional paper ‘document’. It could take an entirely different form, such as a wall poster, a warning sticker on a piece of machinery, or a keyboard template. Nowadays, more often than not, the document will be an electronic document, such as a web-site, a help file, or an on-line tutorial. Or the documentation may be built directly into the product it refers to – via an embedded user assistance, electronic performance support, and more descriptive error messages.

A Technical Author is also quite likely to be called upon to perform information design - not just of their own written documents, but also of just about any other type of printed documents. These documents may be data collection forms, business documents (such as invoices), system-generated data reports, and so on. Wherever technical information is gathered and displayed (on screen or on paper), the Technical Author is there to ensure that the correct data is displayed in the most effective way.

The Technical Author as Documentation Manager

All of this is the bread and butter of the Technical Author. But this is only half of my job (as is the case for many Technical Authors). The other half sees me assuming the role of Documentation Manager. Documentation management is effectively project management for documentation projects. In keeping with ‘regular’ project management, it involves building a proposal, providing estimates, budgeting and scheduling, building a team, providing status reports and progress chasing, and so on.

Unique to documentation projects, it involves implementing a documentation (or ‘publications’) strategy (types of documents, method of production, method of delivery), defining house styles and standards (and ensuring adherence to these), and building templates. More often than not, it also includes ownership (and sometimes development) of the Document Management System. Documentation management also involves ensuring that quality assurance processes are in place, that the review and approval process is accepted and followed, and that the relevant infrastructure (hardware, software, services, and so on) is in place so that the Documentation Team can do their job.

So that’s what I do all day. That’s what I love to do all day. If you think your company could benefit from some of these technical authoring skills, then drop me an e-mail. I’d love to help.

Dirk Manuel