What is a Technical Writer?
A technical writer (technical author) is a person who writes fluently on a technical subject.
Since writers need to understand what they are writing about,
a solid background in engineering is required.
The subject is typically a product or service that is sold by a company,
and the written document is often formal description of that product or service.
A technical writer is not a translator
(indeed, most technical writers take their input in their native language,
and generate their output in the same language).
Unlike a translator, who takes a finished document in one language,
and converts it to a finished document in another language,
a technical writer takes rough notes and drafts
(from the engineers, for example),
and produces a finished document, usually in the original language.
Normally, therefore, there is no translation involved in the work of the technical writer
(here, for instance, is the
Wikipedia definition
of a technical writer,
and a brief bibliography).
However, for a technical writer writing in English while living in France,
and therefore taking input from French engineers,
there is inevitably some aspect of translation also involved.
The two jobs are, indeed, complementary.
The multinational companies are already
convinced that they need to have their documentation written by a specialist –
by a technical writer.
They already employ, or out-source, large teams of technical writers.
These are engaged full-time,
and are considered to be part of the support staff
(paid for by the increased profits, and decreased overheads,
on the production line and sales).
Small and medium sized companies, though,
cannot afford to maintain support staff for 52 weeks in every year.
So they tend not to employ any at all,
and to make do with using their own engineering staff
to put together the documentation as best they can
(in so doing,
taking them away from their normal work).
But taking on a consultant technical writer offers a better compromise,
working for just the number of weeks per year that are necessary.
What a Technical Writer Writes
As with all writing (technical and non-technical) the writer first needs to ascertain
what the target audience is, since this determines the style of writing
that is to be adopted.
For instance, the documentation could be for company-internal use,
or for communicating to the external customer.
The documentation could be aimed at a technical, engineering readership,
or it could be an overview for a more managerial level.
Each of the four combinations can be equally exacting,
albeit in different ways.
A technical writer can, of course, be engaged to work on any written material
that is intended to communicate a technical message.
This can include writing emails and letters to external customers.
Normally, though, a technical writer would be engaged on more formal documents,
such as:
- Datasheets
- A formal specification of the main parameters of the product or service
- User guides
- A description of how to use the product or service
- Application notes
- A slightly less formal indication of how the product might be used
to the benefit of the customer in future applications
- Web page content
- A short, punchy description, on the Internet, to attract the potential customer.
(In general, the shorter the description, the greater the importance of having
each word and phrase crafted by a specialist)
- Engineering reports
- A document for internal use,
written on behalf of today's engineering team, for example,
to help a future engineering team
when it comes to later development of the product or service
How a Technical Writer Works
Usually, the process involves two parties:
the person who is engaged to do the work (the technical writer),
and the person who is engaging him (the document owner).
The standard process is then as follows:
- The document owner decides that there is a need
for a new document, or a change to an existing document.
He works, perhaps using hand-written annotations on a photocopy of other
document fragment(s), to make a draft of the desired document.
- The document owner hands his notes to the technical writer.
Of course, the technical writer is presently engaged on other documents, for other owners.
Thus, there is a delay before the start of work,
plus a delay for doing the work itself.
- The technical writer returns the document to the document owner for checking.
Of course, in the same way, the document owner will be presently engaged on
the other parts of his job.
Thus, there is a delay before the start of the document review,
plus a delay for doing the review itself.
- The document owner hands his review notes,
containing corrections and supplementary modifications,
to the technical writer, and the cycle "2+3" is repeated.
After several cycles (hopefully, only two cycles, but ten cycles is not impossible,
and one single cycle is also possible) the document owner has no further
corrections or modifications to be done,
and declares (perhaps via a formal sign-off) that the work on the document is finished.
- The technical writer gives him a version of the document (such as a PDF file)
that is suitable for publication (by email, or on the Internet site, for example).
The technical writer also gives him
all the "source" elements of the document for saving in the archive.
Two questions of resources are inevitably raised at this point:
those of how long the technical writing will take, and what it will cost.
Of course, both of these questions depend very heavily on the size and complexity
of the document(s) concerned.
However, ways exist of estimating answers to both questions
in advance of starting the work.
There is also a question of quality control in the document-writing process.
Although an initial attempt can be made to answer this,
this is a much more ambitious project that still needs further research.
|
