Archive for June, 2008

h1

STC 2008: Day Four, June 4

June 10, 2008

After a few days of travel and other diversions, I’m back home and settling into the old routine. The last day of STC 2008 flew by pretty quickly. I saw two talks, plus the closing keynote. The first talk was Results of a Survey on the Usage and Impacts of Single-Sourcing and Content Management, by David Dayton of Towson University. Dayton’s objective was to see to what extent people actually realize the benefits of Content Management and Single-Sourcing (CMSS).

Read the rest of this entry ?

h1

STC 2008: Day Three, June 3

June 3, 2008

Today for me was mostly split between two types of events, talks about Agile development techniques, in particular Scrum, and two “progressions.” To take the latter first, progressions were a new concept to me. A progression is held in a room with several large tables, each of which has a moderator with a particular topic. Over the course of a one to two hour progression, participants cycle through 1-4 tables, and have a short conversation with the moderator and other participants. It’s a bit like the conference version of “speed dating,” without the fear of rejection.

Read the rest of this entry ?

h1

STC 2008: Day Two, June 2

June 2, 2008

Three out of four ain’t bad, and the fourth wasn’t awful, just not excellent. Rather that drag you through all four sessions, I’ll summarize the highlights from the three I got the most from.

Read the rest of this entry ?

h1

STC 2008: Day One, June 1

June 1, 2008

I’m at the STC 2008 conference this week and will be posting my comments here each day. This is my first STC conference, and so far I’m impressed. Registration was smooth, in part because our badges were mailed in advance. We just needed to pick up the obligatory tote bag, badge holder, program, and marketing material from the sponsors.

I was pleased and surprised that there was a session right off the bat; a panel titled, Is What You’re Doing Today Enough to Remain Competitive Tomorrow? The panelists were Jack Molisani, Andrea Ames, Bogo Vatovec, and Barbara Giammona (I think that is her name, she was a replacement for Bill See, who was not there), with moderator Paula Berger.

The panel turned out to be a lively crowd that enjoyed mixing it up. They started off with a few random thoughts before getting up a head of steam. Among the random comments, I particularly liked Andrea’s four word slogan, Think More, Write Less. Not only would that make a great book title, it also captures the essence of the panel’s discussion.

The issue the group settled in on was how to avoid being “commoditized.” A commodity product is one where the only real differentiation is in the pricing. If you are “just” a technical writer, you run the risk of becoming a commodity that can be easily replaced with a lower price alternative. Andrea, with the concurrence of the rest of the panel, suggested that technical communicators should be asking why instead of what, and should be thinking in terms of solving business problems, rather than documenting products.

She then asked how many people were involved with deciding what their deliverables would be. She was surprised (and I was shocked) at how few people had a hand in deliverable design or even input into the process. As a quick digression, I consider deliverable design to be a core technical communication task, and I’m surprised at how many folks indicated they are in a situation where their deliverables are dictated to them.

The moderator then asked each participant to recommend courses/training that could help communicators avoid becoming a “commodity.” Here are their responses:

Molisani: He recommends Toastmasters, and suggested improving domain knowledge.

Giammona: She recommended project management training. She told a story about Morgan Stanley, her previous employer. Within the centralized doc group, there was a group of people who expanded their communications skills and found jobs in other areas, and another group of people who stayed as pure technical writers. As Morgan went through a series of re-organizations and downsizing, the people in the first group kept their jobs, but those in the second didn’t.

Vatovec: He suggested learning Project Management skills, Information Architecture, and Object Oriented methodologies; anything but pure technical writing.

Andrea: She suggested learning about DITA, but focusing on the methodology behind it, rather than just the markup. She also suggested honing negotiating and influencing skills.

At this point, someone commented that the consensus recommendation seemed to be to get out of technical writing.

The best response to this came, I think, from Andrea, who said that writers shouldn’t change their careers, but rather should change the way they think about their careers. Jack added that you should think along the lines for being Technical Writer/something else (information architect, interface designer, etc) rather than simply “Technical Writer.”

Beyond the obvious point that broader skills will make you more employable, it’s also the case, fair or unfair, that “Technical Writer” as a job category has less value in the marketplace than other skills.

They wrapped things up with two discussions; first about off-shoring. Beyond the usual questions of reducing costs, Bogo made the important point that some off-shoring is necessary because the market for products has expanded well beyond the U.S. and companies need to go where market knowledge is, regardless of the location.

The final point that I found interesting was a point Bogo made about task oriented writing. He decried documentation that described how to do isolated, and often trivial, tasks without context. The interface should make it obvious how to do simple tasks, like printing, without additional documentation. Where the technical communicator can add value is through context and a deeper understanding of how to solve problems.

Overall, a wide ranging, sometimes disjoint, but thought-provoking panel that I think got things off to a good start.