Changing departments?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

The travails of Anonymous continue:

<<I was recently told the 'powers that be' decided that the R&D Division is
passing the Doc. Dept. to another division of the company.  I was privately
offered by the VP (R&D) the choice of whether to move with the Dept. or to
stay within the R&D Division in some other capacity.>>

My first reaction is that given all the problems you've reported with this
company, moving to another company might be wiser than moving to another
division. But then it occurred to me that if the VP actually knows who you
are and cares enough to give you a choice, there may yet be hope. In
particular, just how much leeway does the VP intend to offer you? (Ask some
pointed questions and find out!) The related and more important question is
whether the VP recognizes the problems that exist and is willing to work
with you to solve them. In your situation, I'd sit down with the VP and get
a really good feel for whether there's actually hope of getting something
accomplished.

Here's one possible scenario: Explain the problems with producing
documentation and how you'd like to try to solve them (e.g., by making the
techwhirler part of the development team, and making documentation a
deliverable just like each module--such as a dialog box--of the software).
That'll work well if (and it's a biggggg if) the developers can be made to
work according to some consistent methodology, such as (i) design the
interface, (ii) get you (or someone equally qualified) to review the
interface for conformity with some overall standard (which must, of course,
be developed), (iii) agree to freeze the interface (at least temporarily),
(iv) begin documenting the interface while the developer worries about the
underlying code; (v) determine any changes needed and communicate them to
you only as part of the final signoff.

Do you have faith that the VP can understand why this is necessary, and lay
down the law so that the procedure gets followed? If so, you've got a golden
opportunity to impose order on chaos and start producing good documentation
in a timely manner. If not, you're spitting into the wind. But since you
have the VP's ear, at least briefly, and you have the opportunity to define
a role for yourself in R&D, I'd suggest giving it a try and seeing if you
can make a go of it.

<<what is more important, the act of tech writing or the person you report
to?>>

The two are inseparable. If you don't enjoy the work, then why are you still
working there? If the manager doesn't create a situation that lets you do
good work that you enjoy, then why are you still working there? There's no
shortage of disfunctional companies, but there are also a goodly number of
intelligently, compassionately managed ones.

<<a barely functioning Doc. Dept of two people, which is widely considered
to produce useless documentation that is chronically out-of-date in relation
to the software by a year or more.>>

This suggests that in addition to needing to freeze interfaces, you may need
more writers. If they're not willing to hire additional help, the
unsatisfactory but workable solution might be for the developers to document
their own stuff, then turn it over to you for editing and final production.
That lets you stay within R&D, with the good manager, and still do a lot of
the work you enjoy.

<<still they are moving the Doc. Dept. to another division of the company.>>

In many ways, where a department fits in the company is irrelevant, because
how you relate to the developers as a writer is far more important than
where you appear on the organisation chart. However, such moves can be very
important because org charts sometimes represent real and intractable
political barriers within corporations. They can also be significant because
they sometimes represent a management approach to problem-solving that I
despise: shifting a problem elsewhere in the hope that it'll go away rather
than taking the time to figure out what the problem is and how to solve it.
You'll have to be the judge as to what is going on here. In the latter case,
it's a strong sign that you should consider taking your talents elsewhere.

<<And to move with the Doc. Dept. under the new division means once again
working with the liar manager.>>

Another excellent reason to stay within R&D. You noted that you don't want
to do QA work for that group, but would being their editor (an important QA
role) let you stay in that group and still do mostly technical
communication? Don't forget, what they call you on paper and what you
actually do in that position needn't bear any strong resemblance*; my
current title is "publications coordinator", and though I do indeed perform
some coordination, the vast majority of my job involves writing and editing.
Moreover, the "editor" job is only as "limited" as you want it to be, and
speaking as an editor born and bred, I don't consider the profession
limiting at all; more to the point, my job title has always been "technical
editor" (with various flourishes attached, depending on where I worked), but
I've never let that define the limits of the work I do. For example, I
currently do writing, translation, Web development, online help, interface
design, and all kinds of other fun stuff. You can too!

* I look on this the same way that Harry Harrison's Slippery Jim DiGriz, the
"Stainless Steel Rat", might: as an employee, you're the aforementioned
chromed rodent sneaking your way through the bowels of a technological
corporation that has little understanding of reality as you see it. Conform
where you must and (more importantly) where you should, but never forget
that you have the right to shape your own path through life, including your
life at that corporation.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

Hofstadter's Law: The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law.