Architecting value

A month ago, I got a new job title: Information Architect. I maintain my company’s content infrastructure, training and supporting a writing team that has, through mergers and acquisitions, tripled in size over the last 18 months. I also look to the future, defining strategic goals and figuring out how to achieve them.

In describing my new beat, I told the writing team that I have two priorities:

• Help the team do their jobs as effectively as possible — by listening to them, by training them in both tools and concepts, and by fixing problems
• Position our documentation products to provide value to the company and its customers

What does that look like in real life? Well, the first priority is pretty much what you’d expect. If I’m listening to the team, I know where they need training and guidance. And I try to be responsive when someone has a problem. (I also rely on a couple of colleagues who can also step in and troubleshoot when needed.)

The second priority, for me, is the crux of my job. But, paradoxically, it’s a lot harder to envision.

Survey says: DITA’s benefits and challenges

What are DITA‘s biggest benefits? Its greatest challenges?

The Content Wrangler is surveying DITA users, and last week Scott Abel — joined by DITA cognoscenti Rob Hanna,Mark Lewis, and Keith Schengili-Roberts — presented some preliminary results.

I’ve listed the rankings here, along with some thoughts of my own. Each numbered item is from Scott’s presentation; the commentary between the numbered items is mine.

(The survey is still accepting responses. If you haven’t yet weighed in, you can do so right now.)

What benefits does DITA provide?

This section was open to all respondents.

1, Consistency: content reuse/single-sourcing
Yes: when I think of single-sourcing, I think of consistency. But I also think about flexibility — of being able to publish the same content on the web, as integrated help, as PDF, and in other formats. For me that’s a big benefit, just as much as — and probably more than — consistency.

2. Usability: structure provides predictability

3. Translation: savings from reusing translation
The panelists remarked that they expected this one to score higher, and theorized that many of the survey respondents were content creators but were not the people actually responsible for translation. I think they’re probably right — and I’d also point out that a lot of organizations simply don’t translate their content. It would be interesting if the survey asked how many are currently translating DITA content.

4. Customization: segmentation, personalization
Nice to see this one crack the top 4. I think we (the community of DITA content producers) are just beginning to take advantage of features like metadata and keys. There’s so much more we can do to adapt content based on the audience’s geographic location, experience level, and so forth. (Key scopes and branch filtering in DITA 1.3 hold out even more promise.)

Rank the biggest challenges associated with using DITA

This section was open to respondents who said they use DITA.

1. Reuse: determining reuse strategy
Conref or keyref? What taxonomy to use, and where to put the metadata (in topics or in maps)? Who “owns” the library of reusable content? There doesn’t seem to be much consensus on best practices when it comes to developing a reuse strategy. Maybe, like the consultants always say, it depends — on what the writing team is
used to, on which groups are collaborating to produce content, and on what the corporate culture will support.

2. Usage: making DITA do what we want it to do

3. Training: equipping staff with skills needed
There’s a ton of training out there — in the basics of structured authoring, in DITA itself, and in the various tools. So I’m not sure what the problem is, unless it’s that companies don’t want to pay for training and want simply to hire people who already know everything (see #7 below). Even if you could hire fully-capable DITA writers off the street (and that’s a big if), they still need to be trained in how to use your local style, transforms, and so forth.

4. Technology: understanding software

5. Formatting: developing stylesheets and rules for content
This isn’t rocket science, but it is serious, hard work. It’s often not considered when companies plan a transition to DITA — which makes it even harder.

6. Governance: enforcing the rules
See number 5 above.

7. Staffing: finding experienced talent

8. Creation: understanding how to create DITA content

9. Measurement: what to measure, how to decide
Let’s be honest: rather than what to measure, don’t we really mean making the business case? We still struggle to quantify the cost savings and revenue enhancement associated with structured authoring and DITA. Translation savings, of course, are a big part of the story. But increased usability, customization, and brand consistency have value too. We just have a hard time quantifying their value.

10. Translation: issues associated with DITA content

So there you have it. What do you think? Do any of the rankings surprise you? Is anything missing from either list?

Do you agree with my take?

Thanks to Scott Abel for conducting the survey. Like so much of what he does, it’s of great value to the technical writing community. Thanks to Rob, Mark, and Keith for their contributions as well.

An agile STC?

How well does the Society for Technical Communication (STC) provide value for its members? For others who are studying or working in tech comm?

We had a lively conversation a few weeks ago on this blog. I’d like to move that conversation forward.

Today’s news stream brings an article by an Australian technical writer, Swapnil Ogale, titled The ASTC is failing us. In it, Swapnil shares an idea that might breathe new life into STC.

First, by way of background: ASTC is the Australian Society for Technical Communication. Despite the name it’s not part of STC. Like STC, however, it’s a membership organization that seeks to advance the profession through published articles, events and activities, and community building.

In his article, Swapnil airs some complaints about ASTC that might sound familiar to STC members:

• Not enough effort to attract and retain members
• Not enough communication from the society to the members
• Not enough workshops and events, especially for people who aren’t located near major cities

Hey, if a dog can be agile so can we.

Then he makes a suggestion: Instead of relying on the traditional committee structure — a structure he calls “outdated and archaic” — the organization should adopt an agile methodology like software development teams use.

Agile, or “just-in-time development,” is a set of processes designed to make software teams more flexible and able to respond quickly to the needs of their customers. Agile teams produce frequent, small software updates rather than big roll-outs.

Here’s how agile could help STC.

Why is it so important that STC survive?

Mark Baker, commenting on my post about STC and its future, asked me a question:

Larry, I have to ask why you think it is so important that the STC survive per se? Is it because it performs some vital function that will cease to exist if STC folds? Or is it sentimental attachment based on time sunk into it, long time association, and long standing friendships?

I’ve pondered that question for a while.

Yes, STC has been good to me. But that’s not the only reason I want it to succeed.

Of course part of the answer, for me, is sentiment. My experience with STC has been extremely rewarding. I don’t keep up with friends from high school or college, but some of my STC friendships are going strong after 20 or 30 years. In STC, I feel an incredibly strong sense of belonging. This is my tribe.

I understand, however, that most people don’t share that sentiment. And I know it’s not a reason for wanting STC to survive per se.

So is there, in Mark’s words, a vital function that STC provides? I think there are several — or at least there can be.

The role of a society

What’s the role of a professional society in a field where credentialling — that is, licensing — isn’t a legal prerequisite to participation?

Start with networking and information exchange. Several of the more recently formed communities, like LavaCon and Write the Docs, provide both of those. It’s because of that, I think, that people are questioning whether STC has become outmoded.

Yet a professional society ought to perform other functions as well:

STC: Growing in Numbers and Relevance

In the runup to the 63rd annual STC Summit, now underway, I posted some thoughts on how the event has shrunk since the late 1990s. The post drew a lot of insightful comments about the Summit and about conferences in general. (I encourage you to read them.)

Two readers — perhaps picking up on my observation that STC membership has declined along with Summit attendance — suggested that STC itself, not just the conference, is struggling to remain relevant.

That’s the issue I’d like to focus on today: How can STC grow in both numbers and relevance?

First I’ll excerpt their comments. Then I’ll add my thoughts. Then I want to hear what you think.

Rethinking RTFM

I still appreciate the humor behind RTFM. But it’s not the way I actually feel.

RTFM. Read the [bad word] manual.

As in, “I don’t know how to do this.”
“Did you look at the instructions?”
“No.”
“Well [rolling eyes], why don’t you read the….”

RTFM has been a byword among technical communicators for as long as I’ve been hanging out with them. (That’s more than 35 years, by the way.)

RTFM reinforces the idea that documentation is important, an essential part of any product.

But RTFM also betrays exasperation and insecurity. We — as a profession — might sound smug when we say it. But inside we’re thinking, Why don’t people like to read instructions? We see it as a rejection of what we do, and ultimately of us ourselves. It stings.

It’s time to rethink RTFM.