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: Domain knowledge? From:"Engstrom, Douglas D." <EngstromDD -at- PHIBRED -dot- COM> Date:Wed, 14 Oct 1998 16:32:19 -0500
Katherin:
This is written in reply to:
########################
I have heard the term "domain knowledge" and understand it to mean "the
knowledge that we as technical communicators have of the product/industry we
are writing about." I have three questions:
1. Is this the correct definition?
########################
I haven't heard it used that way, but it sounds plausible.
########################
2. How do we acquire such knowledge?
########################
A chance to use my favorite Tech Writer reply: "It depends."
What it depends on is you, the nature of the subject, and the amount and
type of knowledge required. If you're just expanding an existing base of
knowledge, some well-spent time of with the project team may do the trick.
If you're stretching a bit further afield, a basic text or some sort of
company-furnished basic training may be necessary before you hit the project
team. This assumes, of course, that the knowledge base is reasonably
well-documented. If a great deal of what you need to know falls into the
category of "plant folklore" or "stuff people who have been working here are
all supposed to know" be prepared to spend some time as a data-entry person,
or a third assistant junior apprentice gofer for anyone willing to put up
with you for a few days. Actually, this is good experience even if it isn't
absolutely the only way to get the information; you always find out lots of
things you didn't know that you needed to know.
########################
3. Can a technical writer always acquire such knowledge (through asking
a million questions) or does a writer have to have an aptitude for and
interest in the domain?
########################
Well, if you're really willing to do what it takes and apply main force
until you've got it, sure. All things yield to will. Though I can say (from
having done it) that spending a minimum of 40 hours a week with your face in
a subject that you don't like and aren't good at is not a particularly happy
work situation.
########################
I'm asking because I'm in a situation in which the "domain knowledge"
required of me when I was hired was, I felt, much less than that which is
required of me now, and VERY much less than what will be required of me in
the near future. I'm concerned that I may be in over my head, and seek
advice on how to deal with the situation.
########################
Well, the first thing you need to do is figure out just how big the wall
you've got to climb is, and what resources you have available to help you
climb it. At a minimum, you're going to be investing some time in learning.
The company may give you anywhere from none of the necessary time to all of
the necessary time as regular, paid work hours. Assuming you've got to
invest some off hours, get a handle on how many and what that's going to
mean in terms of family life and other activities.
Find out what sorts of training is available--on-site, off-site,
company-led, contractor-led, etc. and what, if any you'll have access to,
and under what conditions. Also check into other resources such as
self-paced guides, tutorials, reference books, etc. The company may fund
all of this or none of this.
At some point, sit down and discuss the whole situation with your manager.
Explain what you think the expectations are, what you think it will take to
get there, and what help you want or expect from the company. Listen
carefully to the answers or lack of answers, and revise your plans in light
of them.
Then, you're faced with a more-intense version of the question you should
always be asking yourself anyway: "Is this worth it?" If the job has lots
of positives, you find the subject interesting, and the division of labor is
at least equitable, it's probably time to suck it in and get down to work.
If you dislike the subject, the job has other problems, and the company
regards this (rightly or wrongly) as something you should be working out
entirely on your own, it's probably time to invest some effort in a job
hunt.
Skoal,
Doug Engstrom
engstromdd -at- phibred -dot- com
"What we see depends on mainly what we
look for."
-John Lubbock
#########################################
My opinions only, not those of
Pioneer Hi-Bred International, Inc.
#########################################