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.
SB wrote:
> Well, I don't think that he views this as reduced contribution.
> He is focused on doing things right. Of course, there is no end to how right
> you can do things.
Among the differences between tasks that require design skills and those
that don't, is that design tasks are not well or fully specified--they
have a goal (for example, design a document template) but leave it to
the designer to decide how to do it. Non-design tasks have a specified
end point (for example, solving an equation), design tasks don't.
To your point about doing things right ad infinitum, if he wasn't
supposed to be designing anything in the first place, then how did that
design work get his prioritized attention?
Reading between the lines, I gather that you hired a senior-class tech
writer because you didn't want to have to explain things like this more
than once. I think you're within your rights to expect his cooperation.
<snip>
> I don't have the time to proofread what I do,
> partially because most of what he does not do falls back on me.
>
> See, I had a MAJOR update of a 725 page document. I had two months to do it.
> It was inhuman.
Whoever assigns you that kind of workload needs a wakeup call. If you're
not the sort of direct communicator who will stand up to the boss and
declare,
"Poor planning on your part does not constitute an emergency for me",
then you might enjoy posting a photoopy of one of the images from Don
Norman's "The Design of Everyday Things" in your cubie.
I keep several in my office kit: the teapot with spout and handle on
the same side, the bicycle built for two, etc. They express bad design,
making it easier to suggest that idea to the boss who schedules your
work for you, or to your freelancer who works against you, with an
obvious glance, when they stop by to chat.
<snip>
> What I read was inaccurate and incomplete. I had somewhere around 120
> remarks on those 10 pages, some of which were trivial, some of which were
> extremely important. I didn't send them to anyone else to give him a chance
> to take care of it.
You don't have time to read it over, deciding what errors need immediate
attention, before writing remarks? Unfortunately, this echos the design
problem of endlessly doing it right, mentioned earlier. Commenting on
everything will probably create a new cycle of perfectionist fiddling by
your freelancer, no? Don't do that.
Fire the guy, or ask your manager to fire the guy, before you allow this
situation to auger into the ground. And you should strongly consider
getting out your resume and sending it to ten recruiters every day.
Leave that job, it is a fool's errand.
Or, get a new temp with whom you've been very clear that the pay is
good, but you don't have ANY design work, only shovel work.
I was not angry or upset, just could not understand how
> you write a getting started guide without looking at the product. He got
> very offended and told me that he could find plenty of mistakes in my
> documentation too if he wanted, which is true, only unfortunately, I don't
> have the luxury that he does.
There's something disturbing about this. I can't put my finger on it,
but the hairs on my neck are standing.
>
> He went to complain on my remarks and we were both told that there was no
> time to make the changes, some of which were trivial but others were really
> important. So, I accepted that and sent out an email with my comments to
> everybody in charge saying that I thought that the user would not be able to
> install the product with this piece of paper and that I understood that we
> could not make changes but that I recommend that the document be tested
> before the release.
I read somewhere that in a crisis, every problem can wrongly assume the
dimensions of being of the utmost importance. I think it is of the
utmost importance never to appear to be in crisis at work. This is
because managers don't let us declare very many crisises before they
decide that we can't manage the work. So, I would do the review and
markup differently, I guess.
> The Support Manager immediately said that I was right
> and that it could not be released like that and he had it tested.
What kind of product is this? I usually test the instructions I write,
on testbed equipment.
The
> document failed to provide the necessary information. So, it became my
> project to update it, me and my big mouth.
Odds are, your deadlines are artificial. They give them to you but
nothing is riding on them. Test this hypothesis, see what the
consequences are when you bust a deadline. Get the education that within
your reach on this job, it is strewn with important lessons!
<snip>
> We had to outsource the famous User Manual because the document was a
OK, I get it. This is a shaggy dog story. No one could have this many
problems on one project, right? Ha, good one!
Thanks,
Ned Bedinger
doc -at- edwordsmith -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
