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.
Roughly three years ago, I was asked to take on a moonlighting project with option to turn it into a full-time gig when the start-up got off the ground. They started out asking for a "technical writer", but it soon became apparent that they actually wanted a senior-master engineer to lead (and perform some...) hardware, software, and systems architecture.
Their view was that the technical writer was the person who would just write the detailed design documents (from his/my head and from some early back-of-napkin specs) and then they'd hire coders who would write all the device and system and network code to "make it happen". Similar idea for the hardware, though they had a partially functional (table-top, twenty-pound) mock-up of a device that was eventually to be worn on a child's wrist. Oh, and did I mention some substantial and tricky database design to with all the rest?
Much as I would have _liked_ to be their chief technology officer and most of their senior engineering staff, I had to break the news and bow out. Three years later, I think there's still some aspect of the original dream extant, but two of the three principals have departed, and the remaining show is dancing rapidly sideways. In the interim, I steered them to an engineering services company that helped them start the productization and system development process.
So yeah, educating the client is often a big part of the negotiation process, and I really don't like it.
It's not that I don't like educating/teaching - it's one of my favorite things to do - it's that I expend the effort for the benefit of the next guy whom they actually hire. Few folks are so centered and self-contained that they don't feel embarrassed to have the extent of their ignorance revealed - no matter how gently - so they tend to thank the person who taught them the difference, then hire somebody else who doesn't know how clueless they were. (Never mind that that level of cluelessness will continue to shine for the next guy... At least the next guy gets the paying gig.) :-)
- Kevin ( I am not a cynic - I just play one on TV)
> -----Original Message-----
> From: Gérald Bourguignon [mailto:gbourguignon -at- abrahamcomm -dot- ca]
> Sent: Tuesday, April 21, 2009 3:50 PM
> To: McLauchlan, Kevin; Kathleen MacDowell; Milan Davidovic
> Cc: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Re: Safety manuals and credentials
>
> That's exactly what I've learned from the responses I've
> received. I don't
> yet know who the potential client is, except that their
> product is related
> to safety on construction sites. I suspect that they are
> somewhat ignorant
> when it comes to the role of a technical writer. I worked for a local
> electronics manufacturer and the information regarding
> electrical safety
> came from a compliance engineer. All I did was add it to the
> front matter of
> the manual and apply the formatting. For content, the manuals
> were always
> reviewed by SMEs wherever I worked.
>
> Thanks to everyone for their responses. I now have a much
> clearer idea of
> how to respond to this question.
>
> Best regards,
> Gerald
>
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
