TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Job Futures-Who are We? From:Jill Buss <jb -at- US -dot- DYNIX -dot- COM> Date:Thu, 8 Dec 1994 13:30:13 -700
Here at Ameritech Library Services (formerly Dynix) we prefer the term
"technical communicator" because it reflects our role in communicating
information in the best way possible (be it online, in tutorials, manuals,
good user interface and design, etc.). However, most of the company still
calls us "documentors," "writers," or sometimes "instructional designers."
We've developed respect and a good working relationship with Development
over the years by persistence, a good track record, and by management
stressing our role year after year. One of the most helpful things was a
training class our vice-pres. of Development held for all programmers and
writers. This class focused on the development process as a whole (vs.
just software development). It emphasized that a completed product
included more than just the software. It also included the documentation,
training, marketing, delivery mechanism, packaging, etc. It then focused
on the role each of the different departments should contribute to EACH
product. This included all the valuable input technical communicators
could provide at all stages of the development process. The training also
suggested that all of those involved in a product (including
documentation, marketing, International development, etc.) meet briefly
about every 2 weeks during the development cycle to make sure everyone is
on-track, on-schedule, and informed.
Since I am involved with standards documentation and technical training
for our programmers, I then followed up by meeting with each development
team to apply the principles in the training to their existing projects. I
noticed that within days we had more communication and teamwork between
Development and Documentation than ever before. For us, anyway, this seems
to be more of a training issue and less of a titles issue.
Recently we changed our department name from "Documentation and Training"
to "Technical Information Services" to more accurately reflect some of the
non-documentation things we do (online information, videos, etc.). I
personally think it's more confusing because no one knows what "technical
information services" are while they at least have a mental picture of
what documentation and training are. However, we'll see if it makes a
difference in the long run.
Well, there's my two-cents worth. Lisa, feel free to call me if you want
to discuss this further or see any of the materials we used in training. --jb
Jill H. Buss
Ameritech Library Services
(jb -at- us -dot- dynix -dot- com)
On Thu, 8 Dec 1994, Lisa Baker wrote:
> This question has been lurking on the outskirts of many of our
> discussions. Are we as a profession best served by calling ourselves
> technical writers, technical editors, and documentation departments?
> <Note: This message has a software bent because that's where my
> experience is.>
> In the emerging world of enhanced online technologies that create new
> delivery methods for our "documentation" to compliment the existing
> printing technology, and in the world of the information being included
> into the product so the product actually documents itself, it seems clear
> (to me at least) that the terms documentation, writer, and editor do not
> tell the whole story.
> For example, while the term editor may imply to some a "passive"
> activity of suggesting changes to the flow of text, our editors have
> been anything but passive participants and in fact are a driving force
> behind our projects as the project managers.
> Many of our discussions also talk about the difficulties we face getting
> involved up front. I worked at IBM's Santa Teresa Lab a few years ago
> and their "writers" were called Information Developers and "developers"
> were called Program Developers. I liked that because to me the titles
> implied the corporation believed my knowledge and skills could
> contribute to the success of the product just as a developer's could.
> Although one of my developers in particular was an "old-timer" who
> resisted this type of cultural change and continually tried to treat me like
> a secretary, I at least had management backing (mine and his). In many
> ways I found problems with a developer with support by management
> preferable to the historic environment at "vintage WordPerfect." I
> personally have had a lot of success working with my developers, but
> felt resistance from upper management to recognize documentation as
> an important aspect of product success. This is definitely changing
> here, but I have been wondering if a change in titles might facilitate the
> corporate cultural evolution.
> What are you called at their companies? Do you think it matters? My
> understanding is the "information developer" title change was a
> conscious management choice at IBM. Do you long-time IBMers think it
> helped affect any changes in how you work?
> For a while we were Publications, then we were Domestic
> Documentation Services. Lately we've been calling ourselves
> Documentation Development. What should we be calling ourselves?
> Thanks for your opinions
> Lisa Baker lisab -at- wordperfect -dot- com
> Master Technical Writer - WordPerfect, Novell Applications Group
> Just because people say you#re crazy doesn#t mean you#re going to
> win, but sometimes it sure looks like a necessary condition for
> success.# -- Star Warriors, by William Broad