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.
The post is prompted by Chuck Martin's wondering whether he can credibly
assert to a hiring manager, "That a certain unfamiliarity of a product
will actually elicit areas in which the resulting documentation needs to
focus (and also provide information for future improvements in product
design)?." This is a statement that I've heard since early in my career,
perhaps even as early as college. While I've come to believe it less and
less, and to consider it a simplistic statement on what we bring to the
table, I've only recently challenged it and, more importantly,
considered what it says about us as professionals.
I propose that our skill is actually in knowing how to keep a critical
mindset that allows us to see and question assumptions that others have
made. Just as editors can see things about writing that the author
cannot, we writers can see gaps in information that others cannot. We
can explore those gaps and tease out the threads that matter. We gather
information and then lay it out logically and that whole process is what
gives us our insight into what people need to know about the
product/process we document. We shape it into meaningful content. I have
never run into a situation where I did that better when I knew less
about the subject. I ask better questions, I fill in the gaps, I
organize and write better when I know *more*. It is the fact that I have
a critical approach to information; it is that which allows me to
continue to write usefully for a variety of audiences. It is our
objective relationship with information, not unfamiliarity.
Do we honestly believe that we can sell employers on ignorance as an
asset and expect them to take us seriously? Do we really think that this
adds to our credibility? Do we think it helps us to build relationships
with and extract information from developers, project and product
managers, analysts, etc?
I am trying to pitch myself right now to a company that has a ton of
good written content in a technical area that I don't know much about. I
can tell you right now that I'm not pitching my ignorance, nor am I
saying that I can produce better content than the engineer who knows
everything. What I am pitching is my ability as an editor/repackager to
make the information more accessible, comprehensible, which is a problem
for them right now. I'm saying, "I can make all this incredible content
better for your audience because I know how to mold and shape
information." I am telling them flat-out that I can't produce new
content to begin with. Only when I learn the subject could I confidently
say, "I can write about this for your audience."
The other skill that I'm going to pitch is my ability to work with a
technical team. Tech writers frequently say, "I'm an advocate for the
user," etc. But if we are really going to sell ourselves as being
translators from the technical side to the end users, we have to be able
to communicate with BOTH sides of the equation. One of the programmers I
asked about this told me that one of the big problems he sees with tech
writers is that "the writers do not have the ability to talk to the
technical team." He recognizes that this is a two-way communication
problem. But I think that's almost beside the point. If we don't know
what they're talking about, how do we expect to have useful
communication? Even though I don't know about the technical area, I do
know how to talk to technicians, and I have some layman's knowledge of
the area. That will be enough to *start* to communicate sensibly with
the engineers and to prove to them that I'm not going to waste their
time. I'll spend most of my time at the beginning with the content,
learning how to speak their language better.
I'm not saying that writers have to know everything about a subject
before being able to make a meaningful contribution (obviously, or I
wouldn't be trying to break into a different subject area). But I am
saying that I *never* tell anyone that I'm a good writer because I don't
know something. And I never conduct myself that way on the job either.
If there's something to know, I learn about it. I know more the next
time I talk to someone than I did at our last conversation.
I think that if we really want to advance technical writing as a
respected skill, we have got to stop maintaining and promoting
deliberate ignorance.
Lisa
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here: http://www.ehelp.com/techwr-l/
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.