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.
Re: Should the Doc Manager be equal to the Dev Manager? Response
Subject:Re: Should the Doc Manager be equal to the Dev Manager? Response From:"Tom Sullivan" <tsullivan -at- netexpress -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 14 Aug 2001 21:23:46 -0700
Hey Teemu,
Topic for Future Discussion: There are unique challenges facing lone tech
writers in companies with very immature processes. How and when do we
express needs from development?
IMHO you express needs when they come up, as directly as possible. I
understand the reticence in challenging a "charming bully," especially one
with physical command, and (apparently) the ear of upper management.
If regularly scheduled staff meetings are not part of the landscape, then I
wholeheartedly suggest instituting them ASAP. If regular staff metings are
not an acceptable option, then written directives are imperative. Being the
lone tech writer dictates that you act as your own advocate.
I know how things are supposed to work in
the ideal world or in large companies. But in a small, immature company, I
just "make it happen," working around all the barriers without identifying
them as barriers.
It really matters not if the company has 5 employees or 5000. But since
your company is so small, it is incumbent upon you to formulate and
institute practices that are going to expand as your company expands.
First and foremost, I suggest that you take time to identify and rate the
barriers. I have used a rating system that puts the problem(s) within a
scale from 1 to 5. 1 is "no big deal" and 5 is "OH MY GOD!" Everything
falls somewhere in that range. Urge company-wide use of the scale, in
whatever form it may eventually adopt. If you can't get company-wide
acceptance, then at least make department-wide usage mandatory.
Your practice of working around barriers and "making things happen" may
expedite matters in the short term. It may also reduce the number and
severity of confrontations between docs and dev. But in my experience this
behavior sets up unreasonable expectations of you that could come back to
"bite" you.
It serves the organization more efficiently to have a team approach to
knocking down the barriers, regardless of how small the company. As the
company grows, hopefully more writers will be brought on-board. That
eventuality will require adoption of problem-solving skills that such
growing pains necessitate.
As the demands increase and increase, I continue to "make
it happen" rather than explaining that development will have to change its
ways if I am to achieve the new goals. (Of course, it would help to have
more tech writers, but that's not possible. We don't even have a trained
tester.)
Even more reason to facilitate changes now. Obviously the development
manager banks on his ability to intimidate and bully others. If development
continues its expectation that you will continue to "make it happen," they
have no reason to change. And the longer you continue to "make it happen"
the more they will resist the need to change. They will also have no reason
to believe that you won't continue to do what you have been doing.
I suggest introducing the changes incrementally. If you introduce drastic
changes quickly and immediately, you will get staunch resistance. I suggest
an agenda with a spirit of cooperation, as well as with a firm understanding
that your needs matter. As much as possible, don't allow the development
manager to bully and/or intimidate you. Attempt to have (friendly)
representation from upper management in any meeting(s) that broach the
incremental changes.
Even incrementalism will no doubt cause serious reactions from development
(tantamount to civil war), but that is to be expected. Most people don't
like (unscheduled) change. It sounds like the development manager will
fight the type of changes that need to be made and attempt to use his
(seeming) substantial influence with the powers that be, to resist.
Stand your ground and defend your territory. The patterns you establish
today will determine success or failure tomorrow.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
---
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.