To be successful, technical communication professionals must present themselves in a way that clearly describes the value they bring to organizations.
Tech Comm 2.0 – Article Thoughts [NF0]
I just read (devoured) the new article by two ragingly clever and engaging personalities in the Content World: Jack Molisani and Scott Abel. The article was entitled: Tech Comm 2.0: Reinventing our Relevance in the 2000s. The central thesis is that Technical Communicators have to rethink and re-market themselves in the wake of overwhelming market changes if they want to thrive and survive.
The advice for is Tech Communicators / Tech Writers to stop envisioning themselves in these terms (you’re not valuable because you write words good n’ stuff) and expand their footprint into “professionals who solve business problems”.
Or as they put it:
I think the article was good. In fact, it reminds me very much of my own personal term war, not against the word “Writer”, but the word “document”. I find “documentation” to be a passive and retrospective act. It seems by definition to not be part of product development, but something that simply reflects – documents – the facts of the product in a text-based form. That’s all sorts a’ awful.
Scott and Jack even singled out my favourite pet hate, documents that say things like “Enter your name in the name field”.
So although I’m sympathetic to the cause, my only criticism is that finishing it I felt the TC community was given instruction and impetus to act, and a helpful and reassuring catalogue of the tools with which to take action, but what they’re supposed to do wasn’t quite clear.
In the “TC as a profession” section there was a list of jobs that are typical in product companies. Everything from Product Manager, Business Analyst and Product Architects to Marketers, Sales Reps and Tech Support. All of which used skills that were listed as being similar to core technical communicator skills.
In the “Lather, rinse, repeat” section, it almost seemed to me TCs should pick from the list of the jobs whichever they feel like and go be one of those instead of being TCs/TWs. I know Scott and Jack and, as said, they’re both very clever. I don’t think they’re saying TCs should go be Sales Reps or Dev engineers per se (but if you have those skills why not), so some differentiation and clarification at the end would have been good.
The reason I’m blogging this particular article is put in my support, but also to highlight the difference between “most” (always dangerous to generalise”) Tech Writers and the people who staff these other jobs. The difference is that most tech writers are strongest in written communication. Tech Writers who can deliver strong live presentations, engaging training or a compelling sales pitch are more rare.
There’s a sort of skills spectrum between live, real-time and persuasive communications and supporting, asynchronous communication – some of us are really good live but can’t write, some are great on paper, but PowerPoint and a microphone are our worst enemies. I think this distinction got left out of the article.
My own two cents here are that if you are a writer branching out, it’s good to try to establish where you are on that communication spectrum, and match yourself to the specialism that works best. If you’re good with words, but need to rehearse and be well prepared to deliver them orally, you can probably do great video voice-overs or tutorial scripts or even write training material, but delivering training material or handling angry customers on tech support lines is probably not for you.
I’m only adding some detail to the main message: know thyself. That’s not limit thyself, but put your efforts into something that’s leveraging your core strengths. The idea that technical communicators need to specialise and market themselves differently is, for me, a no brainer.
If you haven’t already, read the article right now.
The first page of the article is a full-page ad for Doc-to-Help’s “multiplatform” solution. I find the ad placement incredibly ironic. I’m assuming that was the publisher’s decision (as opposed to the author’s or ComponentOne’s).
Scott and Jack are breaking it down as to why TCs need to think outside the box, get ready for really new scenarios and ways of operating, and Doc-to-Help are essentially saying, “Screw it! Just do the same ol’ junk in Word and we’ll automagic it into future-proof multi-channel content for you! TADA! Put your heads firmly back in the sand reassured by the wonders of software tools!”
It’s a whole other blog as to all the reasons that that approach and way of thinking are wrong, wrong and also very very wrong. It is the Tech Comms equivalent of traditional publishers who think that saving a magazine as PDF is effectively preparing their content for mobile delivery.
The article mentions XML in the first few lines and gives the example case-study of iFixit.com, another XML-based platform. What is core to XML and multi-platform deliver is modularity. ComponentOne (the irony just won’t stop) are encouraging you to keep going with linear, ‘book—style’ documentation, and just pressing a button and making them into mobile deliverables.
Your documents are never “one component”, they’re a rich combination of different entities that are of interest to different users in different contexts at different times… I don’t want to go into it here, but read some of the books on the reading list, especially those by Ann Rockley, and you’ll learn why this approach has no future.
The future is not in multi-platform tools, it’s in multi-platform thinking. More on that in my recent presentation at Content Strategy Applied in London.