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.
Don't try to convince your boss that clear, concise, consistent writing
is better; show him. After he's seen what you can do with *new*
material, encourage him to let you "polish" some of the old stuff with
"minor adjustments" (which could of course include a complete rewrite).
My attitude is, my audience is the reader, but my customer is the boss.
First, I have to make that sale: If the boss doesn't like what I've got
to offer, then no matter how good it is,the audience won't benefit from
it.
-----Original Message-----
From: Joan Wamiti
Sent: Friday, April 15, 2011 11:31 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Advice on starting out; dealing with employers
Hey All,
I'm new here, both to the list and to technical writing. I've been
lurking for a few weeks, browsing the archives and reading the daily
digests with interest.
Some background: I've just been hired by a tiny software/consulting
firm as a Business Analyst. However, since I have a little experience
with writing, they'd also like me to be responsible for their
documentation needs - mainly a help guide/wiki for the software that our
clients use. There's also talk of a blog...
My undergrad was a combination of Math and Economics, and my writing
experience comes from writing personal projects and working as a
copy-editor for the on-campus newspaper. Technical/scientific writing
is something that I've been interested in for a long time, and I've done
some investigation into courses/online resources.
Questions:
1. What are some good basic resources for someone just starting out? I
was thinking about a dictionary and a technical style guide (I'm used to
using a journalism one), but I feel like I need more information
specific to writing user guides. I'm ok on the language front, but I'm
at a loss when it comes to file formats, document layout etc. Right now
I'm writing everything up in Word 2010, then emailing it to my boss, who
inserts screenshots and converts it to pdf. In reading some of these
threads, it's pretty clear that I have a lot to learn, but I don't want
to overwhelm myself with unnecessary information.
2. What should I keep in mind when dealing with my employer? My bosses
have technical backgrounds and only have the haziest idea of what their
requirements are - they want a wiki, client-specific help guides, and a
blog. They have no idea of what a style guide is or why anyone would
need one. I feel like I come off sounding fussy and pedantic about
getting documentation right, but I want to do a really good job with it,
even if I'm just a beginner. I've clarified who my primary audience is
(the end-user) and the blog isn't a priority right now.
3. Credit/attribution - how do I address this with my employer? I've
already written up some user documentation for clients. I'd like to be
able to use some of what I've done for a portfolio, but I'm dealing with
a lot of proprietary information, some of which I can't just scrub/block
out (describing processes etc.). I've only started working for this
company and I'm hesitant to bring this up right away, but I don't want
this to become a problem later on. I know I could save all my work for
a portfolio and use it anyway, but I'd rather have permission.
4. How do I deal with previous documentation? There's already some
existing documentation that I'm expected to review (and most probably
revise). Some of it is inconsistent, jargon-filled and unclear, and
there's a lot of Power Point presentation style to it (lots of unneeded
bullet points and sentence fragments). I don't lie when the previous
writer asks me about it - I do my best to be tactful with
questions/comments since the person who wrote it is my boss, but he
doesn't seem to think that the inconsistencies/lack of clarity matter.
What's a good way of showing him the importance of documentation?
These are the main issues I've been thinking about. I'd appreciate it
if you could let me know if I'm on the right track, or if there's
anything else I should think about.
Oh, and this is supposed to comprise a fraction of my normal duties.
This message contains confidential information intended only for the use of the addressee(s). If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing, copying, electronic storing or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this message by mistake, please notify us, by replying to the sender, and delete the original message immediately thereafter. Thank you.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, 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-
