Re: How to fend off a tech writer (long)

[Kevin McLauchlan <kmclauchlan -at- chrysalis-its -dot- com>]

This has been a varied, and occasionally interesting thread 
(ok, so I've read every word...).

My Personal Observations

Flow is Good

1) Flow IS more productive. I get more done when I am not 
    constantly trying to recover all the things that I'd 
    been holding in my head. Also, I can HOLD more things in
    my head when the whole thing... flows.

2) Flow is part of my compensation. It's a pleasure, in and
    of itself, and is therefore a trigger for much 
    resentment when it is needlessly broken.

3) Flow does take about 15-to-20 minutes to re-achieve, 
   when it's been running for a while and gets
   interrupted... but it takes (me at least) much longer to
   invoke (in fact it usually needs to arrive
   "accidentally") when I'm first attacking a project or a
   phase of a project that
  a) I've been avoiding, or
  b) I haven't brought into sufficient focus in my own head
      to feel that I've "really begun, at last".

4) When my work is being edited, the pattern of discovered
    blunders (discovered by me if I've had a sufficient
    cooling-off period.... rare... or discovered by a
    reviewer), often matches with the places in the work
    where I was interrupted.

5) With all that in mind, I try to avoid spoiling it for
   other folks, 'cuz I know what it's worth to me to get a
   good groove going... and keep it going.  Reciprocity.
   is a good thing.

Developers and Respect

1) Sometimes there are actual Product Spec, and even Design
    Spec documents -- preliminary though they may be, so I 
    latch onto them. Those, and the project group meetings
    and the engineering group meetings are good to keep me 
    informed and to let me ask relatively sensible questions 
    in a group setting. That gives me the air of an actual 
    project participant.
    When the spec docs are circulated by the authors, I make 
    it a point to review and comment in a timely manner, and 
    to phrase objections as questions.

2) Meeting etiquette -- I try always to show up on time, and 
    prepared.
    Many of our meetings have notes/minutes taken by the
    instigator, so everybody else is off the hook. 
    However, many other meetings have minutes taken by
    participants on a round-robin 'you haven't done it in a
    while' basis. It is important that:
    a) I don't get stuck with that chore, noticeably more 
        often than other people, but 
    b) when it's my turn, I provide exemplary minutes 
        with a lot of well-organized detail and leaving no
        doubt about what was involved in each issue and 
        who is assigned responsiblity, and what they are
        expected to produce, and when it is due, and what
        progress and obstacles have been seen so far. 
        I take particular care to put people's names beside
        accomplishments and beside particularly relevant and
        thought-provoking questions that they raised.

    Quite often, the chore of figuring out what to say in
    the minutes has a salutary effect on my understanding 
    of the project and the issues (technical, fiscal,
    political...). Either that, or I go check with the
    appropriate party to clarify my understanding before
    publishing... ("Chris, I want to be sure I've got this
    right...Is the problem this, or is the problem that? OK,
    that makes sense. I'll have the minutes in your mailbox
    in twenty minutes. Thanks.")

3) Inject a little humor, but with a twist that shows I'm at
    least in the ballpark. For example, within the past 
    year, two developers have left us -- we'll call them
    Samir and Pat. Sammy went on to better things, having
    made himself almost beloved. He was a genius and a
    perfectionist, but had such a nice way about him that
    people somehow didn't mind when he horned in on a task,
    then made it take almost twice as long ("Hmm. This is
    good; this is good... but maybe we go back here and
    change all this -- you see? -- and it be better...") but
    the result was ten times better.  If Samir wrote it, it 
    didn't break.
    Pat, on the other hand, was let go "for cause", and
    people are still repairing things that Pat worked on. 

    So, when puzzled heads are bent over reluctant problems,
    or there's disagreement about direction -- even if I
    don't really grasp the details -- I whip out my cap. 
    I don't wear a cap, I just keep one handy so I can hold
    it over my heart while I raise my eyes heavenward and
    intone: 
    "In times like this, we must ask ourselves, 'What would
     Sammy / Pat do?'"  
     The trick is in knowing when to invoke Sammy and when
     to invoke Pat.

4) Around my desk, I keep:
    a) a goody bowl (contents change, but it's usually got 
        something interesting in it -- unless I'm on a diet,
        and then everybody is...  :-)

    b) several packs of chewing gum, in multiple flavors
        (all the smokers seem to come by, just before
        meetings...  :-)

    c) a container of nuts, usually pistachios, which cause 
        people to hang about, chatting, while they 
        split shells and make a mess all around my
        waste-basket.

    d) extra pens and pencils, especially some spare
        Sharpies for marking CD-Rs (those are always 
        in demand)

    e) a "spare" PC, dual-boot Windows/Linux, with a CD 
        burner and the appropriate software iconized on the 
        desktop in both operating systems, and a spindle of 
        blank CD-Rs

     f) several sets of juggling balls

     g) several steel tavern puzzles

     h) my red editing pen (for everybody's "would you just
         take a quick look at this?" reports and memos and
         white papers), along with a reputation for helping
         them sound good on paper while telling them that
        "Aw shucks! It was mostly just style or personal
         preference stuff. There was really nothing wrong...
         are you after my job?  <insert mock-predatory 
         grin>"

It is always a good idea to go to the relevant manager, 
group leader, or engineering project manager with new 
questions, or to touch base before landing on the underling 
developers. The leader gets to see that you ask sensible 
questions, the leader is kept in the loop on issues that 
are coming up, and the leader will often accompany you 
to the underling's cube, where everyone has a nice chat 
and sometimes issues get resolved or directions get 
changed, and most certainly everybody acquires a better 
grasp of the whole picture.

So, all of that to say, I don't have problems getting 
developers to talk to me. Getting them to shut up, 
though...

Ok, I'm kidding.

Resume coffee break.

/kevin
    




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l

Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

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