Re: Integrating Tech Pubs more closely with Engineering

["Eric J. Ray" <ejray -at- raycomm -dot- com>]

[Making a concerted effort to actually comment, rather
than posting YAAM (Yet Another Admin Message)]

On
Tue, 5 Mar 2002, Smith, Martin wrote:

 > I've got some issues that I've been wrestling with for some time now as the
 > manager of a small technical writing department. I am interested in how my
 > fellow list members might handle the following situation.
 (snip)
 >
 > Nonetheless I am suffering from what I've dubbed the "you're not one of us"
 > syndrome. The number of C courses that I've taken and the fact that I've
 > actually sold applications that I've written doesn't matter. People come
 > down with "you're not one of us syndrome," it seems, based on their position
 > in the organizational chart.
 >
 > So my question is, what would you do? What makes a real engineer or a real
 > programmer seems as dubious to me as the what makes a real technical writer
 > question that we've debated to death. Does anyone have any suggestions for
 > breaking down departmental barriers that inhibit the level of cooperation
 > essential to produce solid technical documentation.
 >

Absolutely.

In my experience, what you describe _could_ be endemic to
the corporate culture and immutable. That said, it might
well not be. On that assumption, I'll note that the
following techniques have been useful in breaking down
barriers:

Be part of the team. I don't think I've ever talked to
the development teams I work with about my technical
experience or expertise, but I've certainly not
hesitated to talk about everything else. I contribute
to the development team in any way I can, from offering
help with design documents, specs, and the occasional
awkward or uncomfortable email, to trying everything
and filing bugs, to offering my two cents on
everything from test design to software implementation.
Yes, there was an adjustment period, while the
team got used to the fact that I have opinions on
lots of stuff, and I'm willing to back them and argue
them as needed.

Be part of the team (2): Effective teamwork requires
that you deal with people, not "engineers", and that
they deal with you as a person, not a box on an org
chart. To the extent that you know your teammates
as parents, cooks, beer fans, horseshoe players,
or whatever, you'll find that teamwork is easier.
(Note that insincere "interest" will be lethal--
you have to mean it, or you might as well not bother.)


Be part of the team (3): Contribute where you can,
admit ignorance when appropriate, and vanish as
needed. For the last month, I've been all but hiding
from my development team as they've been dealing
with some crises that I can't help with--they're
fixing bugs and I'm staying out of the way.
Now that they're done, I'm volunteering to
handle compiling and cleaning up release notes
and the like (technically not my job) so they
can reintroduce themselves to their families.
I'm perfectly comfortable admitting that I
wouldn't know the difference between the various
data structures in the code if they bit me
on the butt, but am also quite willing to
critique the design of the application from
the perspective of users, writers, trainers,
or anyone who isn't buried in the internals.
I know--and admit--where my limits are, but
try to help in every other way.

Be part of the team (4). It's amazing how
effective the word "we" can be. "How should
_we_ handle this issue" effectively conveys
that you consider yourself part of the
team, and few would step up to say that
they don't consider you part of the team.
With that, you're in.

In this job, my management structure doesn't
connect to the engineering teams until you get _way_
up the org chart, but that's not posed any
kind of obstacle to effective collaboration.

Can you elaborate on what the issues are?

Eric



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
www.ehelp.com/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.