This is the unintentional second installment of Customer and Content’s book review series. Well, it’s intentional, in that I’m writing it of my own free will, but I wasn’t intending to write a series of book reviews. Although calling two articles a “series” might be a bit much.
When I attended the Information Development World conference I picked up a copy of Val Swisher’s Global Content Strategy: A Primer. I had just been asked to figure out what it would take to translate our product documentation and UI text, so I needed to learn as much as possible about translation and localization, as quickly as possible.
Global Content Strategy fits that requirement perfectly. It’s concise and to the point, and after reading it I was able to pt together a viable strategy, and talk to localization contractors without sounding like an idiot (always a huge fear of mine).
But this is a review of a different book.
I attended the TCCamp conference…er…unconference last weekend. Short review: I enjoyed it (again!). I attended Tom Johnson’s great intro to API documentation, I talked to some interesting people, and I got some practical advice during the three discussion sessions.
And I won an iPad Air 2 (thanks to XMetaL/JustSystems), which is FREAKIN’ AWESOME.
But I want to focus on one topic that came up during the “Technical Communication in Agile” discussion: the concept of Minimum Viable Documentation.
A big part of a technical communicator’s job is research. The information we use to create content comes from a wide variety of sources: technical specs, product research documents, business proposals, white papers, internal wikis, customer support tickets…
And even from actual people. There’s lot of good info locked away in our coworkers’ heads. Getting to that info isn’t always easy, but I’m honestly surprised how often one question comes up both in interviews and in discussions with other tech writers: “How do you work with engineers?”
A question that comes up regularly on Linked in forums is “What are the most important skills for a technical communicator to have?” I used to have a quick answer for that, but I realize it was based on how I learned to technical writing. But now many people in techcomm won’t be using a complex desktop publishing program to write manuals designed for print. They won’t be relying on the work of editors, illustrators, and a production team.
I’m writing this in a theater that’s filling up with people. I’m here for my youngest daughter’s dance recital. She’s dancing in two groups, both at the very end of the first act. I’ve got a long time to wait.
I spent last week researching support and learning management systems, working on a documentation delivery schedule for the rest of the year, and responding to a few complex support cases.
Those support cases, along with some comments from other users, have made me rethink my opinion of FAQs. Maybe it’s more accurate to say that this feedback is pushing me in a direction that I’ve been trying to avoid, while I knew that I was fighting the inevitable.
Connie Giordano has an interesting take (and a reader poll) on technical writing as a craft vs. a commodity. She’s writing something of a rebuttal to my post about the same topic. When I checked before posting this, the results were tilting towards “Tech writing is a hybrid profession,” slightly ahead of “Heck yes we’re craftspeople!” I voted for “hybrid” even though I’m not entirely sure what that means. But I think it’s closer to my argument.
Continue reading “Responding to Craft vs. Commodity”
When I was talking to people at the Write the Docs conference, I had a couple of interesting conversations with people who were weighing the costs and benefits of moving from a large company to a small startup. I prefer working for smaller companies, but I’ve been through this decision process a few times, and I’ve seen the good and bad of both large and small companies.
I can’t tell you much about being a contractor, though. I’ve only dabbled in it, and all I can tell you is that it made my tax returns slightly more confusing.
Two big things happened to me last week. I attended a technical communications conference and it was a worthwhile experience. I picked up a lot of good information, and I tried to apply the tips that people gave me in comments to my I don’t get conferences post.