Return to Publications

The Art and Profession of Technical Communication

by Brian J. Dooley


(reprinted from People and Performance Magazine, March, 1996)

As New Zealand moves firmly into the information age, competition with leading edge technology firms is growing fiercer and our products must grow in sophistication. Markets are opening, shipping costs are going down, and tariffs and trade restrictions are falling by the wayside. New Zealand is blessed with the engineering talent to face this enormous challenge. But this talent needs a supporting infrastructure. Technology must be packaged so that it is competitive with world market expectations and supported by professional quality manuals, brochures, and reference materials. These materials are the province of technical communications.

Technical writing has undergone a revolution in recent years, and it is important to bring the benefits of that revolution to New Zealand. World-class skills do exist here. But this is only a start. Unfortunately, technical writing is not widely recognised here as an independent profession. To complicate matters, some New Zealand organisations bill themselves erroneously as "technical writers" without having appropriate skills or experience. This has led to some confusion in the marketplace, both among organisations that need these skills and individuals wishing to acquire them. A growing demand in the workplace should change all of this, however. Companies are beginning to realise that they need to create good manuals and technical marketing materials in order to compete internationally. Since this is the real base of technical writing or technical communications, the profession stands ready to emerge as it has in other countries.

Development of Technical Communications

The need for good technical documents has often been ignored. This is because technical communications is typically the last area to develop—historically, nationally, and often within individual companies. Technology tends to be tested first by engineers and technicians in small numbers. At this point, information is easily shared, and a manual might be created by a junior level engineer as an afterthought. The manual is not really used; it is often in the shape of project notes or specifications.

This works for a time, mainly because everyone is basically familiar with the product and the technology upon which it is based. But the product must at last reach the "real" market. In the real market, users are not a part of the development group, do not have constant access to developers, and may not be technicians. The manual offers no help, because they don't understand it and essential information is missing. Support costs go way up. Additionally, potential buyers who must evaluate the product take one look at the amateur documentation effort and opt for the competition. Users--particularly in business--want to be certain that the product can be mastered without an enormous training burden, and will fit requirements.

Meanwhile, the product gets reviewed. A sample goes to the trade press, with a manual. The reviewer doesn't have a whole lot of time, so does an initial evaluation relying heavily on the manual. The product gets a negative score. The product manager cant understand why the product is having problems. It seems to work adequately. And there is documentation. But he is a technician, too, and has no way of judging the quality of the manual. He isn't in the business of creating manuals; he's in the business of developing product!

Variants of this scenario are played out time and again, with similar results. The advent of the IBM PC hastened the process in many countries. Here was a technology that was quite complex and had to be explained to users at a very basic level. Manuals started to compete with mass market books—such as my own "Learn Windows in a Day". Then product information started to get noticed, and the result is history. The role of the professional technical communicator was validated, and the profession began to develop rapidly. Today, the Society for Technical Communication (STC), a worldwide association of technical writers, artists and information workers boasts a membership of some 18,000. And, with New Zealand's push into world technology markets, the profession is rapidly developing here.

Who are the Technical Communicators?

The Society for Technical Communication (STC) membership roster provides a good idea of the variety to be found in this field. Among members, you will find all of the following:

Writers and editors

Graphic artists and technical illustrators


Managers and supervisors

Educators and students

Independent consultants and contractors

Photographers and audiovisual specialists

In addition to these traditional areas, the field has grown to include the whole new range of multimedia and world wide web (WWW) information development—as they are used to disseminate technical information. It is communication about technology using technology. You will find technical communicators in scientific publications, engineering publications, writing manuals for computers, software, radio systems, VCRs, whiteware, business quality systems, and power plants. You will find them writing, editing, formatting—and creating whole new concepts in communication that meet the needs of emerging technologies and developing markets.

STC is the largest professional association serving the technical communication profession. The New Zealand chapter was formed in 1994, and is headquartered in Christchurch. For technical communicators, STC provides the following:

Support from more than 18,000 members and 140 chapters worldwide

High caliber programs that keep both entry-level and veteran communicators aware of the latest trends and technology in technical communication

Innovative services for the educational and professional development of its members

Access to international developments and international competitions in technical communication.

STC provides current information about technical communication and offers opportunities to network. At regular monthly meetings members can exchange ideas with peers and participate in practical, job-related programs. Technical Communication, STC's highly acclaimed quarterly journal, publishes thought-provoking articles on subjects of interest to all technical communicators. Intercom, the Society newsletter, is published ten times a year and keeps members up-to-date on the latest professional news and Society activities. The New Zealand chapter also publishes the newsletter Right Ragged, and sponsors local competitions

This past year has seen a lot of progress in establishing technical communications standards. The New Zealand STC chapter has obtained press coverage from magazines such as Computerworld, expanded its membership base, and laid the groundwork for future expansion by establishing credibility. Educational activities have been developed to further professional development, and a solid program of presentations has brought local technical communicators together.

What Skills are Required?

With the broad range of disciplines and subject matters that fall within the realm of technical communication, it may seem difficult to define a characteristic skill set. This is not necessarily the case, however. Technical communication is, above all, functional. Unlike many other kinds of information, it performs a specific purpose, is targeted to a specific audience, and uses a range of known and tested conventions. Among the specific characteristics of a good technical document—in any medium—are the following:

The skills necessary to work within these constraints require special training, practice, and constant monitoring and evaluation. Technical communicators must also acquire training in the technology used to create information—word processors, page layout software, hypertext systems, multimedia systems, and a growing range of delivery platforms.

There is currently some debate in the profession over the amount of technology-specific training a documentor might require. In other words, if you write about radio systems, do you need to be a radio expert? Currently, employers tend to require too much specific knowledge rather than too little. Technical communicators should have advanced skills in focusing upon what a user needs to know. If the user is likely to be a technician himself, then some specific training may be required, but you should bear in mind that a good technical communicator is an expert in assimilating and developing technical information. The documentor also has to look at the product from the users' point of view—a perspective that a developer or someone intimately connected with the product will find impossible to maintain.

If possible, you should find someone who has some demonstrated familiarity with your product area, but, if none are available, the amount of specific training required may be relatively small. The necessary information is generally available in the form of product specifications, other manuals, and general research materials used by your engineers.

Seeking Special Training

Time and again, organisations, consultants, and engineers have attempted to develop technical communications systems by mechanical means. This has involved everything from creation of schemes to rearrange product specifications, to grandiose schemes involving a "Chinese menu" approach ("one from column A and one from column B"). The problem is that there is no single solution. Each document is unique because it addresses a unique situation. Products differ. Audiences differ. Media differ. Technical communicators must be trained to understand and apply concepts creatively. For this reason, a simple course or seminar in "Technical Writing" is only appropriate at the most basic level. A good technical communicator needs to know a great deal more, and develop appropriate experience.

Among the elements that need to be contained in a technical communication curriculum are:

Of course, the list goes on. There is plenty of material for a complete course of study, or for a reasonable period of apprenticeship under experienced supervision. On-the-job experience can be problematic, of course, since qualified managers of technical documentation are still difficult to find. Without a good manager, the end result can be development of a lot of very bad habits and questionable practices.

Luckily, Christchurch Polytechnic has just taken the lead in developing a certificate course in technical writing. This course will be offered in 1996, and it covers the areas detailed above. The course was developed by a committee that includes representatives of some of the major technical organisations in Christchurch, plus input from American experts and from a similar effort in Australia. The course is also endorsed by the New Zealand chapter of the Society for Technical Communication (STC). It should provide a basic platform upon which to build world-class documentation for New Zealand's developing technical industries.

What Do Employers Need To Know?

The first thing that employers need to know about technical communications is that it exists as a profession, backed by several professional organisations, and having well understood standards of performance. If you are hiring technical writers, you need to look for past experience in technical writing and/or an appropriate scholastic background. Do not presume that any individual familiar with your technology will be capable of creating a user manual. Also, do not presume that anyone billing themselves as a "technical writer" or "technical communicator" will be appropriate for your job. You need to find appropriate experience and professional involvement.

If you intend to train technical writers, you first need to first find the right people. They should have at least some experience in technical documentation, and have a demonstrated interest both in the technology and in communications. Note that there are a lot more technologists and a lot more writers than writer/technologists. But they can be found. They may not be the best at technology development, and they need not be the worst. But they do need to be able to communicate technology to ordinary people. If you cannot find anyone with previous documentation experience, you should look for someone with demonstrated interest in both technology and communication; a science student on the school newspaper, for example.

Once you have found the right people, you can provide training. Avoid the brief overviews and "all-in-one" courses; they're okay as a refresher, but it isn't real training. You will need to cover basic technical writing, word processing and desktop publishing, graphics, and other areas appropriate to your documentation requirements. Wherever possible, mentoring, internships, and other forms of on-the-job training should be provided. You cannot create an instant technical communicator; but you can point people in the right direction. The local polytechnic is a good source for many of your training needs. Additionally, there are seminars being offered by various training organisations, and the Society for Technical Communication (STC) has assembled seminar offerings in the past.

Other Employment Options

Like an increasing number of technology professionals, technical communicators can generally be hired on a freelance or contract basis. This gives you top notch writing talent without a yearly wage, and ensures that your staffing levels meet project needs. For example, a small software company may develop a product over the course of a year, but only need a technical communicator during the final four months. In this case, management may elect to go with a freelance or contract employee.

Freelance arrangements are fairly fluid, and generally involve a contract for specific documentation items. Work may be completed offsite at the freelancer's office, with materials and access to engineers provided by you. Freelance operations may provide additional services, such as editing, graphics, and other specialisations. Your contract is with the freelancer or freelance agency, and it is based on completion of the whole documentation project.

In the contract situation, the writer often works at your facility, using your equipment. He or she works like any other employee during the term of the contract. Contact employees can be hired through a technical or technical communications contracting agency, and your contract is with the agency.

If you need to use a freelance or contract employee, it is important to plan the documentation project carefully, and allow plenty of time for initial design. The freelance or contract worker will need time to "come up to speed" on your technology and systems. You will also need to introduce the technical communicator to your project development team. Before work begins, you also need a documentation plan.

A well developed documentation plan should be a part of your contract. The documentation plan sets out the technical communicator's assumptions, and details your expectations. As such, it keeps the project from getting off the rails. The documentation plan should give you a good idea of what to expect, and reviewing it with the technical communicator will give you an idea as to how the project will proceed.

In a documentation plan, you should look for the following basic components:

Since the documentation plan can involve considerable effort, you should be prepared to pay for its development time. A thorough job at this stage can save a great deal in the long run and avoid costly misunderstandings.

Where is Technical Communication Headed?

The technical communication field is in the process of rapid expansion, both globally, and in New Zealand. As more and more technology is unleashed upon the public, the need to explain it grows proportionally. At the same time, whole new realms of communication are being explored. This makes the future pretty rosy for the technical communicator, but it also provides some significant problems. The field is growing in diversity as it expands, and the skills required are always changing. Like software engineers, technical writers need to constantly keep up with a growing range of tools and media possibilities. Training must be constant. In addition, provision needs to be made for experimentation with new systems. Without careful planning, conversion between different word processing systems and delivery mechanisms becomes frighteningly expensive.

As the need for professional technical communications grows, you can expect to see more programs like the one created by Christchurch Polytechnic. There is a growing awareness that documentation must be improved, and measures are being taken to improve it. Two years ago, the New Zealand chapter of the Society for Technical Communication (STC) was formed, and the Society has recently held the first all-New Zealand technical documentation competition. This competition will be held every year, and the best entries will compete with entries from other STC chapters for international prizes.

Copyright 1996, Brian J. Dooley

Return to Publications