Re: Can someone learn to be detail-oriented? [Long: 1600

[Dan Brinegar <vr2link -at- VR2LINK -dot- COM>]

Thanks, Jill, for the followup... yeah, yer prolly right to be a little
unhappy with the way this thread went-- everyone has their hot-buttons and
pet-peeves...  I, too, hate being micro-managed  but I also know the dread
of going over something with the same people over and over again when they
keep making the same errors.

I'll try to add something pertaining to your questions, without being too
flippant (I should state right out that I do not have a peer-reviewed
textbook on this issue, merely opinions based on anecdotal experience
training, being trained, and working -- my explanations are long, and may
not relate to anyone else's frame of reference 8-)

As with many issues today, this one is not either-or/black&white: Within
one five year period I was told I was both "obsessed with trivia" and/or
suffered from Attention Deficit Disorder...  once all men in my age group
were so-defined, however, we were again able to get on with things (the
trick being to know just *which* sackfull of drugs one needs depending on
the prevailing mood ;-)

"Not Detail Oriented" is a judgment call, and there are no hard-and-fast
rules that let anyone less-powerful than Drill Sergeants estimate the time
it will take to alter a person's behavior or fix a broken process... well,
that is, AFAIK, nobody's tried since the 1920s anyway... in business-- as I
understand it-- the job is to alter the process or environment to achieve
the desired condition (environment+behavior+materials+process -> result).

There are just grillions of folks out there who really *aren't* able to pay
attention to the details of a "new" situation/paradigm, but know the
ins-and-outs of their existing specialty by heart....  they're not
idiots/perverts/ne'erdowells, they're new at it...  and may have learning
styles that differ from our own.

Biggest thing, I think, is focusing on *what* kinds of details are most
important, and *WHY* they're important... I've seen folks completely seize
up when confronted with too many details and not-enough knowledge of
what-counts (and it's at that point when guys like me tend to get
micro-managed, when least able to respond to it ;-)

>It is impossible to write a short query to this list, because one cannot
ever
>make a statement that is taken at face value.

I *think* (based on my own method of reading the list) that many many
people (like me/such as I) read  the list with their "Big Picture" hats
on... and, as good techwriters are wont to do, tend to try to read between
the lines when limited information is available...  we all then tend to
respond with a focus on our own pet-peeves.

Of course, I often find useful information in here when I get to look at an
issue from an angle vastly different from my own... YMMV

>My attitude towards pickiness is irrelevant; the client
>has zero tolerance for errors.

How do the errors occur? Where in the process? Typos? Wrong info?
Formatting errors? Stuff left out? Prevention/elimination of each type of
error must take place at a different stage in the process.

>My take is that our new manager here
>recognizes the past failure to manage as a contributing factor to problems.
>Active management may allow the new person to succeed.

Unless the people involved are irredeemable, I firmly believe it's process
and not people.

>our client has expressed very strong comments on (need for/lack of)
>attention to detail.

What details are they most interested in? (I've heard it called duplicity;
but knowing how to buff the floor so that the colonel sees the kinda swirls
he likes means he's not going to imagine excessive corrosion on doorknobs
-- consultants call it "expectation management" I guess 8-)

>She has said
>herself that assessing, conceptualizing, and synthesizing a manual from
>resource
>materials (big picture stuff) is beyond her current skill level.

AHA!! [I missed this crucial point during my first three attempts to
respond to the thread ]

It's sink-or-swim when the Big Picture is unclear *and* a bunch of
incomprehensible details scream for your immediate attention....

So, if I have this right, it might be a matter of, say, failing to include
pertinent information in a document when "everybody knows" that information
but the writer? Is it an "if yer mother sez she loves you check it out"
error?

>If two people have had problems and I haven't, the conclusion must be that

You can know how those problems happened, how *you* avoided them, and pass
that knowledge on....

>This brings me back to my simple questions.
>
>1. Can someone who hasn't shown the aptitude learn to (take your pick of
>descriptive phrases):
>        be detail-oriented [etc.]

Any _skill_ can be learned assuming they actually *have* the aptitude
lurking untapped in their personality: so, yes, one can learn to pay
attention to the details that are important to the work being done -- like
techwriting.

Will they like it? Maybe not...
How old/experienced is the new TW? ("You can train older recruits to
kill/write/play violin/use windows, but you can't make them think they like
it")

Personality types play a big role here: f'rinstance I tried several times
to learn algebra and trig from mathematicians and only reinforced the idea
that I was a complete idiot... I finally *got it* from a master machinist
who was able to explain the concepts to trainee machinists in terms we
could relate to with the aid of raw metal, tools, and finished parts -- I
didn't actually get *smarter* afterwards, I merely learned to
unlock/redirect existing aptitudes...

>
>2. What methods worked to achieve this?
>

Readily-available institutional memory, Endless repetition, trial and
error, deadlines, obsessive desire to accomplish something,
terror&intimidation, screwing up and figuring out how to fix it, here's
*why* this is important, here's what to look for, "See? You can *do*
this".... knowing a problem's *not* gonna go away unless *I* can solve
it...  BIG Picture: imagining a "perfect" project/outcome; Detail Oriented:
that last index entry in a monster manual and having the satisfaction
knowing it's the best I've ever done or as close to "perfect" as I'll ever
get and they're happy with it.

The method that didn't work all-that-well included compulsive types
stopping me during a Big-Picture-Impulsive whack at a project to focus on
nit-picky details before I have my head totally wrapped around the idea--
I do best on big impulsive whacks, taking a step back, then tackling the
nits with the whole thing in my mind so's I can find the holes in-between
the camel caps, another impulsive whack, a final slog through the small
stuff when I know I won't have anything else to worry about, et voila!

Oh, BTW, it's best if I'm not *too* familiar with the material:  such
things as taking the afternoon to edit the manual I'd finished that morning
-- that page with the same steps for two totally different procedures
still haunts me -- or giving the same instructions out day after day to
customers and getting lost 'cos they have to click two different "settings"
tabs in the same wizard, but they've clicked the same one....

>3. What results?
>
the joy of a properly compiled program/help file...  finding all errors in
formating... knowing that every logical hole we could find has been
addressed and filled... "See? You can *do* this"  has always been my
favorite technique.

Terror and intimidation only served to heighten my awareness of the boss'
perception that I wasn't detail oriented 8-(

>4. How long did it take for the person to work independently?

With "See? You can *do* this" techniques I've had much greater success
getting people to pay attention to new things than I have with the
"By-the-numbers" approach (which is really just rote memorization, the way
most folks are schooled, and the way most folks end up predisposed to
always-press-one and ignore snazzy posters).

Using my "See? You can *do* this" (car magazine) style; I've successfully
gotten folks to learn for themselves to diagnose their computer trubs,
maintain their weapons, rebuild carbs, make Framemaker sing and dance, and
so on in about half the time required by my colleagues who depended on
rote, by-the-numbers, step-by-step-don't-think-just-do techniques... it's
often quicker to run thru a rote set of instructions and get off the phone,
but they'll call back, I guarantee...

>My question wasn't prompted by a desire to change the situation or find a
>different writer. Rather, I have new responsibilities. I'm busy and those
>responsibilities are going to take significant time. I'd really hoped for
>feedback that might help me estimate and budget the time it's going take
>for the
>situation to succeed. I need a realistic picture of the effort and
>potential in
>this situation.
>

I'd write up the kinds of detail that were important, talk that over with
the new writer, make a good effort to understand the newbie's learning and
working style and have the newbie understand the requirements of the work,
go over past good product and bad product and see if y'all can come up with
an undersanding of *why* the bad product is bad and how to avoid it... if
yer spending all day going back and forth on one page of a 300 page manual
you'll need to step back and regroup and not redouble your efforts in a
process that's already not working.

Hope I made some kind of sense... best of luck,
dan'l

-------------------------------------------------------------
Dan Brinegar   Information Developer/Research Droid

"Leveraging Institutional Memory through Contextual
Digital Asymptotic Approximations of Application Processes
suited to utilization by Information-Constrained,
Self-Actualizing Non-Technologists."

vr2link "at" vr2link.com   CCDB Vr2Link
http://www.vr2link.com     Performance S u p p o r t Svcs.

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=