New Hire Orientation

[Jim Barrow]

Gene Kim-Eng [mailto:techwr at genek.com] wrote: 
>Jim Barrow [mailto:vrfour at verizon.net] said: 
>>
>>Our Tech Pubs department hired a new tech writer last Friday and I'm
trying to >>assemble an orientation that will do more than just keep that
person occupied until >>we can obtain a computer, network ID, password, etc.
For that matter, I also need >>to develop departmental policies and
procedures, but that may need a separate >>thread.
>
>How soon is this person starting?

That would be Tuesday.

>Given that you don't have your department's policies and procedures
documented >(and you're the documentation group, shame on you)

In the dictionary, under the word 'slacker,' there's a picture of me.

>unless the new hire already has hands-on experience working with all your
standard >tools and documenting products in your company's technical field,
anything less >than assigning someone to be a hand-holding "buddy" for the
first week or two on >the job is essentially the warm body equivalent of
your 10 days of document reading.

She does indeed have experience with all of the tools that we currently use.
Over the weekend I created an orientation plan that I tried to gear towards
tech writers.  In doing this I realized that I need to talk with HR to
create a formal process for all new hires.

>The subject matter may not be obsolete, but without the handholding it
won't be any >more useful.

I agree.  That's why I decided to assign a mentor to all of the assignments
in the orientation plan.

>Face time for orienting the new hire needs to be considered a part of your
workload >for a time, the same as any other bit of extra work your
management might dump >onto your current projects.  At least this one will
provide you with a direct return on >your effort invested.

Currently, our orientation plan consists of my first in command covering
ever topic and detail.  I'm sure that this leads to burnout (on both the
parts).  This is why I'm scheduling brief meetings with everyone in the
department so that person can explain his or her part of the project(s).

We've had problems in the past whereby new tech writers look at our agile
methodology as a bit fast and loose and subsequently decide to reinvent our
policies and procedures, rather than focus on the writing at hand.  

- Jim