About responsibility and fault

["Eric J. Ray" <ejray -at- raycomm -dot- com>]

You know, I think much of the current contention
stems from several nuanced distinctions in terminology.

In my opinion, a core tenet of professional behavior
is taking responsibility for one's own actions and
products. The engineers I work with are quite accustomed
to hearing me say "my docs; my responsibility"--meaning
that if there are problems with the documentation, I
take full responsibility for allowing them to occur and
go out the door.

The question of "fault" or "blame" doesn't arise in a
professional environment. If I wanted to evade
responsibility for the errors in my documentation, I
certainly could find places to point fingers. I could
point at schedules and deadlines, point at information
sources, point at test equipment, point at code comments,
or anything else.  As a matter of fact, my engineers often
give me a lot of latitude to do so, by volunteering "we
should have told you that", or "we should have given you
more information", or by making similar comments.  I'm
sure that, for any given mistake in my documentation,
I could find an excuse for why it happened.

I don't do that, and would never do that. According to
the standards of professional behavior I expect from
myself, that's not acceptable. If I need to analyze
the root cause of errors in my documentation, the buck
stops with the test I didn't run, the question I
didn't ask, the code I didn't understand, or the
priorities and deadlines I didn't manage correctly.
It's my project, so I take responsibility for it.

In an environment where fingers are pointed, blame
is assigned, and fault is found, the meanings of
responsibility (meaning taking responsibility) and
responsible (meaning who is at fault) are often
conflated, and this situation gets worse where there's
an expectation that a scapegoat must be found for
mistakes.

I'm fortunate to work in an environment where taking
responsibility (as I use the term above) is rewarded,
and assigning blame isn't acceptable. I've been in
other environments, and have found that, for my personal
sanity and mental health, the only thing to do is to
leave. I've done it before, and I'll do it again.
(And no, the quality of the economy doesn't affect the
decision--I leave unprofessional environments as soon
as I recognize them.)

Yes, there are environments with unrealistic deadlines,
political problems, and "challenges" in other respects.
Managing those issues are part and parcel of what a
professional technical writer does. If you're in such
an environment, you actively manage expectations, reassess
deadlines and deliverables, schmooze and make friends,
do first and ask permission later, and do the best you
can. And take responsibility for your products. And it
is possible to effect changes to the environment and make
things better for you and your readers, but those changes
only happen through unrelentingly professional behavior
on the part of the writer.

Ok, that's it for the rant. Thanks for listening.
Eric
ejray -at- raycomm -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.