Writers job description/definition

[Ned Bedinger]

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.com