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.
Subject:Re: SERIOUS: Formal vs. informal organizations From:Gwen Thomas <thomasgp -at- CBS -dot- FISERV -dot- COM> Date:Mon, 8 Mar 1999 12:17:20 -0500
Andrew Plato wrote that the concept of formal/informal business practices is "a complex idea that absolutely affects technical communications."
Agreed that this idea bears study. But I would not jump to a "formality is good/bad" decision. This is not really a documentation question, after all. How formal a process to incorporate into the doc department is actually a business decision, and documentation business decisions cannot take place EXCEPT as a subset of Enterprise business decisions.
Deciding HOW TO DECIDE how to do business is one of the most important meta-questions any manager can ask. If you skip this question, you've chosen to be at the mercy of numerous, unacceptable factors.
Have you noticed how the fields of Knowledge Management and "Learning Organizations" are more and more incorporating the Decision Sciences? There has been - for quite some time - very exciting work taking place at MIT, U of Chicago, Berkely, U Texas at Austin, Cornell, and other learning institutions, not to mention within forward-thinking corporations. Some of the models coming out of this work will definitely help shape the future of the technical communication profession.
For an intro to Decision Sciences, I recommend J. Edward Russo and Paul J. H. Shoemaker's book Decision Traps.
However, part of the post in question was extremely disturbing from a management point. AP wrote:
<snip>
Naturally, when I showed up I ignored everything, wrote the entire doc set for the product in two months, and had my contract promptly terminated for failing to follow the established style guide.
<snip>
Wow.
No way would I EVER hire someone who completely disregarded the guidelines I set out for the job. I would absolutely terminate him. And even more, if the attitude was that NATURALLY the writer ignored guidelines, then I would pass that fact along to other managers to assist them in making hiring decisions.
A business decision about end products belongs to management. Period. Doesn't matter if the end result of a cowboy effort was acceptable or even superior. Sure, sometimes processes can be a matter of work style, but only if the person choosing an alternate process can deliver the end product in the expected form in the expected period of time.
Don't like the decision made by the manager? Feel free to attempt to educate the manager and initiate a process change or deliverable change. Think the process/deliverable is unwieldy or wasteful or stupid? Ditto.
But keep in mind that you're probably not being paid to see the big picture. You might not be privy to the collective knowledge Ben Kovitz' post refers to. And even if the manager IS being paid to see the big picture and is failing -- has the manager asked for your input? Have you been asked by the manager or someone higher up to be part of a redesign team? Have you been asked to evaluate the manager or the deliverables or the processes?
OR... have you been hired to deliver some doc? If it's the latter, correcting the problem probably isn't your job.
Me? I always want to hear alternate views. I always want to consider alternate decision frames, and to be made aware of facts that might affect my decisions on processes and deliverables. I (almost always) invite those whose reference points differ from mine to be part of fact-finding missions. I attempt to, as Elna Tymes so eloquently put it, "use planning and guidelines as tools in the process of getting something done right." (See, I'm selfish. I think people with those characteristics tend to get the cutting edge projects and folks who want to work on them.)
But I DEMAND that those working for me stay on my course until I change it. End of discussion. Think I'm too rigid/ too loose/ too decisive/ too indecisive? Don't like the way I've structured the job? Then don't take the job. I can get you work typing in the SME's mark-ups.