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.
> Even at the initial stages, it pays to be aware and give
> some consideration to stuff you won't be able to address
> for a while, to:
>
> a) let people know that 'it's on the list' we haven't forgotten
>
> b) ensure that you don't paint yourself into a corner
> by early choices that could have gone another way if
> you'd anticipated the effect on things you'd eventually
> need/want to address.
Yes, but there's a big difference between raising awareness and saying
that something either won't work or is otherwise wrong, which is what
we're largely seeing here. Uninformed opposition, given the thing
being opposed isn't even formulated yet.
> Indeed.
> Those three people do a lot of chatting and browsing
> and drinking coffee in the early days, between sporadic
> bouts of evals. But if the enterprise takes off, they
> start getting busy. Then fully employed. Then overworked.
> Then burnt out.
>
> "We decided early that we were against a testing paradigm,
> so we're obliged to stick with portfolio evals. Youse-guys
> will just hafta keep working double shifts until we can
> find some more qualified bodies to handle the load. Ain't
> success grand? By the way, we've been getting complaints -
> lack of sleep is not an excuse for sloppy work. And your
> pee-breaks will need to be shorter."
LOL! But are we talking dedicated staff for this? Or are we talking a
Council of Elders approach? We don't know.
> It's not that people can't be evaluated - though now we're
> talking job performance being evaluated by your boss, and
> not performance/attainment against some trade standard.
>
> It's that the job IS all over the place, and varies with
> the situation - even within one person's employment at
> one company. That's probably _less_ true for members of
> a documentation team, and more true for lone writers.
>
> I suspect that most contract writers have more focused
> responsibilities. They are hired to document something,
> and they are seen as being there, short-term, for that
> purpose. It's either unlikely or less likely that other
> managers will see them as a general resource, or that
> they'll be offered tasks responsibilities for which
> they were not specifically hired.
>
> Captive employees of lengthy tenure become part
> of the corporate memory, and can often find themselves
> doing stuff that's unrelated to the nominal task of
> writing manuals/help. But their title doesn't necessarily
> change - nor should it - if technical writing continues
> to be a major part of their reason-for-being... there.
Yes, but that unrelated stuff they end up doing isn't technical
writing/technical communication. Sure, they're still labeled
TW_3_HRBABBLE in the salary database and still have "Technical
Communicator" (or whatever) on their business cards, but the tasks
don't need to necessarily be lumped into technical communication.
Hell, I've worn so many additional hats that I have no clue which
one's the official one anymore. With my official title falling in the
"Technical Documentation" bin in some manner, I've worked in sales,
QA, development, marketing, tech support, HR, the C-level floor,
production, legal... That doesn't mean it's now part of the officially
certified role of "technical communicator".
Maybe that's the hangup here... The goal isn't to certify every little
thing you do. It's to certify your technical communication adeptness.
>> I disagree. Free certification is about as valuable as a ring out of a
>> gumball machine.
>
> We'll agree to disagree partially.
> I'm thinking in terms of a baseline, entry-level cert.
> If not free, then inexpensive, not onerous.
> I'm also thinking of multiple levels vertically, and
> multiple compartments/silos horizontally, so those
> advanced certs would be sought by people who have been
> employed for a while and looking to move up or at least
> be recognized for what they've learned and done. Those
> could have a non-trivial price-tag attached.
>
> True, even the entry-level should have a nominal fee,
> to give the applicants a feeling that they are pursuing
> a thing of value... never mind the outsiders who might
> use the cert as a screening tool.
I'm just trying to see the value in a base-level certification in
technical communication, never mind what it might look like. Do other
certifications have base level honors? Does PMI offer something that
certifies that someone knows just enough to be dangerous? ;)
> Again, if you can get the same necessary assortment of
> portfolio and work artifacts (??) from any-and-every
> applicant, and treat them all equally, it's not a big
> deal. But if there are legitimate reasons why a number
> of people might legitimately be unable to produce
> enough material on which to be fairly evaluated (fair to
> the other people who go through the process, as well as
> fair to themselves), then you need a model that can be
> applied to anybody who fits the [lumpy] mold of 'techwriter'.
>
> If that doesn't eventually devolve to a testing paradigm,
> then I'll be interested to see what does bubble to the
> surface. But if it does come down to testing of knowledge,
> skills, ability, then you need to let people know what
> they are in for, in detail.
>
> You also need to let them know - by keeping as much
> info public as possible - that everybody is tested to
> the same degree against the same standard. Which means
> publishing the standard, which pretty much comes down
> to a very detailed set of skills, tasks, samples (with
> equivalents that apply across dissimilar industries).
>
> One approach would be to have a set of exams on your
> website. People could prep themselves for any/all,
> but would never know which ones they would sit for,
> until the day. That would be a good way to let people
> see where their deficiencies might lie before they
> tendered their credit cards. "Wow! That cost me
> a thousand bucks to learn that my idea of 'doc plan'
> didn't agree with theirs."
I'll buy that, and I believe that's in part what the BOK is for.
> Not 'of course'. Some people legitimately argue that
> wide and varied experience should be an important
> factor in master-level certification. You can go up
> to senior journeyman level in a single industry, but
> to go any further, you need some breadth to go with
> your depth. I can see both sides of that argument,
> and I don't know where I'd come down if pressed.
Industry certification and technical communication certification
should be kept apart. You need to draw a line. Now, if it's something
that is very specificly related to techcomm (info architecture, RFP,
Help authoring, spec writing, etc.) that can be looked at. But at some
point you need to acknowledge a breakpoint where another entity is
better suited to certify on things.
> None of the above is "stop the presses" stuff. It's
> just things to be mindful of, when deciding what to
> do next and where to aim. Swamp avoidance.
Understood.
Man, this'd be easier if it was in some kind of a formal STC wiki or
something. Wish we had one of those, still. ;)
Gain access to everything you need to create and publish information
through multiple channels. Your choice of authoring (and import)
formats with virtually any output. Try Doc-To-Help free for 30-days. http://www.doctohelp.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
