STC 2008: Day Four, June 4

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).

STC 2008: Day Three, June 3

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.

STC 2008: Day Two, June 2

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.

STC 2008: Day One, June 1

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.

What Can We Learn About Motivation from a Tornado?

I spent the last four days scheduling volunteers for an organization supporting the disaster relief after last week’s tornado in Colorado. When I came home each evening, I would find another installment of a lively discussion about motivation on the mailing list for the Society for Technical Communication’s (STC) Management Special Interest Group (SIG). It wasn’t until the fourth day that I realized that my “day job” as a volunteer was also a lesson on motivation.

So, what did I learn?

• For the right cause, people will do pretty much anything.

  For example, I found out at 6pm on Friday night that I needed to assemble a crew of 10 to unload a supply truck at 5am the next morning. Hard work at an insane hour, but I got commitments from everyone I needed within 3 hours. And, for every activity I needed to schedule, we had more volunteers than we needed. This response didn’t happen because I have some magical skill as a motivator; it happened because the need was critical.

  Most business objectives are not as clearly “right” as feeding disaster victims, but if your objectives make sense, are clearly communicated, and can be seen as productive for the organization, you’ve got a much better chance of having motivated people.

• A strong group helps keep people motivated.

  Nearly everyone who volunteered came as part of a group, and not just groups like Red Cross and Salvation Army that exist specifically for disaster relief. Churches and other community groups were a big part of the effort. While there were a few stalwart folks who volunteered independently, they were in the minority. The reason is pretty clear; if you’re a member of a strong group, you have a motive to serve the group as well as a motive to serve the group’s objectives. The two reinforce each other.

  Given today’s highly outsourced, geographically diverse projects, most of which operate in an environment where downsizing is the flavor of the decade, it’s difficult to build a strong team, but if you can pull it off, it becomes really difficult for team members to remain unmotivated. They either get with the program or leave.

All of that said, motivation is internal. You can identify clear objectives, communicate them vigorously, create a strong team, and build a supportive environment, but they have to drink the Kool Aid, you can’t do it for them.

I believe that most people will be motivated if you do these things, but some won’t; they may be in the wrong place, be going through problems outside of work, or simply be one of those folks who never gets motivated by anything. When that happens, you can coerce them and get some results, but almost always the best thing you can do is find them a better job fit or get them out of the environment.