UK MadCap user group launches with two events

MadSIG, the MadCap UK & Europe user group, launches with two events in the UK in September. We are a handful of MadCap users who network to share expertise and support. Most of us are based in the UK, though I’m the Europe outlier who’s based in Germany (and sometimes Denmark).

MadSIG offers occasional meet-ups and also a LinkedIn group for feedback, ideas and resources. If you are a sole technical author, become part of a more personal group – in your own virtual home town rather than in the big city of the online forums!

MadSIG is a special interest group under the ISTC‘s umbrella – while you don’t need to be an ISTC member to join and participate, it’s certainly a good idea to take advantage of the society’s many benefits.

Meet with MadCap’s Mike Hamilton in Staines on 19 Sep

Mike Hamilton from MadCap is going to be at the Swan Hotel and Pub, The Hythe, Staines TW18 3JB, on Thursday 19th September from 7pm onwards. He’s generously offered to spend the evening talking MadCap with anyone who uses Flare and the other MadCap products, or is interested in finding out more about them.

If you would like to come, please let us know by email to MadSIG@ISTC.org.uk with your contact details, so we can update you if anything changes last minute. If you’ve got any specific topics you’d like to talk about, feel free to let us know, too.

Mike Hamilton has an encyclopaedic knowledge of the MadCap products, so bring your questions and, if you like, your projects, and get to know some other Flare fanatics from the South of England at the same time.

Inaugural MadSIG meeting at TCUK on 25 Sep

MadSIG holds its inaugural meeting at TCUK 2013. If you’re at TCUK anyway, this is your easiest chance to meet other MadCap users. We’ll meet at the Terrace Bar of the Marriott conference hotel on Wednesday, 25 Sep at 5 pm.

This meeting is a TCUK fringe event – that is, it is organised by us delegates, not by the conference itself. We are grateful that TCUK provides space and publicity.

My webinar slides as PDF handout

If you’ve attended my webinar “Getting ahead as a lone writer”, you might be interested in the slides in PDF:

They were supposed to be made available to attendees by the STC, but apparently that hasn’t happened as I’ve just learned yesterday.

If you have any more questions about the webinar or being a lone writer, feel free to browse my previous posts or pose your questions in a comment below.

So what’s it like to present a tech comm webinar?

Presenting a webinar isn’t much different from other “public” presentations, but the format has a few quirky effects and demands of its own.

On 29 February, I had the chance to present my first webinar. As with many first-time experiences, the newness of it all felt a little weird, there were some glitches, but altogether, it went alright. I think. I hope. Because I have had virtually no feedback.

Missing feedback

And that is already the most important difference to other presentations: You have next to no idea how you’re coming across. I never knew how vital even subtle cues are for presentations before a live audience. Does the audience follow along or do I need to be faster? Or slower? Frowns can signal that a point or a  joke didn’t get across. Genernal “antsiness” means I can pick up the pace a bit. Attentive smiles or chuckles indicate that I’m connecting. A webinar offers none of that.

The best I’ve seen other, better webinar presenters do is to ask at the beginning whether attendees can hear the audio and can see the slides changing. But after that, as a presenter, you’re on your own. It feels like talking into a tin-can telephone – without knowing whether the string is still taut.

Tin can phone, from http://www.wikihow.com

Fortunately, my webinar heroine Sarah O’Keefe had alerted me to this lack of immediate feedback. So I could identify it – but that didn’t make coping with it any less bewildering.

I think I forged ahead too fast and with too much urgency in the beginning, as if constantly groping for attention. Then I reminded myself to take a long, deep breath between my major sections.

The curse of convenient isolation

I think it’s also worth keeping in mind that even a live webinar catches everyone in a different time, place and context. What makes webinars so easy and convenient to attend, turns out to be a bit of a curse. I was presenting at 7 p.m. in Germany from my kitchen. Attendees in the US caught the webinar in the late morning or around noon, at the (home) office, I’m guessing.

This means you have less of a common context on which to build a dramatic arc or a feeling of community. In this regard, a webinar feels rather like broadcasting live television.

By contrast, some of the best live presentations I’ve witnessed gathered all attendees together, took them on a transformative trip and dropped them off at a different mental place. These were communal experiences which impart knowledge and change your perspective and rouse a group to action. I don’t think I’ve ever had that feeling in a webinar. And after my own experience, I don’t think it can be done, unless participants know each other better and have some way to interact with each other.

My webinar about getting ahead as a lone writer relies mainly on information sharing, but both times when I presented it at conferences, I was delighted to know that some attendees walked away with a feeling of “I’m not alone; I can do something about this, because others could, too.” Whether my webinar was successful along these lines, I don’t know.

Your turn

If you’ve considered presenting a webinar or have done so already, I’d love to hear your expectations and experiences. Feel free to leave a comment.

Get ahead as a lone tech writer with a STC webinar

A compact 1-hour STC webinar gives you the low-down about getting ahead as a lone writer, from tools to strategy – plus two words every lone writer should know how to use.

What?

Writers are often the only person in a company who create and maintain documentation. Lone writers who operate without a dedicated budget or specific managerial guidance find it hard to excel in their work. In this webinar, I will draw on my experience and explain how to make the most of this “benign neglect”:

• Develop your skills—and your career
• Raise your profile with management and colleagues
• Contribute to a corporate communication strategy
• Help your company to turn documentation from a cost center into assets

When?

Wednesday, 29 February 2012, wherever you are, right at your PC via the web:

• 10:00-11:00 PST – Los Angeles
• 11:00-12 noon MST – Denver
• 12:00-1:00 pm CST – Chicago
• 1:00-2:00 pm EST – New York City
• 18:00-19:00 GMT – London, Dublin
• 19:00-20:00 CET – Copenhagen, Berlin, Paris, Rome
• 23:30-0:30 IST – Mumbai, Bangalore

How?

Available as webinar, live or recorded, via the STC’s webinar site:

• STC student members: US$ 29
• STC members, sale price: US$ 59
• Not yet STC members: US$ 149

I hope to see you there!

My tcworld11 presentation “Getting ahead as a lone writer”

You can download the PDF slides to my presentation “Getting ahead as a lone writer” at tekom/tcworld in Wiesbaden on 19 October 2011:

My tcworld presentation "Getting ahead as a lone writer". Click to download the PDF.

For alternative formats and versions, see

• Getting ahead as a lone author, the article from ISTC’s Communicator.
• Getting ahead as a lone author, my TCUK presentation which is a little more verbose and may work better if you didn’t attend the session.

The presentation itself went very well, I think: It felt a bit strange at first to be presenting in English to what seemed to be largely a German audience. But the questions and answers session at the end showed that for many the language barrier was not a problem.

I want to thank the attentive and helpful venue staff and sound technician for their professional, attentive help! They made me feel welcome and in good hands.

Join me for “Getting ahead as a lone writer” at tekom

If you’re attending the tekom conference in Wiesbaden, consider joining me for my updated presentation “Getting ahead as a lone writer” on October 19 at 8:45 a.m. in room 12C as part of tekom’s international, English-speaking tcworld conference.

tcworld conference at Wiesbaden, Germany, in October 2011

My presentation will be an updated version of the session I did at TCUK 10. I will talk about how to overcome neglect and raise your profile by running your job (more) like a business with best practices. Here’s the abstract:

Lone writers are often the only person in the company who creates and maintains documentation. They often operate without a dedicated budget or specific managerial guidance. In this presentation, Kai Weber will draw on his experience to show lone writers how to make the most of this “benign neglect”:

• How you can still develop your skills – and your career
• How you can raise your profile with management and colleagues
• How you can contribute to a corporate communication strategy
• How you can help your company to turn documentation from a cost center into an asset

Twitter meetup afterwards

Join us on Wednesday at 9:35 am on the upper floor in the foyer in front of rooms 12C and D for a #techcomm meetup after the session! @rimo1012 and I, @techwriterkai, are presenting at the same time in adjacent rooms, so if you know us from twitter, stop by and say hi!

I’ll be blogging from the conference, so watch this space…

Framing tech comm: O’Reilly vs. Dangerfield

Technical communication is perceived in many different ways, some more constructive than others. Luckily, the framing of tech comm is the result of a dialogue/feedback loop, so we can help to shape how we come across.

Tim O’Reilly on the future

Consider Tim O’Reilly, quite a visionary technical communicator. He works to create “The Missing Manual for the Future“. O’Reilly explains it by quoting William Gibson: “The future is here, it is just not evenly distributed yet.” So we technical communicators can help to distribute the future evenly – a pretty noble mission to be on.

Or consider Kathy Sierra whose Kick Ass Curve taught me that my documentation can help users look good and suck less.

– Of course, just because I find cool quotes on the web doesn’t mean my work and I actually help to “distribute the future” (what does that really mean, anyway?) or help a single user suck less. But it’s the attitude that counts. These ideas inspire me. They give me a sense of the best I can aspire to with my documentation.

Rodney Dangerfield on respect

Photo by Jim Accordino, CC-BY-3.0 via Wikimedia Commons

Or consider these assessments:

• “No one reads the documentation.”
• “Nobody cares, but we gotta have it.”
• “This manual is unusable.”

They seem to be rather common, I sometimes even hear them from tech communicators who graduated from RDSP, the “Rodney Dangerfield School of Professions”. The school is named for its patron saint and his motto “I don’t get no respect, I tell ya…“. RDSP graduates tend to accept criticism, when they hear it often enough, not when they find it fundamentally and immutably true.

Actually, it’s worth finding out in a customer survey how many people do read the documentation – and while you’re at it, try to find out how customers use it and what they expect to find it. Maybe only a few care, but if a company cares enough to do documentation at all, they might as well do it right – and yes, you can get documentation done right on the 80/20 rule. And a manual that’s deemed unusable can be made better and clearer.

Tech communicators on their work

Most of the time, my work speaks for itself. But sometimes it cannot stand up against prejudice and misguided judgements. Then it needs my help. I don’t mean making excuses about a late spec or a review that fell through. I mean moving the critic into the position of the generic customer who reads my documentation and finds it useful.

And when I engage with my readers, whether they are colleagues or customers, they are frequently surprised how much thought goes into my documentation. They marvel that

• Documentation that offers less of a narrative is actually easier and faster to use in the majority of cases when customers look up specific questions.
• Many users welcome the separation of concepts and procedures, because they read concepts just once, but need to refer to clear, bare-bones procedures repeatedly.
• What has recently beefed up our marketing material is actually lifted verbatim from the documentation.
• When they find a mistake, I can tell them immediately what I will do to fix it and when it will be rolled out to customers.

This dialogue/feedback loop gives my work the chance to earn respect by virtue of its benefits. And it allows me to follow the goals that O’Reilly and Sierra have inspired in me.

Your turn

What’s your experience? Does it work to enlighten colleagues and customers just how cool your documentation actually is? Does it help? Please leave a comment.

Recommended read: Practice technical writing

Becoming a better tech writer requires practice.

Mike Pope, tech editor at Microsoft in Seattle, has a brilliant blog post about 12 ways to practice tech writing. The catch is he means “practice” like a musician, so you learn to do stuff better than yesterday – instead of just doing the same things over and over.

Over the last years, I’ve tried all 12 ways, and they’ve all helped me to become a better writer. And most of them can be fun, too, at least most of the time… 🙂

Here are just six of the ways as a teaser, but I highly recommend you head on over to Mike’s post to find out about all of them with details and examples.

1. Read other technical writing attentively.
2. Read about writing.
5. Writing something outside your usual material.
7. Edit someone else’s work.
10. Learn new tools and new ways to use your existing tools.
11. Talk to other writers.

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.