Reorganization Questions (fwd)

[Betsy Perry <betsyp -at- VNET -dot- NET>]

Rick Lippincott said,
------- start of forwarded message -------

Up until Friday, my entire tech writing career has been with
companies where all of the tech writers were in one department
answering to one manager. On Friday, that changed when my present
employer announced a major reorganization of the R&D department.
There are now five software development teams, each team has a number
of tech writers. Although each group of tech writers will answer to a
group manager, there is apparently no plan to have one overall
manager in  charge of tech pubs. There's been talk of a "steering
committee" composed of reps from each team so that we can maintain
some consistancy across the teams...but I'm getting ahead of myself.

What are the pitfalls that I should whatch out for? What are the
lessons learned that you can send to me? Any suggestions on how to
make this work with a minimum of trouble?

------- end of forwarded message -------

I've worked under this organization before, at Hewlett-Packard.  In my
experience, reporting to a writing manager who reports to engineering
is almost identical to reporting directly to an engineering manager;
the same strategies are necessary for success.

The benefit of this organization is that the writers can become
tightly integrated into the software-development team.  When you sit
with the engineers you're supporting and report to their management,
you can become *their* writer: instead of being another anonymous
interruption, you're a teammate, working toward the same cause.  (Yes,
a good writer can achieve this result no matter who s/he reports to.
It is easier to be part of the team if you're genuinely *part* of the
team, orgchart and all.)  Over the years, you can develop a deep
understanding of your team's projects and processes and become a more
efficient contributor.  Instead of having to sell yourself afresh at
the beginning of each project, you can depend on the respect you've earned
in your previous projects.

The disadvantage of this organization is that your professional life
winds up being controlled by people who may not understand (or value)
your profession.  A good engineering manager may be a very bad writing
manager, either because s/he thinks writing is easy  ("Just add some
commas to the specs and you're done") or because s/he doesn't want to spend
valuable engineering dollars supporting a staff member who isn't
cranking out code.   When you report to engineering, it can be very
difficult to get money for hardware, software, and professional
education.  In the worst case, you may find that it's impossible to
pry raises for writers out of engineering management, or that writers are
last-hired first-fired.  If this last happens to you, your only recourse is
to find a new job.

The winning strategy is to do a sales job on your new team -- not just
the management, but the individual software developers.

o Show them how much value you add to the product, and to their
process.

o Show them that your interruptions, far from slowing them down, can
actually save developer time by pointing out inconsistencies in the
design before they become bugs in the code.

o If you have the time, offer to edit some of the developers' writing:
design specifications, professional papers, and so on.  *Edit for
content!!!* When the developers begin to understand the difference you
can make to their writing, they're well on the way to valuing the
excellence of yours.

o When you're first added to the team, give them a brief explanation
of the writing process and its parallels to the software-development
process.  This will help the developers understand why there are
periods during which you aren't apparently producing anything at all,
and why it takes time to produce quality documentation.

o Keep lines of communication open to your fellow writers; you should
share survival tips on your new development-driven environment.

I sympathize completely with your situation.  One of the most
frustrating features of our profession is the continual need to
explain and justify our value added.  On the other hand, it's very
satisfying when you succeed, and when you have turned a software
developer into an advocate of good documentation.  A software team who
understand and value your work can make you smarter, happier, and more
productive.

Betsy Perry
ParcPlace-Digitalk
--
Elizabeth Hanes Perry                    betsyp -at- vnet -dot- net

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-