Top 4 benefits of writing a tech comm blog

Kai’s Tech Writing Blog was one year old last week! It’s been good to me, and the work it takes pays off in several benefits.

If you don’t keep a blog, my benefits below may help you decide whether you want to start one. And if you do have a blog, we can compare notes! 🙂

1. Improve ideas

My blog helps me to come to terms with trends and developments and to test drive new ideas. I usually try to have them thought through well enough, so I can publish something coherent and don’t just think out loud.

2. Connect with the community

My blog’s most important benefit is that I get to meet other tech writers who may have similar concerns, different solutions or interesting insights, whether they appear in posts on other blogs (see my blog roll on the right), in comments beneath my posts or on twitter. I get advice and can learn from smart and experienced people. And I can give back to the community when I can offer my experiences.

3. Picture progress

My blog lets me track my progress as a tech writer, much more so than weekly reports in my company. After several years, I don’t become a better tech writer by completing yet another manual, but rather by mastering a new method or by consolidating experiences into applicable insights. Such advances aren’t always immediately visible in a time sheet. In other words: My blog helps me to report on my development in a more personal, less corporate framework. Oh, and it’s nice to see the tag cloud changing (see Categories to the left)…

4. Write regularly

My blog has been habit-forming. From the start, one year ago, I decided to stick to a regular publication schedule with one or two posts per week. I still find that works best for me.

Writing 400 to 800 words per week, which usually don’t directly relate to my work at the office, has been a very good exercise. It encourages me to keep my eyes open for trends (even though I may take some time to pick them up). And it helps me to express myself clearly in less structured writing than my topics and manuals usually require.

– So that’s what motivates me to write one or two posts a week…

Your turn

If you keep a blog, what do you get out of it? If you’ve wondered about starting one, do you find these benefits reasonable or attractive? Please leave a comment.

Advertisement

Getting ahead as a lone author, the article

“Getting ahead as a lone author”, based on my presentation in last September’s TCUK conference, appeared as a 3.5-page article in the current Winter 2010 issue of ISTC’s Communicator.

Click to download the article in PDF.

I’ve covered lone authors over the last months in blog posts and in my presentation, after which Katherine Judge, commissioning editor of ISTC’s quarterly, asked me to write it up as an article which I share with you today.

It’s a concise summary of my talk, along these headings:

• Overcome benign neglect
• Buy yourself time
  • Implement topic-based authoring
  • Don’t test when you should be documenting
  • Learn to say ‘later’ and ‘no’
  • Control interruptions
• Treat documentation as a business
  • Make documentation an asset
  • Estimate documentation effort
  • Plan documentation properly
  • Embrace reporting and metrics

2011 megatrend in technical communications

I think this year’s megatrend for technical communicators and their managers, especially employed ones, is to position tech comm as a business in its own right – or to be redundant in the long run.

This is my conclusion after thinking about three astute predictions that Sarah O’Keefe recently blogged about.

– I know: I’m late to the predictions party. And I’m actually not very good at crystal ball gazing. I’m much better at reconfiguring what I find. So my contributions are comments and some additional reasons why I think Sarah’s right.

Three sides of the same coin

If you’ve read Sarah’s post, I’ll just remind you of the headings of her predictions:

• A schism in tech comm (traditional vs. modern tech comm)
• The age of accountability
• Increased focus on business value

If that doesn’t ring a bell, head on over and read her post, I’ll wait… 🙂

I think Sarah’s predictions are really three sides (?) of the same coin. And I’d be surprised to see a documentation team experience only one of them.

Business value

The lackluster attitude about documentation of “No one reads it, but you gotta have it” has been widely replaced by close scrutiny of its value add and ROI. I’ve recently seen a doc team’s initiative that had to present the same business case, including cost saved and break even, as any other internal initiative that wanted to spend some money. But more is at stake for us writers than playing the numbers game with managers and bean counters.

The question is how the tech comm team is perceived: As a cost center or as contributing to the corporate assets. The latter is of course more desirable and can only succeed when we break down departmental silos, when collaborate with other teams and become user advocates, see my earlier comment on Scriptorium’s blog.

Now take a step back and think of what that cost vs. asset question means to your job and your career outlook. To me, it’s awfully close to being seen as part of the problem or part of the solution…

Another reason why I think tech writers do well to consider and promote their business value is…

Accountability

Sarah’s second prediction follows directly from attention to business value: Once a company expects ROI from documentation, it will want to monitor the output. And that means to hold the documentation team accountable, not by measuring the quantity of produced stuff, but by measuring the quality of useful assets that have been efficiently produced. (It’ s worth keeping in mind the difference between accountability and responsibility; link courtesy of Jurgen Appelo and his presentation on authority and delegation.)

In the metrics, you may have some leverage: If you’ve ever tried it, you’ll find it’s awfully hard to come up with reliable metrics for documentation quality. The good news is that your managers will usually find it even harder. That’s a chance for you to apply some “Top strategies to embrace cost metrics” .

If you’re alert and on top of your game, you’ll find you have some agency in how you’re measured. It won’t always be your choice alone, but to a certain extent, you can choose sides in…

The schism in tech communication

The distinction looks crude, but I’ve found that many technical writers fall into one of the two camps that Sarah has identified:

• “Traditional tech writers” who produce communication deliverables, such as user manuals and online help.
• “Modern tech communicators” who provide user assistance services as part of the customer experience.

Note that this distinction has nothing to do with quality! I know very diligent, highly qualified people in both groups, and I’ve seen sloppy work in conventional manuals and modern screencasts.

I believe how that schism plays out for each writer in a team has a lot to do with the accountability of the documentation team, the responsibility of the team members and the dynamics between the members: Ideally, both types complement each other – and can show management that they are strong and agile because of their complementary strengths.

Now what?

Okay, so treating your documentation as a business before everybody else does sounds reasonable. For specific next steps, may I recommend the slides from my TCUK presentation “Getting ahead as a lone writer” and my other blog posts for lone writers. Even if you’re not a lone writer, you’ll find many ideas also apply to documentation teams.

Your turn

What do you think? Are these trends part of a larger movement to economize and commodify technical writing? Or is it nothing new, not worth beating a dead horse over? Please leave a comment.

Instructions for everything

“If Ikea Made Instructions for Everything” is a brilliant spoof on (almost) wordless IKEA instructions by the folks over at CollegeHumor.

This made the rounds a few weeks ago on social networks. If you didn’t catch it then or want to revisit it, check it out now. I especially like the “Hädrönn Cjollidder”… 🙂

Learn about DITA in a couple of hours

DITA 101, second edition, by Ann Rockley and others is one of the best tool-independent books about DITA. It’s a good primer to learn about DITA in a couple of hours.

Strong context

The book excels in firmly embedding DITA’s technologies and workflows in the larger contect of structured writing and topic-based authoring.

I attribute this to the authors’ years of solid experience in these areas which comes through, especially in the earlier chapters.

“The value of structure in content,” the second chapter, illustrates structured writing with the obvious example of cooking recipes. Then it goes on to show you how to deduce a common structure from three realistically different recipes – which I hadn’t seen done in such a clear and concise way.

“Reuse: Today’s best practice,” the third chapter, takes a high-level perspective. First it acknowledges organizational habits and beliefs that often prevent reuse. Then it presents good business reasons and ROI measures that show why reuse makes sense.

Comprehensive, solid coverage

From the fourth chapter on, Rockley and her co-authors describe DITA and its elements very well from various angles:

• “Topics and maps – the basic building blocks of DITA” expands on the DITA specification with clear comments and helpful examples.
• “A day in the life of a DITA author” is very valuable for writers who are part of a DITA project. Writing DITA topics and maps is fundamentally different from writing manuals, and this chapter highlights the essential changes in the authoring workflow.
• “Planning for DITA” outlines the elements and roles in a DITA implementation project for the project manager. Don’t let the rather brief discussion fool you: Without analyzing content and reuse opportunities, without a content strategy and without covering all the project roles, you expose your DITA project to unnecessary risk.
• “Calculating ROI for your DITA project” has been added for the second edition. It’s by co-author Mark Lewis, based on his earlier white papers: “DITA Metrics: Cost Metrics” and “DITA Metrics: Similarities and Savings for Conrefs and Translation“. It expands on the ROI discussion of chapter 3 and creates minor inconsistencies that weren’t eliminated in the editing process.
• “Metadata” first introduces the topic and its benefits in general and at length. Then it describes the types and usefulness of metadata in DITA. This might seem a little pedestrian, but it’s actually helpful for more conventional writers and for managers. It ensures they fully understand this part of DITA which drives much of its efficiencies and workflows.
• “DITA and technology” explains elements and features to consider when you select a DITA tool, content management system or publishing system. This always tricky to do in a book as much depends on your processes, organization and budget. While the chapter cannot substitute for good consulting, it manages to point out what you get yourself into and what to look out for.
• “The advanced stuff” and “What’s new in DITA 1.2” continue the helpful elucidation of the DITA specification with comments and examples that was begun in the “Topics and maps” chapter.

Mediocre organization

For all its useful contents, the book deserves better, clearer organization!

• Redundancies and minor inconsistencies occur as concepts are defined and discussed in several places. For example, topics are defined on pages 4, 24 and 46. The newly added ROI chapter complements the ROI points in the third chapter, but neither has cross-references to the other.
• The index doesn’t always help you to connect all the occurrences and navigate the text.
• Chapters are not numbered, yet numbering of figures in each chapter starts at 1. It’s not a big problem, because references to figures always refer to the “nearest” number, it’s just irritating.

Formal errors

The book contains several errors which add to the impression of poor production values. They don’t hurt the overall message or comprehensibility, but they are annyoing anyway:

• Mixed up illustrations such as the properties box in Word (page 72) vs. the properties box from the File Manager (73)
• Spelling errors such as “somtimes” (1) and “execeptions” (16)
• Problems with articles such as “a author” (20) and or a system that “has ability to read this metadata” (77)
• Common language mistakes such “its” instead of “it’s” (52)

Lack of competition

Another reason why it’s still one of the best books on the topic is that there simply aren’t many others!

• Practical DITA by Julio Vazquez is the only serious contender, and its practical, in-the-trenches advice complements Rockley’s book very well.
• [More books are pointed out in the comments, thanks everybody! – Added January 11, 2010.]
• DITA Open Toolkit by “editors” Lambert M. Surhone, Mariam T. Tennoe, Susan F. Henssonow is a compilation of Wikipedia articles. Amazon reviewers call other titles produced by the same editing team and publisher a scam.

Of course, several other honorable and worthwhile books include articles or chapters on DITA and/or discuss DITA in context of specific tools.

My recommendation

Despite its shortcomings, the book’s own claim is valid: “If you’re in the process of implementing DITA, expect to do so in the future, or just want to learn more about it without having to wade through technical specifications, this is the book for you.”

I recommend that you read it if you are

• Involved in a project to implement DITA
• Writing or translating documentation in a DITA environment
• Managing technical writers

Your turn

Have you read this book? What’s your opinion? Can you recommend other books or resources about DITA? Feel free to leave a comment!

TCUK10 conference videos online

Speaking of conferences, one stream of 13 presentations at the ISTC’s conference TCUK10 was recorded, and the videos are now online.

Included are the two keynotes by Nokia’s David Black and by J Haynes of Haynes manuals, as well as Roger Hart on content strategy, Chris Atherton on the psychology of usability, and many more.

The slide from J Haynes’ presentation is both, a sign and a reason of Haynes’ success. Check out the presentation to hear the story behind it.

(My own presentation wasn’t recorded, and I like to believe it’s for the better… 🙂 )

Resolution for 2011: Attend a conference!

Attending a conference is the perfect professional new year’s resolution for us tech writers: Regardless of what other plans for improvement you (or your boss) have, tech comm conferences are the perfect platform to exchange ideas, learn about new methods and tools and generally recharge your enthusiasm!

If you’re a manager: Sending your tech writer to a conference is one of the easiest and best ways to motivate her or him and to ensure that your documentation is in step with trends and developments! See my previous posts about conferences for insights and raves.

(Alan Houser at tekom 2010, photo by jophan).

To start you off, here are some of the pivotal conferences in the US and in Europe – with one “write-in” conference in Israel added by commenters. The list had great help from Linda Urban who suggested most of the events in response to a twitter query. Thank you, Linda!

The list is sorted by date; the quotations are taken from the event web sites. If you have any advice about events listed or missing, help us all out and leave a comment below.

MEGAComm

February, 20; Ramat Gan (Tel Aviv), Israel

MEGAComm combines two related communities, technical communicators and MARCOM professionals, offering sessions and networking opportunities for both.

WritersUA

March, 13-16; Long Beach (Los Angeles), CA, USA

Developing the best possible user experience for all types of software applications through well-designed interfaces and helpful and accessible support information

CMS/DITA

April, 4-6; Baltimore, MD, USA

Content management and DITA in four conference segments: Management, information design and development, technical solutions, and tools and technology

STC Summit

May, 15-18; Sacramento, CA, USA

More than 80 sessions covering all aspects of technical writing, editing, project management, and publication production

Congility

May, 24-26; Gatwick (London), UK

Content Integration: Leveraging Content Standards to Improve Customer Experience; reducing cost of content and translation; implementing XML, DITA, reuse and dynamic publishing; applying content standards and best practices

UA Europe

June, 16-17; Brighton, UK

Latest industry trends, technical developments, and best practice in software user assistance and online help

CS Forum

September, 05-07; London, UK

Talks and interactive workshops for content strategists, web editors, user experience designers, technical writers, CMS developers

Technical Communication UK

September, 20-22; Oxford, UK

Technical Communication UK is the annual conference that aims to meet the needs of technical communicators, their managers and clients, from every corner of the industry.

tekom

October, 18-20; Wiesbaden, DE

Nearly 200 lectures, workshops, tutorials, and discussion groups on latest developments in technical communication and documentation

DITA Europe

November 7-8, Prague, CZ

Technical writers, IT professionals, information architects, publications managers meet publications professionals who have implemented DITA in their organizations and hear from representatives of key tools vendors who are actively supporting the DITA community.