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.
Somebody mentioned the "barrier" between engineering and tech writing.
So I'm in an engineering meeting just now, talking about use cases for a
software tool we're developing. At the end, we start talking about next
steps, which leads to a discussion of design reviews. At that point, I
say "OK, now we should start talking about the documentation for this."
The VP of Engineering replies "In fact, documentation is critical here
and not only for online help. We need to add electronic versions of
procedures, checklists, and so forth. We need to have content management
as part of this." I said "Right. Now who is going to take leadership for
that part?" Everyone (and I mean literally) looks at me and breaks into
a smile!
I laughed and said "Hey, not a problem! Usually it's the *opposite*
problem; nobody wants tech writing to get their hands on it!" So we
discussed the things I could do for them, not just *writing*
documentation but helping them organize and develop their *own* material
and then edit it, and consulting for the content management aspects. One
of the operations/QA engineers asked me for help in compiling and
organizing their new binder of procedures.
So at least in this company, I'm not seeing a barrier put up by the
engineers.
I attribute this to several things:
* I push to be in meetings. Face time is useful.
* I learn the technology, and listen to what others say about technical
problems.
* From my learning, I learn to ask questions. I figure that if I give
answers, I could be wrong on the facts. If I ask I smart question, I
demonstrate that I'm
following what's going on.
* I identify myself with the engineers and other technical
professionals. My role is to produce something, not necessarily to
manage/market it or sell it.
I think I've said before that I have a software engineering background.
That helps.
I'm not ruling out doing work for marketing and sales, but they do have
their own needs. The writing style and focus is much different than for
documentation. Marketing and sales people are expected to do their own
writing, and they're more resistant to editing. But mostly, I find it
difficult to switch between technical and marketing style.
New from Quadralay Corporation: WebWorks ePublisher Pro!
Completely XML-based online publishing. Easily create 14 online formats, including 6 Help systems, in a streamlined project-based workflow. Word version ships in June, FrameMaker version ships in July. Sign up for a live, online demo! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
