Top 3 tech comm lessons in 2011

2011 was an eventful year for me as a tech writer. Here are the three most important lessons I learned this year.

Content strategy can change tech comm in 2 ways

… and only one of them is up to us tech writers:

  • Tech comm departments can engage in content strategy bottom-up, connect with stakeholders in training, customer services, marketing, and producct management to try to break down silos, reuse content and make content a corporate asset. One way to do this was the topic of Ray Gallon’s webinar “Content Strategy for Software Development”.
  • Corporations can can engage in content strategy top-down and essentially change the way the organization works. The objective is essentially the same as above, the main difference is who’s driving it. While tech writers cannot do it without management support, managers may decide to relegate tech comms to one of many stakeholders – which I think would be a pity. tekom’s Content Strategy day offered several sessions which discussed corporate content strategies.

The “big disconnect” is closing

The “big disconnect” is the difference in IT innovation between consumer IT and corporate IT. Geoffrey Moore coined the phrase in an AIIM white paper and presentation: “How can it be that I am so powerful as a consumer and so lame as an employee?” Earlier, I wrote about exploiting the big disconnect as a tech writer.

The reason it’s closing in tech comm is that consumer web sites have appropriated help systems and all their benefits, so the use cases and business models finally catch up with user demands and technologies, as Scott Abel pointed out in his tekom keynote address.

Content migration is about people first

In summer, our team of writers embarked on the journey towards structured authoring. One of the surprises to me as we proceeded was that metaphorically speaking, for every hour I spend moving content, I’m spending another hour moving minds.

Your turn

What did you learn about tech writing in 2011? Feel free to leave a comment.


4 Responses

  1. The biggest lesson I learn t this year is never to assume what your users know and what they do not know unless you have actually spoken with them 🙂

    • Thank you, Shweta, yes, that is a lesson I regularly have to remind myself of! (Though it took me some more time to find out that users don’t always know what good and maintainable documentation looks like…)

      • That is true, they are as is it not interested in how the documentation is, or how good and maintained it is, I believe. They are just interested in getting answers to their queries. What do you say?

  2. @ Shweta: I think it’s very important that my documentation is good, up-to-date and maintainable, but I can’t necessarily ask my users what good documentation is. For example, one user might prefer the FAQ format, but insist that it is only good if it answers each of his questions. However, it is very hard to create such complete FAQs and to maintain them, and many users find them difficult to search and browse.

    So I need to listen to and respect my users’ needs, but most of the time I need to abstract and convert them into something I can implement. And some of their requirements might not be feasible at all.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: