Re: Should the Doc Manager be equal to the Dev Manager? (LONG)

[Andrew Plato <intrepid_es -at- yahoo -dot- com>]

"Teemu S."  wrote

> Do you think the Documentation Manager should be equal to -- or report
to --
> the Development Manager?

Report to a development manager with strong ties to marketing, sales, and
support. 

> I know several posters have said that it doesn't matter where tech
writers
> sit in the org chart because results speak for themselves. While I
agree, I
> also think that that acting as a user advocate requires some authority.

Authority flows from capability and respect. Capability to do one's job
and respect for the existing arrangements and organization. Just because
you have great ideas on usability does not mean they will or should be
implemented. There are often many other considerations that make it
impossible to respond to all usability ideas. 

> I currently work for a small software company (30 people) as a lone
senior
> writer, but have the responsibility of a Doc Manager. I currently report
to
> the Development Manager, who in turn reports to the VP of Operations. I
have
> asked to report directly to the VP of Operations so that I can have
equal
> authority to the Development Manager.

Your company is way, way, way too small to be so bureaucratic. When you
get to 250 people, post this question again. You're jumping the gun. No
company this size should have so many chiefs. 


> General Reasons for NOT Reporting to the Dev. Mgr
> 
> 1. A Documentation Manager has similar responsibility to the Development
> Manager.
> I have to gather deadlines and requirements from our Marketing and
Support
> staff, determine the best user assistance (help, better UI, print),
select
> the tools, prepare the deliverables, ensure their accuracy and
completeness,
> and deliver them. Given an impossible staffing situation (me and a
summer
> intern), I have to make very difficult tradeoffs almost minute by minute
> when selecting which deliverables get first priority.

Welcome to the party. I'd challenge you to find a single organization in
the universe that doesn't have these problems. 


> 2. Tech writers need authority to negotiate with Development.
> I would prefer to have some authority to make demands of Development
when it
> makes demands of me. 

Doesn't work that way. Your company MUST have a development team.
Documentation (while important) is not mandatory.  

If you build a good working relationship with your development manager,
he/she will come to respect your input on usability. If you just outright
demand the authority, you won't get it. You have to prove that you can
make a significant contribution to the team without being a twit who
expects everything they say to accepted. 


> 3. Tech writers are the resident authority on user assistance and may be
> more customer-focused than development staff.
> This argument is value-laden and open to debate. I'll leave it as an
open
> claim.

Yeah, its rarely true.  The people who have the most exposure to what
customers/users want is almost always people in support, sales, or field
engineers. Tech writers RARELY work directly with customers, and thus
their ideas of usability are based on ethereal ideas of usefulness and not
how people are REALLY using the products. 

This is why I laugh when I hear about tech writers wanting to be usability
experts...I always think to myself: "have you ever really MET a customer?"


> Company-Specific Reasons for NOT reporting to the Dev. Mgr
> 1. One of the primary documentation audiences is Support staff.

This in an of itself is why you should report directly to a development
manager. They make the products and therefore need to communicate those
designs to support.

> 3. The Dev. Mgr is a "driver" personality.
> Our Development Manager is a charming bully. He's very intelligent, and
he
> gets things done. When he wants to be he can be very charming. But it's
hard
> to make him listen; you have to have to be willing to battle (or nag)
for
> your ideas, or he will ride roughshod over you. He's a great debater and
> controls every meeting, even with senior management present.

Most development managers are this way.  They don't want people with flaky
good ideas. They want PROOF. That means you have to be willing to defend
themselves. Apparently, you want to mandate changes without defending them
- that is a really bad way to run a complex development environment. 

> Reasons for Reporting to the Dev. Mgr
> 
> 1. Documentation is part of the development deliverable.
> Since tech writers produce deliverables that are part of the CD (help
and
> PDFs), we need to be integrated as part of Development.
> 
> 2. The Dev. Mgr. doesn't need to be an authority on documentation to
control
> documentation.
> The Dev Mgr said can't be expected to be able to perform the jobs of
most
> his staff. Each staffer is an expert in his or her area. That doesn't
mean
> they all don't need direction from a central manager.
> 
> 3. One person -- the Dev. Mgr -- has to have to clear vision of the
entire
> product.
> 
> 4. The Dev. Mgr. may be better able to acquire more tech writing
resources
> than a Doc Mgr.

I think you pretty much answered your own question here: you should report
to the development manager. Honestly, most places that have free-floating
doc managers are really not equal with development managers.  The fact is
people just do not value documentation the same as they value development.
Development is mission critical, docs are merely critical. Thus doc
managers rarely get the same access to management that a development
manager does. 

Andrew Plato 



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** 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.