2012 tekom thoughts
Some thoughts on technical communication, content strategy, and the state of the industry at tekom/tcworld 2012.
I had lots of fascinating conversations with people from all over the world during the tekom/tcworld event. Here are some of the thoughts that are percolating as a result:
- Compromising quality in order to get automation and therefore lower costs is more acceptable in some cultures (U.S.) than in others (Japan).
- Cultural differences play a huge part in determining how software is evaluated, selected, and implemented. This partially explains why the leading content management systems in Germany are entirely different from the leading CMSs in North America. This becomes highly problematic for multinationals that want to implement a single system across the enterprise.
- Much of the tech comm effort in Germany is driven by regulatory issues. Hardly any of the tech comm effort in the U.S. is affected by regulatory issues.
- Europeans don’t really understand how the Americans get away with producing content that doesn’t conform to any particular ISO or industry norms. Americans don’t really understand why Europeans are so obsessed with conforming to ISO or industry norms.
- DITA is big in North America and nearly irrelevant in Germany.
Others have already done some excellent write-ups of my sessions, so instead of attempting another recap, I’ll just direct you to them:
- Turning tech comm into a business asset: Kai’s Tech Writing blog (Kai Weber) and Open Technical Communication (Axel Regnet)
- Strategic Technical Communicator panel: Kai again
I used a spreadsheet in my business case presentation, which is available as a public Google Doc.
Many thanks to Scott Abel, who somehow managed to corral Rahel Ann Bailie, Charles Cooper, Joe Gollner, Ann Rockley, Val Swisher, Noz Urbina, and Kyle Wiens into a content strategy track.
Kai
Thanks, Sarah, for sharing your thoughts. Since I work out of Germany and in an international environment, it’s always very valuable for me to hear expert opinions about how tech comm shapes up internationally, with all its differences and common themes.
From my own limited experience, I can confirm that there seem to be different ideas of how much or how little quality is acceptable in different markets.
Thomas Tregner
Those are interesting bullets. With regard to regulatory issues (bullet 3) and ISO (bullet 4), that seems to be true as a generalization. When you dive into many specific industries in the United States such as nuclear power and defense contracting, regulatory issues and standards conformance are central to documentation efforts. What I find interesting about technical communication as a professional community in the U.S. is that from the outside looking in, technical communication appears to be mostly focused on software documentation. The STC is a good example. Technical documentation responsibilities in other industries in the U.S. often fall under the umbrella of logistics, quality, and other departments. But rather than interact with the greater technical communication community dominated by software documentation, writers in those departments tend to interact with members of the logistics and quality assurance communities.
Karen Mardahl
Ah, this explains why I get so grumpy with generalizations. Or should I say generalisations? Now, I can just ask people to stop and read this before rolling out another “everyone in techcomm does/thinks …” or “the only way is …” đŸ™‚
Ray Gallon
Hi Sarah,
Interestingly, in France there is rather less concern about adherence to ISO standards than seems to be the case in Germany. It’s hard to make generalisations even about Europe, though in principle, there should be Europe-wide standards.
One area where technical communicators are heavily involved with machinery and mechanical instructions is medical equipment. Two other major areas (at least in France) are aerospace and rail transport. All the TGV documentation, for example, is done by technical communicators. You can bet in these regulated industries, they follow standards. I know for a fact that they do in the U.S., too.
On the subject of coherence, even within ISO there are divergences. There is a large software documentation working group, in which STC participates quite actively.
There is also another ISO standard for “general technical instructions” or something similar, in which TEKOM is heavily involved. One of the ways the two organisations have agreed to collaborate is for each to get a bit more involved in the other set of standards.
To date, as far as I know, no one has checked to see if the two sets of standards are coherent with each other.
And oh yes, there are some new standards about to be drawn up – one covering content management life cycles, a revision to web content standards to include technical information, and a group is working to make DITA an ISO standard. STC is involved in one way or another in all of these.
Thomas Böttiger
Regarding the obsessions of Germans with rules and regulations: This may partly be due to the cultural heritage, but also due to the fact that most techcomm writers have at least a basic technical background (e.g. engineering), so they tend to look at documentation from a technical view, which may not be identical to the addressed customer’s view.
Sarah O'Keefe
Interesting thought. I personally think it’s related to the business environment — when tech comm people are held accountable for producing information that conforms to specific industry norms, they tend to be interested in meeting those industry norms. This does happen in the U.S. as Ray pointed out, but it seems to be more widespread in Germany for some reason.
Corry Clybouw
You bullet point on cultural differences in selecting software struck me. Could you elaborate a bit more on what the differences are?
Sarah O'Keefe
Hi Corry,
I want to be careful about blanket assumptions, but the decision flow seems to be different. Generally, in the U.S., you see this:
choose a content model (DITA or not? mostly DITA)
* evaluate CMSs that support the specified content model
** assess workflow options
In Germany, it’s more like this:
choose a workflow
* evaluate CMSs that support the specified workflow
** evaluate content models (mostly not DITA b/c chosen CMS doesn’t support it)