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.
We had this tech, no tech argument at work. The guy from the client
organization got stuck with a no tech. By the end of the project, he totally
lost his cool, because all the interviewing wasted his time. And, the no
tech wouldn't share with the help writer. It's not the job to learn. Learn
on your own time. It's the job to write. If you don't know the subject area,
don't apply for the job. It's no wonder that TW is perceived as a cost, a
hidden cost. Development should charge back the SME salary costs to the
Documentation department every time we ask a question.
Yes, we must learn, but that learning has a cost attached to it. A real cost
that the accounting system doesn't see. But, still, a real cost the CFO
feels intuitively. Just like the cost of reading that the customer pays for
when they read a manual or a help system. That is an invisible cost as well.
Rare will a company know how much salary is contributed to a vendor's
product. Writing a manual may meet the customer's expectations, but reading
them is bad for their company cost wise as are buggy code, printing out
pdfs, and the salary contribution for the time spent on technical support
calls and self support.
On job titles, recruiters will not present you to a client unless you
already had the job title for which their client is looking. Some larger
companies like TI only hires people for jobs that they have done before.
Both of these hint at the need to manage your job title.
The statistics on TWs in Maine could have come from the Portland STC
chapter's Salary Survey. We've had some equally gruesome survey results here
in Austin: 2001-2002 minus 100 TWs. The real trouble with the numbers is
that they doesn't show all the inexperienced people having replaced
experienced people. Look at the job ads today. Tons of companies are hiring
TWs with no experience, no college, and no demonstrated ability to write.
The job loss has been at the high end and the hiring at the low end. We laid
off middle management, so we could still make the new grad, college hires.
In the middle, the recruiters will not present you, because they think you
won't be happy at $50K. Well, that's a hell of a lot better than the $6K per
annual that is running out soon. The good news is that hiring has picked up
over the past three weeks. And, once everyone is back at work, the people
who managed to hang on to their jobs will be looking to switch. The wage
suppression will probably keep them in place unless they really hate their
boss. Wages will have to go back up before some people will be able to
change jobs. And, for some, wages will never be that high again. Let go of
the cookie jar and begin again.
The software industry is on the downhill slide, so even if you get a job,
don't get used to it.
We can define ourselves all we want, but it's the market that defines the
jobs, job content, job titles, and salaries. I think that letting the
English departments define the TW curriculum was the beginning of the end.
STC should have done it. SIGDOC should have done it. I believe IEEE did do
it for professional engineers. So from here on out we will get the no tech
TW, who drives up client costs, if you are in a service oriented functional
unit, by wasting the SMEs time. They could have written it themselves in the
time that it takes to explain it to the no tech TWs. Been there. We can't
know it all, but we should be somewhere above 80%. More than ten content
redlines in 900 pages from a technical review is unacceptable. Read, test
and validate before you ask the SMEs and you won't have to bring them
cookies.
If you really, really want to write, instead of publish, if you want to be
a novelist, then don't work in words during the day. Dig ditches and go home
and write your heart out. Being a TW and a novelist doesn't seem to mix well
among the people I know that are doing that.
In my last company, we hired lots of TWs to clean up the work of others.
None of them actually wrote on the job. They edited. They had written
before. They all were tech TWs. The writers sorely missed writing. The
sought satisfaction in a rewritten paragraph or so. Yes, they should have
hired editors and word processing people instead. They were managing the
hardware documentation process--a technology unto itself--and the CYA
blame-assignment, procedures game. The engineers didn't want to turn loose
of the content responsibilities. They didn't want to write either. Luckily,
I was writing software documentation, working for the developers rather than
engineers, and not cleaning up other people's writing. I did that long ago
though. Lucky are the immune.
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
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.
