TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Delegating (was: Working later than the boss) From:"James Barrow" <vrfour -at- verizon -dot- net> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sun, 08 Jul 2007 07:39:05 -0700
>Writers Book Mall said:
>>Mary Arrotti wrote:
>>
>>I think probably most of us has at least one bad manager story in us.
Managers >>who dump their work on others, don't stand up for staff, take
credit for the work of >>subordinates [...]
>
>When I was a manager, it gave me special pleasure at the end of a
successful >project to send out a thank-you to the writers involved and the
SMEs they worked >with, with copies to lots of relevant managers, including
mine.
As I'm sitting here reading these outstanding posts, I'm also working
through my To-Do List and Activity Plan for Monday. Specifically, I have to
keep a new hire busy and also coordinate a new-hire package/tour for a tech
writer that starts tomorrow (my kingdom for a "TechWriter TV" cable
channel).
This is hard enough to come up with, but is not the subject of this post.
The real problem for me is taking some of the projects on my plate and
scooping them onto my tech writers' plates - how do I delegate?
The projects that I've been working on fall into four major categories:
requirements, use cases, specifications and 'one-off' projects.
The software requirements are derived from recent meetings with stakeholders
and I either wrote them in shorthand or digitally recorded them. I'm not
sure that a new hire could decipher either.
The use cases are 75-90% complete and I'm thinking that it would take more
time to get the new tech writers up to speed than it would for me to finish
them (FYI, there will be a new set of use cases coming up next week).
The software specifications are derived from the requirements above. This
is the job that I'm most comfortable handing over, but I don't want to split
one job between two tech writers.
The one-off projects come up daily and are only completed because I've
worked with the same team for some time:
"Hey Jim, do you remember that thing we talked about?"
"The analysis thing or the meeting thing?"
"The analysis thing. Can you create that assessment document?"
So how does one go from flying solo to flying in formation? ;^) Should I
take the time to type my meeting notes so that the new resource can convert
these to requirements? Should I just dump all of the information in their
laps and say 'call me if you have any questions'?
Does anyone have any general advice on how to get new hires up-to-speed?
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
