A bit of background – I started out as a Data Systems Tech, during my stretch with the Navy. Back when the computers were bigger that a Sub Zero wall-mount refrigerator – and kept just about as cold. But they could crunch a bunch of square roots, in a pair of seconds. Though it still makes me shudder, when I think about the level of the technology used, to put that first man on the moon, back in 1969.
My initial foray into tech writing came while working for an early manufacturer of CRT computer terminals. I was enlisted because of an apparently unique ability to submit technically detailed Service Reports. Something a little more detailed that “fixed’.” And that worked into documenting a number of early ad hoc design changes, that had been made to equipment in the field.
Working in field service had its moments – both harrowing and rewarding. And led to working more closely with a number of the guys in Engineering. As well as getting shoehorned into writing a number of Engineering Change Orders, for the production lines.
Add to that, being called on to pull together some of the earliest training materials, and I think the die was set.
I never went to university – though I would’ve liked to. But, being more of a can-do kind of guy, I seemed to gravitate to those jobs where a higher premium was put on simply getting the job done. And, except to say that writing has been part and parcel of my working life for well over 40 years, I’ve always been able to knock out clearly written theory of operation sheets, technical information, or User Guides – for service technicians and customers, alike.
I do point to the number of years spent in hands-on problem solving – working face to face and on the phone with service providers, manufacturing representatives, and customers alike – with having greatly enlarged my capacity for critical thinking, and broadened the communication skills. And for having honed the writing, to where I’m quickly able to see and ski the fall line – in moving from point to point – while outlining and filling in the blanks, for a new technical publication.
That’s not to say that, as a lifetime autodidact (self-educated neophyte), I haven’t digested any number of Rhetoric Handbooks and Writing Style Guides. Or that I haven’t had occasion to directly mine information from between the red covers of The Chicago Manual of Style. Not to mention the Microsoft Manual of Style for Technical Publications. But I spent 6 of the last 10 years working in customer support – pressed into the role of technical adviser. And at a time when the whole industry was going through a major shift in attitude, towards customer service in general. It was a wonderful experience, that greatly informed my sensibilities about technical writing from that time.
Among other things,
- Consumers need clear, concise, uncomplicated, and unambiguous instructions – delivered in a helpful, conversational ‘tone.’
- With Step-by-step, Numbered Bullet Points.
- Touching on any points, where confusion might arise.
- Using NO unexplained acronyms or technical terms – which often do little more than obfuscate and arrogate information. To where it’s only barely understood by a trained technician.*
*Actually, most technicians appreciate and understand material that’s easier to read. Without having to continually re-read, trying to make sense out of that little bit of information they’re actually looking for, to help solve a problem. (One of the reasons I specialize in updated rewrites of awkward, cumbersome, inaccurate User Guides, and Tech Manuals.)
The other thing I get a kick out of – as much as the writing – is working with graphic design and layout.
( I’d probably be taking myself way too seriously, to even suggest that it approaches something of an art.)
So please don’t hesitate to give me a call.