What do you write?

[Ned Bedinger]

I've read the other comments in reply to yours in this thread and you're 
getting the view of tech writing through the Kaleidescope, and that's a 
pretty good place to start.  I have a few (unsolicited, confused) 
patterns to add to what's been said to your windup to the main 
question.  See comments embedded below.

Tech Writer wrote:
> I have been a tech writer for almost a year, having previously worked 
> as a
> software engineer in the same company.  I love the change, but there 
> is one
> thing that bothers me about it.  I expected to spend most of my time 
> writing
> user manuals and help files, as our software is sorely lacking in user
> documentation.  I firmly believe that documentation would improve the
> quality of our product.
If you can find some of the scholarly studies/articles by Ramey and 
Reddish  from the University of Washington, I think you'll enjoy them.  
They work with the proposition that technical writing does add value to 
a product.

> Unfortunately, I am more often assigned to write internal systems
> documentation that is either ignored or simply filed away somewhere, 
> mainly
> because this is a small enough company where everyone already knows 
> how to
> perform their job from pre-existing documentation and notes.  (The "head
> cheese" who assigns these projects to me apparently doesn't see it that
> way.)  I'm afraid that my developer past is keeping me tied to those 
> types
> of projects.
Stop me if I am going wrong here, OK?  I'll go out on a limb with 
intuition and past experience to speculate that the headcheese wants 
some sort of baseline documentation.  Without some sort of documentation 
of a frozen state for a product, there can't be much hope of ever 
keeping track of the changes as they release the ongoing minor revs and 
major version updates. 

An added bonus, for a writer with your background, is that SMEs, who 
hold the information you need, will be much more likely to discuss 
things with you than they would be with a tech writer who doesn't have a 
background in the technology.  Your background can make you worth more, 
in terms of your compensation per hour, when you work on deep documentation.

> I really want to build writing experience and to
> gain knowledge of many types of documents.
Well, you've mentioned end-user documentation, and I want to mention 
that End-user documentation is its own thing and not nearly as 
interesting (IMHO) as internal project documentation, system 
documentation, etc.  The formalities (of doc design and writing for 
end-user docs) appeal to lots of tech writers, who probably won't admit 
it but they get their validation from seeing a manual they wrote on 
someone's bookshelf, or from a list of titles they have written that 
might get read by end-users.  When you're writing internal 
documentation, you don't get that same thrill of believing that 
thousands of people read you effortlessly, but I think that internal doc 
projects are just as valid and validating for the writer, if only in 
other ways.

End-user documentation skills can seem to be the core of some tech 
writing job descriptions, but many of those tasks are closer to desktop 
publishing than to plain old tech writing.  If that appeals to you, 
you're probably free to hunt such opportunities, aren't you?  But my 
advice would be to develop and build on your skills in the deeper 
technical arena, and keep working in internal documentation.  That's 
where the real game is, if you ask me.

> My question to you is this:  On average, what percentage of your time 
> to you
> spend on user documentation versus internal system documentation?  

Maybe I'm missing something, but what exactly is the dichotomy again?  
Is 'systems' limited to as built diagrams and component documentation, 
something like that? Is 'end-user' sort of a context-free description of 
how to use a particular package?  I ask because I see that line as 
blurred--I have end-users for system documentation.

Anyway, I contract anymore, so my work tends to be focused on IT, one 
proj at a time, usually either system 
installation/administration/operation, or training material to train 
those same roles. Doggone me if I can break it up into percentages!
> Also, how
> much control do you have on the projects you get to work on?
As a senior tech writer, I am generally left to my own devices to get 
and keep my SMEs focused on working with me.  But if I want their (SMEs) 
manager involved, I go through my manager to contact their manager.  In 
short, I am in control where I have to draw on my personal resources to 
be effective, but I'm never in a position to exert much preference, 
leverage, or force.  I can't impose 'the right way' of doing anything 
but my specialized little task as master of the word processor.

Issues of control, such as deadlines, document designs, influence over 
project stakeholders or team members, are not usually left to me as a 
contractor, although I sometimes find myself working with the client's 
bunnies, who look to me as a consultant and authority on all things tech 
writing, and what I say goes.  Even in those cases, the client is 
reporting to someone higher up--I might control the horizontal, but they 
control the vertical.
> Thanks for your input!
>
Yore welcome.
> Sarah
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ned Bedinger
doc at edwordsmith.com