Re: YOU are responsible, even when YOU are not to blame

["Paul Strasser" <paul -dot- strasser -at- windsor-tech -dot- com>]

Looks like there is a bit of life left in this thread...

A few days ago, the following was posted:
>
> > but nobody has really come up with a reasoned, logical
> > argument of how a document error was not the responsibility of the
> > author.

Jan Henning responded:

> Rubbish. It has been repeatedly pointed out that, e.g., if a product
> changes after the documentation has to be finished, the inaccuracy is
> not the responsibility of the writer. (Unless of course he or she was
> also hired as a clairvoyant.)
>

May I take a whack at a counter-argument?  The above scenario, in which
product updates occur after the documentation was completed, has been used
in this thread as an example of errors or omissions that are beyond the
control - and hence, responsibility - of the writer.

I don't agree, and here's why.  If you (that's a basic, general, all-purpose
plural "you" rather than a finger-pointing "you" - I curse the shortcomings
of the mother tongue) are truly responsible for the documentation, then what
for heaven's sake is going on at the project meetings?  The deliverable
schedule is there, and you see Final User Guide Due May 1.  But on the next
line is Update Parameters User Interface Due May 10.  That's a disconnect in
the whole structure.  (And yes, this precise thing happened to me on Tuesday
of this week.  I saw that the User Guide and Final System Documentation for
a large project is due in early May, but the final revisions to some modules
is due later.  That can't work.  I pointed this out.  The project managers
looked at each other, then at me.  "You're right," they said, and the
schedule was revised.)

The reason I'm at these meetings, or any other project meeting that I want
to attend (shades of John Posada) is that I have made the assumption that
I'm responsible for the documentation.  Yes, it helps that the senior dudes
in the company assume that too.  But I'm responsible for content. As an
aside, the one thing I'm not fully responsible for is - fonts! There are
some senior people who are attached to certain fonts, and my response to
their strong suggestion that Garamond be used is usually, "Fine."  It saves
me the bother of worrying about such matters.

Taking responsiblity is, in its own way, liberating.  If the client loves
the online help, I gladly and humbly accept the praise.  If there's
something missing or wrong, I accept responsibility, find out how it
happened, and fix the "process" so it doesn't happen again.  I'm not overly
concerned with blame - maybe that's just the corporate culture here, plus a
bit of confidence in the quality of my output.

But when you accept responsibility you are doing far more than casting blame
upon yourself.  You're marking your territory, taking ownership.  And with
ownership comes the desire to make it better, because those words and images
and diagrams are yours.  With this mindset, the discovery of errors due to
poor project scheduling or lousy communication Ticks You Off.  So you put on
your best corporate face and find out what went wrong with your docs and fix
the process so it won't happen again.

With the opposite mindset ("I'm not responsible") getting your dander up is
more problematic.  There were errors from scheduling or poor communication?
Don't look at me - I'm not responsible.  If it was the schedule, it's the
manager's fault.

I prefer having the former mindset.  I like thinking of the docs I write as
mine, and I can use this mindset (that I hope is not illusory!) to make each
document - and the process that resulted in the document - a little better
than its predecessors.

One caveat to this - As I mentioned above, I work for a small but terrific
company, where communication between the various employees isn't just OK -
it's encouraged.  If you (again, the plural, non-threatening "you") work for
a less open company, where suspicion is rampant and blame-naming is a daily
ritual, the above might not work.  And yes, I know that such companies
exist.  And I know that in some companies the TW is beloved but not exactly
someone important enough to be invited to meetings.  But if your corporate
culture accepts communication and doesn't play the blame game, try accepting
responsibility.  It might work.

Paul Strasser
Windsor Technologies, Inc.
2569 Park Lane, Suite 200
Lafayette, Colorado 80026
Phone:  303-926-1982
FAX:  303-926-1510
E-mail:  paul -dot- strasser -at- windsor-tech -dot- com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in 
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.  
Order here: http://www.ehelp.com/products/robohelp/


   Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.