Introducing "best practices" to non-experts?

Subject: Introducing "best practices" to non-experts?
From: "Geoff Hart" <geoff-h -at- mtl -dot- feric -dot- ca>
To: TECHWR-L -at- lists -dot- raycomm -dot- com
Date: Mon, 25 Oct 1999 09:06:15 -0400

The problem is that you can lead a techwhirler to best practices,
but you can't make them think. <g> That is, the problem you're
facing is the same one any teacher faces, namely that of
motivating someone to become interested in learning. If you can't
raise that motivation, you're not going to succeed. Although the
precise tack you have to take will differ for each person, there are
various "univeral" tools that work for most students.

One thing that works particularly well is to figure out what
"professional" tricks are going to help your colleagues do their jobs
better or more easily. (Relevance and elegance are powerful tools
for getting someone interested in a new way of looking at things.) If
you can find "neat" or "peculiar" stuff that relates to what you're
doing, that tends to stick in the mind too. And for each trick or tool
or "tease" you introduce, you can casually mention the learning
resources available to the person (e.g., steer them here, show
them William Horton's icon book, etc.). The ones who really want
to learn and expand their professional skills will gleefully seize
upon what you provide and start learning on your own. The others
will take a bit more work to get going, but at least you've given
them tools that move them in the right direction, and you can
continue doing so by adding the less interesting things to the
repertoire... such as standards.

Speaking of standards, the most important way to begin a dialogue
is--surprise!--to begin a dialog. Start with something like "I'd like us
to begin doing things the same way, because apart from the
benefits of consistency, it's a kindness to our editor". From that
point, you can begin discussing the specific consistency or style
issues you need to address, and hopefully reach a consensus.
One useful tool might be to use techwr-l as your source of
authority: "This is my opinion, and here's why. This is your opinion,
and here's why. Let's put the question to techwr-l and see what
other professionals think, and why. Then we can try again to reach
consensus." Better still, this sounds like a marvelous opportunity
to do some audience analysis and usability testing: "We've been
doing it this way since the dawn of time because it's what our
users wanted. But maybe their needs have changed. Let's ask
them, and we'll use their responses as the basis for our new

And although you may be well versed in the theory of the field, and
familiar with what works and what doesn't, never let that blind you
to your own blindness: sometimes a newcomer from outside the
field can shed significant new light on old issues, provide significant
insights you've forgotten about or never pondered, and overturn old
dogmas that deserve to be overturned.

--Geoff Hart @8^{)} geoff-h -at- mtl -dot- feric -dot- ca (Pointe-Claire, Quebec)
"If you can't explain it to an 8-year-old, you don't understand it"--Albert Einstein

Previous by Author: Presentation to engineers, take II
Next by Author: Icon for a documentation department?
Previous by Thread: RE: John Galt: Lover of Standards
Next by Thread: Icon for documentation department

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads