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: Trouble working with a SME From:John Posada <jposada -at- NOTES -dot- CC -dot- BELLCORE -dot- COM> Date:Thu, 31 Oct 1996 14:23:00 -0500
To: TECHWR-L @ LISTSERV.OKSTATE.EDU @ smtp
From: melindac @ CAPSOFT.COM ("Melinda M. Carr") @ smtp
Date: 10/31/96 09:37:55 AM
Subject: Trouble working with a SME
let me tell you a story...
I write proposals for a telecommunications company and as part of the process,
receive material from various SMEs, tech people, managers, and sundry other
They have their job and I have mine.
Part of what i do is to incorporate material, mmake it look like it was written
by humans, and to check for inconsistancies.
After we incorporate their material, we send out versions for "pink team
reviews), which is simply a process where the tech people make sure that based
on everyone's input, the answers are still correct and to make some answers
They then give me additional input, i incorpprate it into the document, and
make it available for examination again. This may happen several times, based
on the size, complexity, etc.
Most times, we accept their input. However, sometimes we don't , and most
understand that we are able to do this.
Last November, I was involved with a particular group that was know to
micromanage each proposal...perhaps because they were know to do this, I was
assigned as the writer.
During one particular episode, I was given instructions that were obviously my
domain, such as a preference on how many levels deep the Table of Contents was
When I told the person that I was going to do it my may, I was told "..we want
a different writer since you aren't being responsive to our needs."
I replied back that I'm not SUPPOSEDSI TO BE RESPONSIVE TO THEIR NEEDS. I'm
supposed to be responsive to the company's needs, the customer's needs and my
boss's needs. Their job is to get the material to me accuratly, and their job
is done. What I do with it is none of their business. They hung up on me,
contacted my boss, and she told them the same thing. They wernt off and
pouted, but the job went out anyway.
Two months later, when they needed a writer for another project, they requested
that I be the writer.
The reason...they accepted that I had as much responsibility for my part as
they do for theirs and that by all doing their part the way it's supposed to
get done, they get the best product possible.
To make a long story short, if your boss understands that your part is just as
important as their, then your boss will tell that particular person to just do
their job and accept that you will do yours.
- Technical Proposal Writer
Bell Communications Research
(908) 699-5839 (W)
jposada -at- notes -dot- cc -dot- bellcore -dot- com
"Its wonderful to be here in the great state of Chicago"
- Vice President Dan Quayle, 4/30/91
I don't speak for my employer and they return the favor
Okay, I need a reality check. I have been at this company for almost
three years and have never had any trouble working with the programmers
before, but now my manager and I find ourselves head-to-head with one
programmer far too often.
The crux of the matter is that he likes to review the documentation (okay
so far); make copious suggestions on technical matters, organization,
word choice, writing style (sometimes annoying but still okay), almost
all followed by exclamation points (definitely annoying but bearable);
and receive an explanation for each suggestion that we do not implement
(???). It has never been our standard practice to provide feedback to
reviewers on why we don't take some suggestions. My gut reaction is that
this is a bad idea (in part because explanations when given are rarely
accepted and usually spawn a long e-mail exchange designed to convince me