What I learned from my pattern recognition talk at STC12

My session on pattern recognition for technical communicators was a very rewarding experience which taught me a lot. I thank Paul Mueller, Conference Manager, and Alyssa Fox, Program Committee Chair, for inviting me to speak, even though this was my first summit. Their friendly, indefatigable support set the tone for a high-energy, well-run conference.

If you want to revisit the session, here are the slides and the article from the proceedings. (If you haven’t attended the session, the article will probably be more helpful, for reasons explained below.)

Here’s a look behind the scenes of my talk and what I learned:

Two different roles

Attending a conference is not the same as speaking at one. Well, duh…

But what I mean is this: I took care to be an observant attendee before my own session, so I could gauge expectations and behaviors of attendees. Bluntly put: As attendee, I want my money’s worth. As speaker, I need to give my audience their money’s worth. Observing and knowing the first helped me achieve the second – or so I hope.

When I was still in academia, I was often put off by conference presenters whose ignorance of the audience’s interests and demands could be quite arrogant – and usually didn’t help the conference as a whole, either. So I wanted to avoid that.

Plus, one of the mantras of technical communicators is: “Know your audience!” How could I afford to ignore it at a tech comm conference?

“Unusual” works

I was unsure about my topic, because it was a bit unusual and off-the-wall: Tying the psychology of perception to technical communications – only to confirm what we do anyway, such as topic-based authoring and parallelism?

(Photo courtesy of Jamie Gillenwater)

On the other hand, I know from attending previous conferences, how much I enjoyed and benefitted from such sessions. A-ha moments are fun and enlightening, they work in TV science programs, so maybe they’ll work at a conference as well…

During the session, I was too busy to count heads, but I’m guessing I might have had an audience of 70 people maybe. There were other sessions to choose from. Or breakfast, since I was in the 8:30 slot. So I decided early on to get over my worries and trust in the general curiosity of tech writers. 🙂

Rehearsing pays

So practicing helps… Again: Well, duh…

Specifically, it allowed me to move beyond bullet points. I’ve seen many a session (less so at the summit) where presenters mainly read their slides. To me, those are usually not the best presentations. I don’t need great showmanship, but reading the slides seems as if the speaker serves the slides rather than vice versa.

I’ve tried to make at least the a-ha moments less reliant on words and bullet lists and more like an illustrated story. And I’ve found that decent images will remind me of the story just fine. (The last section about actually applying pattern recognition in tech comm has more bullet lists, so people could take notes.)

In addition, I found that rehearsing also helps me to “know time” (a pet obsession of mine; I even have a blog post about it). I’ve seen excellent presentations, but it peeves me a bit if they take up 58 of 60 minutes. I also learn by asking questions and by engaging with the speaker or others in the audience. And to me, it seems a bit careless to mar an excellent session by running overtime.

Budget your energy

I am really glad (and almost a little proud) that we’ve had such a lively, engaging discussion after my presentation. People suggested additional sources, propped up some of my arguments and ran with others, bringing up evolution, Edward Tufte’s information graphics and – privately afterwards – even Immanuel Kant!

My one regret is that by that time I was a bit exhausted and didn’t always do justice when repeating the question or comment for everybody in the room and for the recording. Not sure how I can achieve it, but I want to save not only time, but also energy to facilitate the discussion afterwards.

But all in all I think the session went well, I’ve really enjoyed the experience and am glad to contibute to our curious, friendly and supportive tech comm community!

Advertisement

Leah Guren’s Tales of Terror: Avoiding Project Disasters at STC12

Leah Guren presented a spunky, fast-paced session of project train wrecks that offered many lessons to managers and writers in tech comm projects. She presented disasters in five categories: Communication, people, politics, implementation and global issues.

“Failure to communicate”

When poor communication derails tech comm projects, it’s often due to missing information. Specifically, a project may have failed to ask the right questions (almost like performing due diligence) or failed to insist on getting the questions answered by the subject-matter experts or the specifications.

To prevent this problem, don’t write blind! Ensure that the project is clear not only on the product, but also on the users, their scenarios and workflows. This is a tricky issue that it afflicts even experienced tech comm’ers who may be tempted to wing it. But a checklist can help you to cover all your bases.

Of monster managers and quirky SMEs

People can jeopardize documentation projects, especially if they bring together people who don’t work together in projects very often. As a tech communicator, you might deal with an annoying monster manager breathing down your neck one minute and placate a quirky subject-matter expert the next.

Leah’s advice was straight and matter-of-fact: You can’t fix crazy, so don’t take it personally. You might even find yourself documenting irrational processes and workflows.

Of stakes and turf wars

Politics can endanger projects when agendas clash and turf wars arise between fiefdoms. This is actually the reason why so many organizations still run a balkanized business where development proceeds in distributed siloes. The resulting documentation often perfumes the pig though it can hardly help being inconsistent or disparate.

Consider carefully whether it’s worth the extra effort to try and clean up broken workflows and GUIs after the fact – or if you even have the leverage and the clout to be successful.

Of implementation constraints

Implementation can throw a wrench into a well-planned project, when you find you lack skills, resources or access to such. Sometimes you’ll see warning signs, such as “scope creep” when a project quickly becomes more complex than you thought originally. For example, Leah talked about a project which was to cover a complete product overhaul – and an SAP integration on top of it.

This is a case for a senior stakeholder or manager who needs to assess the situation and who can hopefully reschedule tasks or reassign resources.

Of intercultural complexity

A recent, often unexpected problem in tech comm is complexity due to globalization. Global business often doesn’t scale seamlessly, and tech comm (as all culturally contingent practices) even less so.

If your project involves countries, markets and languages you haven’t been involved with yet, take extra care. However, as companies find out again and again, there seems to be no fool-proof way to address this issue, other than trying to look at similar case studies.

Solutions and remedies

Leah held off suggested solutions until the end. The good news is that many projects can address many of the issues to an extent with standard project management tools and best practices.

• Use a project check list that defines scope, deadlines and involved participants, incl. their roles, goals and expectations. Include also SMEs and other stakeholders.
• Track project status meticulously and insist on regular reporting – from participants and to the steering committee.
• Have a contingency plan, if at all possible, which can buy you extra time or replacements for people if you need them.

Salvaging wrecks

But the best-laid plans don’t always guarantee success, so you might find yourself with a project train wreck that needs salvaging. Leah’s advice, at least to me, wasn’t revolutionary or new, but rather an encouragement to stay honest:

• Don’t hide from problems or difficult people. They won’t get better and they won’t disappear by themselves. Face them and address them as soon as possible. If nothing else, you’ll sleep better.
• Cut your losses, if you have to and find the right time to cut your losses, before you throw good money after bad. If you, be clear to everyone (including yourself) what went wrong and why.

The assurance of coaching

After her presentation (which already included several case studies that I have omitted above), Leah solicited further case studies and problems from the audience. This rounded out the session quite well which felt like coaching on speed.

For me, the most important take-away was that projects can and will go wrong for all kinds of reasons that are beyond our control. But if we are alert and honest to ourselves, we can salvage most of them, wrap them up with decent success and saved face.