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.
--- Shannon Morris <shannon -dot- morris -at- gen21 -dot- com> wrote that there is a debate in
her workplace about what her duties should be. It seems she has been given some
Business Analyst duties, and apparently at least one BA has objected. Now the
managers are arguing about just what she should be doing.
<mytwocents>It sounds like some in your organization want something other than,
or in addition to, a Technical Writer: a Business Writer perhaps or a general
wordsmith, even a Business Analyst with technical skills, in addition. It also
sounds like you are two, or more, managers fighting over control of your time.
Obviously, this situation can be good or bad, depending on how all concerned
For my part, while I don't disagree with the list of responsibilities you
quoted from Bill Swallow, I noticed that they seemed to be software focused.
That isn't surprising given that most of what most TWs do is software-related.
Right now, that's where the money is. I think, though, that you can generalize
from Bill's list to other, non-software writing jobs.
"Evaluate and test software" might be generalized to evaluate and test
(systems, products, business plans, marketing proposals, design documents,
etc.) "Create graphics" is general enough, but publishing to PDF will depend on
your organization's needs as well as the needs of your readers. "Publish to
HTML" again that depends on audience and customer needs; however, writing
without some soft of publishing sort of defeats the purpose, does it not?
"Troubleshooting documentation tools" and "research emerging technologies"
again can be generalized for whatever work environment you find yourself in.
I would suggest trying your hand at writing your own job description if one is
really needed. (I haven't had one in 8 years, yet I feel that I have been
effective in the various jobs I've had in that time.) I operate on the general
idea that a writer can write anything--some things just take longer and are not
as well done as others <g>--with the proper application of the writer's skills.
Talk to the person you report to. Find out what that person wants. Be proactive
and take it upon yourself to write up a proposal of how you might spend your
time. Get your feuding managers to focus on the proposal rather than their turf
war. Show yourself to be a problem solver by helping to make a problem go away.