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: Working for a liar From:Scottie Lover <iluvscotties -at- mindspring -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 24 Feb 2000 09:30:41 -0500
At 05:07 AM 02/24/2000 -0800, Chris Hamilton wrote:
> Could it be that they don't see your ideas as being
>good or relevant? It could be that your defense of
>them is seen as being overly and uselessly argumen-
>And maybe you've used the memos to go around them.
No ... Let me give you an example. Unlike most of you, I design computer
systems. (Whenever possible, I write my own documentation, manuals, and
online help, which is why I love this mailing list.)
During one period, outside consultants were hired by the Board of
Directors. I created a simple program to automatically import the
managers' Excel or Lotus data into a humungous database table, and was
about to write another simple program to automatically parse the data by
category so it could be totalled, sorted, and used to report the data. My
boss told me NOT to write the second program -- that another project was
much more important, and that I was not to waste it on something they could
That would have been fine were it not for the fact that one of the
consultants wanted a report based on the aforementioned data. I very
clearly explained that I would first have to normalize the data, since very
wide tables produced erratic reporting results. Both my boss and the
consultant insisted that they didn't care about that, and that the results
would be close enough for their purposes, so to just go ahead and generate
the reports. I did so, adding a footer reflecting that the results were
unstable because the language used did not support wide tables, and that
the tables could be normalized to ensure accurate data. I was ordered to
reprint the report without that footer.
When we received our performance reviews, all members of the development
team got negative reviews for contrived reasons (ostensibly proving that my
boss had done a great job, but that the morons on the team had screwed
everything up). Mine was that I had screwed up things for the Board's
consultants by issuing inaccurate reports. My boss "didn't remember" any
of my warnings about the stability of the data,
and had "never seen" the report with the footers. (When I produced a copy
I'd saved, he had "never seen it before".) By that time, the consultant
was long gone -- and would probably have supported him, anyway, since it
made her look good to promptly complete her analyses, and she wouldn't have
wanted to admit that she had known all along that the figures were not
I'm still uncertain how to handle that sort of thing in the future --
wherein I'm directed to do something I know won't work, and forbidden
either spend the time to make it work or to even document that the results
are not dependable.
I am deeply grateful for all the suggestions I've received here, and will
thank each of you individually.