Where does the docs department fit? (Long)

[SteveFJong -at- aol -dot- com]

Geoff Hart <Geoff-H -at- MTL -dot- FERIC -dot- CA> wrote, "Count me in among the heathen, but 
I don't think it really matters where on the org chart you put the 
documentation group." He then went on the make some fine points (with which I 
agree) about what a doc group needs to succeed. But I think I will take the 
opposite side of the issue. In 25 years I've worked in different spots on 
different org charts, and I think it does matter where the organization sits.

Where a group goes "on the org chart" really means who the boss is. Different 
bosses are different people, with different levels of understanding and 
interest in the work of their people. As Geoff said, if your boss understands 
and values your work, that's great, wherever you're situated; but if not, 
you're in trouble. 

I once worked in a doc group doing networking docs for the networking 
division. The corporate group was forever launching hostile takeover efforts, 
but we reported to a divisional VP who thought we did good work, relied on us 
to respond to his products' needs, and kept us independent. All was well. 
Then we were reorganized under a VP of Shared Services (QA, Performance, Ops, 
and Doc), who had no clue or interest in what we did. All he saw was his 
largest and most expensive budget item. When business went bad, he asked each 
group to save $250,000. We cut training (I think); the Ops manager raised his 
chargeback rate to us, which effectively threw us back out of whack and 
directly triggered the layoff of one of our administrative assistants. 
(Apparently you can be a technical manager and not understand arithmetic.) 
The next time the corporate group came knocking, the VP was only too happy to 
unload us, whereupon our manager was immediately laid off and things went to 
hell.

Whoever you work for will regard you as a resource to be used to further his 
or her own goals. I worked at a startup for a doc group that reported to QA. 
(Why? Because the first QA hire thought she could write, and when she became 
the QA manager she kept her hand in.) Working for QA is OK--we both take an 
"outsider's" view of products. But when the QA workload got heavy, she 
naturally turned to the writers, part of her resource set, to pitch in. 
Suddenly we were dropping everything to test software, not our forte and not 
on our schedule. Mysteriously, the writing suffered.

Your value to the organization mirrors your boss's perceived value; when the 
boss succeeds, you succeed; and when the boss fails, rightly or wrongly, you 
fail, too. We went through several incompetent QA managers, and that stigma 
attached to everyone in the group, including us.

It's great to work for engineering, because we share values and because we 
want documentation considered part of the product. But when you report to one 
of several peer managers, conflicts can arise. I worked for an Engineering 
director in a structure of several directors. When a resource conflict 
cropped up, my boss instinctively decided the writer should work on her 
product rather than the one I'd assigned the writer to cover. (This conflict 
got settled, not by me, but between my boss and her peer.)

Even when your reporting structure is right, there can be troubles if the 
boss is bad. I worked in a doc group reporting to the VP of Engineering, 
which is about perfect. But business went bad, and the doc director, to save 
the jobs of himself and his managers, voluntarily laid off the entire writing 
staff, retaining his managers to manage contractors that took over the work. 
It didn't help that we ourselves were the contractors; it still sucked, and I 
quit as soon as I found another job.

So yes, it matters where you sit!

          -- Steve

Steven Jong, Documentation Team Manager (Typo? What tpyo?)
Lightbridge, Inc., 67 South Bedford St., Burlington, MA 01803 USA
mailto:jong -at- lightbridge -dot- com -dot- nospam          781.359.4902 [voice]
Home Sweet Homepage: http://members.aol.com/SteveFJong