Path: utzoo!attcan!uunet!wuarchive!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!mountn.dec.com!minow
From: minow@mountn.dec.com (Martin Minow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 and MacDTS policies
Summary: Send thanks when folk help you
Message-ID: <1718@mountn.dec.com>
Date: 27 Jun 90 20:52:20 GMT
References: <1990Jun21.215639.16938@efi.com> <8842@goofy.Apple.COM> <1990Jun25.223451.2864@efi.com> <42340@apple.Apple.COM> <1990Jun26.192623.7121@efi.com> <26883CF9.2BCB@intercon.com>
Reply-To: minow@bolt.enet.dec.com (Martin Minow)
Organization: Digital Equipment Corporation
Lines: 40

Having worked as a support person for six years (with corporate responsiblity
for support of a major product for two), I can well sympathize with the
problems MACDTS folk are going through.  I would add a few comments, however:

For "us":

-- When someone in MACDTS (or Apple Engineering) goes out of their way
   to help you, send their boss a thank-you note.  If you don't know
   their boss' name, send it to John Scully, with a request to pass
   it to the right person.  This doesn't get you invited to Scully's
   barbeque parties, but it does end up in the person's personnel file,
   where it can give their boss an incentive to reward (salary) the
   helpful person.  Send a thank-you note by real mail, not Email.

-- Don't waste MACDTS time.  If you're reporting an errror in their system
   "for the record," let them know.  If you have a deadline "I need this
   answer by July 30," let them know that, too.  When you report a problem,
   give them all the info: reproducible, which system/hardware, strange inits,
   etc.

For "them":

-- My experience is that triage really has to be done by an experienced
   person, mind-numbing and painful though it may be.  If you rotate the
   task among all the MACDTS engineers, it becomes less of a chore (a
   half-day per month, perhaps).  This keeps all the engineers aware of
   the kinds of problems folk are having.  Give your triage person the
   job of writing/solving the easy problems.

-- If the same problems crop up again and again, don't blame the dumb
   customers (RTFM), but blame the folk who didn't explain the system
   adequatly in the documentation.  The recent set of sample programs
   is useful.  You might also look at the Mark Williams C documentation
   for the Atari-ST: each "toolbox" function is illustrated by a short
   explanatory program.

-- Don't forget, the customers are paying your salary.

Martin Minow
minow@bolt.enet.dec.com