Post Doc-Train Thoughts While Sitting in the Vancouver Airport

by Tom Johnson on May 12, 2008
categories: technical-writing

Doc Train has ended, and I'm sitting at the Vancouver airport waiting for my airplane. Lots of thoughts are coming to my head, in no particular order.

I interviewed about 12 people this year. I seem to have a knack for this -- tracking people down, asking if I can interview them, getting them talking, etc.

Actually, it has taken me three conferences to get this right. Last year, at Doc Train West 2007, I didn't have the right setup. I tried using a lavalier mic attached to the mic port of a Mac I borrowed. But I didn't realize the Mac wasn't reading the lavalier; it was using a built-in mic.

Then at the STC Summit in Minneapolis, I had the right equipment (a portal Zoom H4 recorder), but by and large I interviewed the wrong people in the wrong places. I did interview some presenters, but I spent too much time interviewing attendees.

This year at Doc Train West 2008, I had the right equipment and I talked to the right people in the right spaces. And it worked extremely well. I give you this advice if you ever try recording live interviews at conferences:

• Buy an H4 Zoom recorder.
• Use the built-in mics rather than an external mic.
• Interview people who are giving presentations.
• Find a quiet room where you can sit down with them.

Really the key is to interview presenters, because they automatically have something to say. They have a message they've been cramming and practicing. Conversations flow naturally, and they give you great content. In contrast, attendees have much less to say.

By and large interviewing is weird. I'm not a radio geek, I never did audio as a teenager. I just fell into podcasting and became a podcaster. It takes some tact and boldness to interview people at conferences. I think I learned this skill as a missionary in Venezuela -- a two year period where I spent almost every hour of the day talking to people I didn't know. Strangely, there are a ton of comparisons between being a missionary and seeking people to interview as a podcaster. You have to open your mouth, even when you're shy. You invite them to sit down and talk with you. You have to initiate contact and be a good listener. Okay, enough of that.

But seriously, it gets even weirder because now that I work for the Church, I had "LDS Church" printed below my name on my conference tag. This only adds to the questions. One person, seeing my name tag, shared her frustrations with the FLDS situation. Another person asked if I write religious tracts. Another said he was converting all of Scientology's documentation to XML. Several people asked if the Church has software and wondered exactly what I do.

The frequency of the last question (does the LDS Church have software?) is a little perplexing. Let's say you work for a company with 13 million employees, scattered across the globe, speaking 100+ languages, meeting in thousands of buildings, 120+ special conference centers, with complex financial contribution system, facilities maintenance, an ambassador program with 60,000 nomadic people spread out in geographically diverse locations, with some in delicate states of health. Not to mention numerous external properties, ranches, investments, and other equities. Also include hundreds of committees, with dynamic reporting and information sharing needs. On top of all this, add a twice-yearly general conference held in one location but distributed via satellite, TV, and radio across the globe, translated almost immediately, with a web distribution and extensive resources online. Not to mention handbooks, manuals, pamphlets, and other literary materials, videos, and CDs in multiple languages. Would a company like that need any kind of software to manage all that? Heck yes! Actually, it's a miracle that there are only 4 technical writers (and a lot of non-technical writers).

But enough of that. More on the conference. One of the incredible things about blogging is that it really does build relationships. This is especially noticeable at conferences, when you meet people whose blogs you've been reading and you immediately feel like you're a close friend, even if it's a first-time encounter. I feel I know tons of people at these conferences. I got to meet Theresa Putkey and Alan Porter for the first time, who I just recently interviewed. I met other podcast listeners. One listener ("Lisha") sat next to me in the same session and showed me the latest podcast she'd downloaded to her computer.

Were the sessions good? As good as any. I'm not sure how it happened, but my attention span during sessions has diminished greatly. As soon as a presenter starts droning away at a long bulleted list on a PowerPoint slide, it puts me to sleep. I open up the laptop, check Gmail, Twitter, and before you know it, I'm only half there.

However, when I'm interviewing someone for a podcast, I'm completely engaged. This is because I get to direct the topic and tempo of the conversation. If the interviewee starts to go in an uninteresting direction, I ask a question that brings it back onto the main raceway.

The light bulb moment for me happened during one of these podcast interviews. I was talking with Noz Urbina, who delivered a keynote one early morning. (By the way, when I explained this light bulb moment to my wife, she had little response and later said it was somewhat obvious. Many times the groundwork behind realizations, she said, are laid by numerous experiences, brought together by a simple observation someone states. She's right.)

Noz explained that as technical communicators integrate Web 2.0 feedback mechanisms to gather information from users — whether through comments on blogs, contributions to wikis, posts on forums, or other ways — the technical communicator transforms into a much more integral player in the user interface design, the task workflow, and the feature roadmap of the application.

Essentially, when you connect with your users in an integrated way, you become the business analyst, interaction designer, and product manager all in one. You suddenly know what the users want, what the users are experiencing. You are not just writing tech docs. Dude, you are leading the direction of the product!

And as you accrue this user experience knowledge, you begin to influence the project team in the direction they should be going. You become a leader rather than a follower. You aren't simply one who takes directions from an exec who isn't connected at all to the user base. The execs begins to come to you for information.

As I mentioned earlier, numerous other experiences laid the groundwork for this realization. In my current role on the User Education Team, I write tech docs, online help, quick reference guides, and role-based guides. But I also give training sessions to users, act as a point of contact when users have feature requests or problems, and take occasional support calls when users are confused.

I've been taking all the information I receive and channeling it back to the project leads. And I've noticed that I am contributing user feedback 100 to 1 (compared to what others send). I'm doing much more than simple technical writing.

As such, the term "technical writer" no longer describes what I do. Not even "technical communicator." Right now I'd take any wacky term, just to remove the stereotype that a technical writer's job is to "write documentation." Information designer, content strategist, user information lead, or whatever.

My light bulb moment was to realize that web 2.0 would forever change the role of the technical writer. The more I enable user feedback and content, the more I will understand users, and the more I understand users, the more central role I'll play in defining product roadmaps, guiding interface design, and making other key decisions.

The strange thing is, I don't even have any Web 2.0 formats integrated in my help. I deliver static content — online help, quick reference guides, and user guides. And live training. Once I flip on the Web 2.0 switch, the amount of feedback coming in will triple or quadruple, I'm sure of it.

I also attended several sessions on wikis, including one during the Unconference. The more I listened to Stewart Mader, the more I became convinced that wikis are the way to go. I've decided to go in a similar direction with my help deliverables. We have SharePoint 2007 at my organization, and as bad as Microsoft products sometimes are, they got many things right with SharePoint 2007 — namely, blogs, wikis, RSS feeds, and comprehensive search.

I plan to put my documentation into a wiki format, add a product blog, and drive users to this SharePoint site for documentation. Even though Atlassian Confluence offers better wiki functionality and WordPress offers better blogging, I'm using the SharePoint platform for a number of very convincing reasons:

• My organization already has SharePoint technology, and as much as we're open about tools, getting a non-standard technology approved and implemented has proven to be difficult.
• SharePoint's search looks at content both in the wiki and the blog (and any other site resources). This is critical, and is the reason I've not formalized a blog yet — it couldn't be integrated with the Madcap Flare webhelp I was using. Having one search that finds all help content is paramount.
• SharePoint's wiki allows you to introduce columns (metadata) and sort by those columns. This can help keep a wiki organized and prevent it from degenerating into an "unmitigated disaster," as another conference attendee described her company's wiki.

Overall, usually applications either excel at blogs or wikis, but not both. You compromise with one or the other. I'm willing to compromise, and I plan to experiment with any SharePoint blog and wiki plugins I can harness to increase the functionality.

SharePoint interfaces can be radically modified, so I'll be exploring SharePoint Designer to see just how easy that is. However, one thing Stewart said has really stuck with me:

Content is what matters most.

The wiki doesn't have to look like a professional website to serve its purpose. As long as the content is accurate and relevant, users will benefit -- even if the interface is simple.

Did I have any other conference epiphanies? Not really, but I'll leave you with a small growing idea that I secretly enjoy even without hard evidence — bloggers are cool people. Darren Barefoot, a prominent blogger, delivered a keynote and participated on the Meet the Bloggers panel. Although I only spoke briefly with him, he seemed like a cool person, as did other bloggers I met at the conference (such as Anne Gentle, who organized an Unconference, and Sara O'Keefe, who was doing some impressive live blogging).

Dare I say that bloggers are more engaged, passionate, commonsensical people? Anyone who is engaged enough with a topic to write constantly about it usually ends up being a fun person to listen to. Their passion drives them.

----

airplane photo from ecstaticist