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 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:
To be successful, technical communication professionals must present themselves in a way that clearly describes the value they bring to organizations.
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”.
Communication Spectrum
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.
Footnote: Doc-to-Help
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.
To set the record straight: Doc-To-Help is not a complex component content management system and we have never claimed it is. What we claim is that is is a great tool for people who want to write and single source to many deliverables without jumping through hoops.We have a strong following that proves there is a place for that.
If you have had a negative experience with Doc-To-Help and need help, we are here. Contact us any time.
Hi Noz,
It’s unlikely that Doc-to-Help controls their ad placement, so the juxtaposition is just not their fault. Why ruin an interesting post with a cheap shot? XML is not appropriate for everyone.
-Sarah
Hi Sarah, I noted that it was the publisher and to be more accurate I’ve just
Hi Dan, I appreciate that you’re engaging the comment directly. I haven’t had a negative comment with with Doc-To-Help itself, but I’ve had repeated negative experience having to do ‘clean-up’ work at clients because of the ‘press a button and reuse happens’ mentality that this particular ad professes.
I’m sure you’ve got lots of happy customers – Word itself is a very popular tool for tech docs and has an enormously strong following – but I don’t think that that constitutes ‘proof’ that it’s a good long-term solution for professional technical communicators.
As I said to Sarah, I’m going to follow-up with a more detailed post qualifying and explaining my “shot” at the ad.
I’ve been in the same tech writing position for eight years, and I’ve seen writers come and go, some to other tech writing jobs, but a few to other positions in the company — implementation and business analyst — and their ex-tech writing position is viewed as a stepping stone to something better. In fact, I’ve become rather glum on the subject, sensing the change in the wind that’s reference in the Molisani/Abel article.
I’ve been making the argument that our department should push towards a wiki solution. Although it seems that wikis haven’t had the impact in documentation that I thought they might, I still feel that they are one solution to our role within the larger enterprise. All those skills mentioned in the article can be used freely within the wiki — hopefully spreading it throughout the company, beyond the traditional area of documentation — while still keeping us firmly in our comfort zone of the written word. We become facilitators of content, ushering newbies into wiki culture while performing gardening, creation, and design roles within the wiki itself.
This comment has been removed by the author.
Hi Mike,
Interesting to hear from someone seeing this first-hand. WIKI’s are just technology. Technology usually doesn’t actually *do* anything, it just enables people who can, if they put in the time, effort, thought and discipline, re-engineer the way that they think and work together.
WIKI isn’t a solution to anything. The route of the problem, as you say, is the role of TechComm within the enterprise and the ability to collaborate within it.
The idea of becoming facilitators and garderners is a good one – I’m talking a lot about content curation these days (http://bit.ly/HGqcbZ). The question is usually do your colleagues get it? Not how, but *why* would they participate? Nail that, and the “how” becomes truly secondary. Motivation is many times greater a barrier than software.