Technical writers and conversations

I’m continuing my musings on connected conversations and tech pubs since there were such great comments and conversations going on with it.

I had an “ah ha” moment at SXSW Interactive, when one of the social media metrics panelists Rohit Bhargava said he sees three areas or channels for measurable conversations – Public Relations, Marketing (Sales), and Customer Support.

For me, those three categories crystallized this connection: where our role as tech pubs is strongest in an organization, that’s where we might start successful conversations.

Gordon McLean’s post cites Marketing and Sales as a strong tie-in, and sure, I’ve seen that and worked in that type of environment. Marketing concepts such as Business Service Management and white papers about ITIL were the primary reason and communication idea I used when I started my blog at talk.bmc in 2005. Product documentation that helps drive sales or close deals is a great method for proving our value.

Tech support seems the best alignment for many companies, as Charles Jeter’s follow-up points out. Tech publications that drive down support costs are another area where value proof lies.

Where tech writers don’t stand much of a chance, based on my limited experience, is public relations. We tend to be a fact-finding lot, not the “spin doctor” type, nor are we necessarily prepared or educated in the ways of crisis communication. I myself cringe to think of having to write blog entries for Southwest Airlines after the recent safety fine. There’s a great case study on crisis communications at BlogWrite for CEOs – Case Study: Southwest Airlines’ Corporate Blog and Crisis Communications and reading it makes me realize how difficult it can be to blog for a company as a representative of a company.

Now, my question is, will companies pay technical writers for a conversation rather than a deliverable? Perhaps only if there are some metrics to prove worth and value.


  • April 4, 2008 - 3:00 pm | Permalink

    A friend of mine just emailed me one of your articles from a while back. I read that one a few more. Really enjoy your blog. Thanks.

    Jason Whitmen

  • April 5, 2008 - 1:18 am | Permalink

    In my own little bubble of experience, there seems to be a change in the way companies buy products these days. Twice now I (as head of the Publications department) have been told that the documentation helped clinch a deal.

    Now, I know that we didn’t MAKE the deal, but it’s telling that customers are now asking about the information side of the product. Whether this is cause and effect, or the rise of the awareness of the importance of information (thank you, internets!) I’m unsure… but it’s a huge lever when the Sales Director and CTO have a discussion about technical publications with a customer!

  • Pingback: Public Relations Nightmares » Blog Archive » Technical writers and conversations

  • April 5, 2008 - 5:08 pm | Permalink

    Interesting thread, both the original and the extension. I don’t know that any writer is ever going to be comfortable writing in all genres. (For example, I’m currently working on a project where all the training material has been written by non-writers without instructional-design backgrounds, and it shows.) However, as times change, there are instances where the usual business models have crossed over.

    Example – documentation for World of WarCraft was built by users, even a script that allows users to search for each game character’s properties and migration patterns – per software release! This was all user-generated and maintained, evidently (I’m not into WoW myself, so have to trust the presenter on this one.) Would it even have been realistic to expect the writer to anticipate that users would have wanted this? Probably not – it became a new documentation genre.

    OTOH, I do use Expression Engine, which is a micro-CMS/ power-blogging platform. There, the developers contribute to a forum, and that forms the basis of the documentation. It’s not the best documentation, and if they were a larger company, they’d probably have an editor who takes user-generated documentation, pulls it all together editorially, and keeps it organized, etc.

    Also, just as documentation creation is all over the map at the moment, its value to potential clients is all over the map. Where its contribution to user adoption is a major factor, it ranks higher; in more traditional business models, or where the purchasing process is set up to compare straight-up features, then this aspect often still gets overlooked.

    I just realized my comment is rather all over the map…hmmm…at the risk of sounding scattered, I’m going to leave it.

  • April 7, 2008 - 4:33 pm | Permalink

    Hi Anne,

    I tend to disagree with this statement:

    “Where tech writers don’t stand much of a chance, based on my limited experience, is public relations. We tend to be a fact-finding lot, not the “spin doctor” type, nor are we necessarily prepared or educated in the ways of crisis communication.”

    While I absolutely agree to the ‘fact-finding lot’ part (I love that in fact!) in places where we support open source projects, we are definitely capable of spinning the public relations piece. Having worked like this for some time now, I have to note that the writers – along with everyone else involved in the project – hold at least some of the collective memory of the project. This means that when a particular function goes a little wonky and a user reports it to the team, knowing the memory of how that function was supposed to work and adding their writing abilities to the mix means that the writers may in fact be the best to handle the spin doctoring while the developers fix the wonkiness. Besides, having the writers involved in answering the user forum questions often gives outsiders the feel that everyone is contributing to user adoption, which is a little towards the ideas that Rahel Ann Bailie presented here.

    As projects go to open source, we all have the opportunity to spin things to a certain degree. I think it adds a certain creativity to our position … a fun little skill to add to the resume. I think it just goes to show how vastly our writing roles and opportunities are changing.

    Just my opinion.


  • April 8, 2008 - 10:11 am | Permalink

    My technical documentation about a software product will end up on the public web, so in essence the documentation is serving a public relations function as well as user assistance function.

    I didn’t attend that particular SXSW talk, but I’m guessing that a PR conversation implies being responsive to current events and trying to formulate newsworthy events. That implies ongoing duties, something antithetical to project-based work I’m used to.

    By the way, you might enjoy a piece I did a long time ago about Roxio’s great documentation and lousy technical support .

  • April 8, 2008 - 1:31 pm | Permalink

    Thanks, all, for the comments!

    Virginia, you are a good, loyal community member for putting a good spin on your product’s inevitable shortcomings, although I would still categorize your example under “support” since it’s a little bit vague on the consequences of a feature going wonky. I’m guessing no one died as a result of wonkiness. 🙂 I think of crisis communication as the more life- or career-threatening sorts of information control, I guess. I do agree that in open source, there’s a supportive, community, public relations element. But, when an open source product or brand has a “really bad day” (think Wikipedia scandals? Or think life-threatening crisis situation with data loss?), do they call in the PR firms, or does the community just rally around the community members with no need for the pubic relations and media experts? I’m not sure what goes on behind the scenes. I’m not necessarily talking about “spinning” data loss from a bad into a good, but rather, diffusing potentially damaging press coverage, that sort of thing. I know these “crisis” events occur rarely, but when they do, I know I’d steer clear, but that’s only my current perspective. 🙂 I appreciate your view from the front seats of the open source documentation train, great example.

    Rahel – I love the World of Warcraft example! Those players are so inventive in their pursuit of the perfect game strategies. I love it.

  • April 9, 2008 - 9:40 am | Permalink

    Aahh… I see what you mean and yes, I can see how steering clear of crisis events would be a natural reaction. Perhaps I’m naive (it’s absolutely possible), but if I the writer as part of a very small development team don’t admit to the crisis situation, that could look even worse I think with an open source project. That’s one of the scariest things about open source, all the problems show and all the arguments occur in the public, so if we did cause a crisis – not probably of the life-and-death variety, but potentially a bad data mashup in the hands of an inexperienced user – and then failed to admit to it, we could get creamed from the coverage. Ouch.

    Thanks for the perspective … I think I was being naive. I suppose I’ve still a lot to learn *sigh*.


  • April 9, 2008 - 8:29 pm | Permalink

    Virginia, I think you’re on to something about the transparency that is required by Open Source, and what is interesting to me is to observe how it will change the way that “spin” works – because I truly do believe that when transparency is the priority, all other potential bad news messages get re-visited. What I mean by that is, if a user feels like she is part of a team that works together and is transparent through-and-through, then most situations wouldn’t necessarily reach “scandal” level or attract media hype. Maybe.

    Also, I really don’t mean to make you feel naïve because you’re not naïve, you just have a different open source perspective, and the rest of the world (myself included) is just now realizing the differences in communication for open source projects and enterprise projects.

    I know I’m still learning the differences in my open source endeavors, so I’m naïve in many ways too. 🙂 Thanks for the follow-up!

  • Leave a Reply