New to tech comm? Expect the unexpected
When I started at Scriptorium a year ago, I knew almost nothing about tech comm. I knew what technical content was, having used it many times, but I’d never really thought about how it was produced. Looking back on my first year in tech comm, these were the biggest surprises about the industry.
Disconnect between producers and users of technical content
I was shocked to learn how uncommon it is for technical publications teams to get direct user feedback. How could they create effective documentation if they didn’t know how people used it?
But I learned that at many companies, other departments such as customer support or marketing interact directly with end users—and may or may not pass on those users’ comments to the tech writers. One client told us that their marketing team had been meaning to conduct a customer survey about the documentation but “had never gotten around to it.” Maybe this disconnect helps explain why I knew so little about tech comm before I came to Scriptorium.
Resistance to change
This one was understandable. People feel safe and confident doing what they know, and as long as it keeps working, why change it? The surprise was finding out how often tech pubs teams kept using familiar tools and processes when they didn’t work anymore.
In discussions with clients about content strategy, I heard tech writers admit that their current workflows added stress, made it difficult to meet deadlines, and were unsustainable. But they’d also say things like, “Will we get to keep Tool X?” or “We’re scared to learn Tool Y—it looks hard.” As a newbie, I could sympathize with their fear of a learning curve. But I was still amazed that some tech writers would rather keep an inefficient workflow than face that curve—especially if it would give them more time to actually write content.
Wasted resources
In the digital age when everyone is talking about the latest and greatest technology, I was astounded to see so many tech pubs departments using outdated tools or doing manual work that could be automated with a computer. Whether it was copying and pasting content, maintaining multiple copies of reused graphics and updating them separately, fixing broken cross-references, or managing files, I saw tech writers having to do too many things by hand.
Implementing a new workflow may be expensive, but so are the hours of work performed by the writers, and those hours are especially costly when they aren’t used productively. Companies would benefit from making the most of what technology can offer, and saving the time—not to mention the tech writers’ talents—they are currently wasting.
Using the “Band-Aid approach,” again and again
I know it’s hard to think past the implementation cost and short-term productivity loss that accompanies a major change in publishing processes. So I wasn’t too surprised to see companies making quick fixes to their tech comm problems instead—often with a shiny new tool that’s supposed to solve everything. After four years of journalism school, I knew these kinds of fixes didn’t just happen in tech comm, but in any deadline-driven industry.
The real surprise was seeing companies using the “Band-Aid approach” or picking tools for their tech writers without a strategy over and over. When I learn about clients’ tech comm publishing histories, and they go something like, “First we had Tool X, then switched to Tool Y, then changed managers and got Tool Z,” it’s clear that a) content strategy is not as high a priority as it should be, and b) these companies are not learning from their mistakes. This is not only costly to them, but unfair to their tech writers.
Need for convergence between tech comm and marcomm
Working in tech comm with a background in journalism and multimedia design, I immediately discovered how much tech comm differs from marcomm. For example, I saw that there wasn’t as much room for design in tech comm—trying to have too much control over formatting can interfere with efficiency in an automated workflow. I was worried that this would make it difficult to use my background in my new career. So I was pleasantly surprised to see Scriptorium and others in the industry talking about a growing need for tech comm and marcomm to converge.
At the very least, these two departments should collaborate with each other instead of working in separate silos. This would help solve the problem I mentioned earlier of tech writers being disconnected from users. It could also encourage collaboration amongst all of a company’s departments for a more unified (and ultimately successful) business.
As I move forward with my career and keep building knowledge inside the tech comm industry, I hope to maintain some of my outsider’s perspective, or at least remember what it was like to be new. Taking a step back to think about how a person with no knowledge of tech comm might view our industry and our issues can help us be more logical in our approach to content strategy. It can also help tech pubs teams communicate more effectively with others in their companies and with users of their content.
What are some surprising things you’ve encountered in tech comm? And how can we work toward resolving the issues addressed here?
Ellis Pratt
I agree with you, and talked on this subject at the STC conference last week (see http://www.sdicorp.com/Resources/Blog/tabid/77/articleType/ArticleView/articleId/158312/When-everything-just-works.aspx#Comment962).
Gretyl Kinsey
Thank you for linking to the info about your presentation, Ellis. I hadn’t thought about how this recent development of having some products that “just work” and some that don’t could contribute to some of the issues in my post. It’s an excellent point and interesting to think about.
This split into two camps of products does point to a need for more collaboration between tech comm and marcomm, and could worsen the disconnect with users if those of us in tech comm aren’t careful.
Larry Kunz
Gretyl, your outsider’s perspective is dead on. You’ve spotlighted some very important issues. In fact, the only one I can add is the refusal of many technical communicators to think of their work in business terms. The value of tech comm isn’t intrinsic; it must be measured in terms of either revenue enhancement or cost avoidance. A lot of practitioners still don’t get that.
Overcoming resistance to change is probably the key to resolving all of these issues. The world has changed, and it continues to change. Doing things as we’ve always done them is simply illogical.
Gretyl Kinsey
Larry, thank you for your insight. I agree with your point about the refusal to think of tech comm in business terms. That’s probably a contributing factor to both wasted resources and the “Band-Aid” approach.
It’s also interesting to think about how resistance to change might be at the root of the other issues, and how overcoming it would help us keep tech comm moving in the right direction as change keeps happening.
Ellis Pratt
When we carried out surveys of the technical communication sector in the UK last year, we found that Technical Communicators said they were open to change.
They complained that the resistance came from outside their department – senior management who had a view of what documentation should look like (aka “documentation by the inch”) and departments that felt it would impact on them adversely (Support and training revenues). There was also the lack of time and budget issue.
They may of just been saying this, but I get the sense there needs to be a selling job to those with the purse strings.
The correct link in my first comment is http://www.sdicorp.com/Resources/Blog/tabid/77/articleType/ArticleView/articleId/158312/When-everything-just-works.aspx
Harry Van Dort
Gretyl – As someone who is brand-new to tech comm, I appreciated seeing this reality check. I was also encouraged to see the insight you’ve developed in just a year after knowing very little about the field…hopefully I’ll be able to contribute similarly to the conversation a year from now.
Gretyl Kinsey
Ellis – I have seen resistance to change happen both inside and outside tech comm departments (for example, product developers or engineers don’t want their development cycles disrupted by changes in tech comm such as installing a CMS, or SMEs don’t want to change the way they’ve always contributed content to the tech writers). I think this speaks for the need to educate other departments about what tech comm does, and for the selling job you mentioned.
Harry – Nice to see another newcomer, and welcome to the world of tech comm! This field is full of great opportunities to learn on a daily basis, so I’m sure you’ll have plenty to contribute to the conversation in no time.