In my last post, I suggested a few reasons why technical writing is dying. And it is, at least as a career with a single focus on writing documentation for end users.
What’s happening, and what do we need to do?
What’s changing, and why?
I work in the software industry. Specifically, I’ve focused on enterprise software. Why? Because enterprise software companies hire technical writers to explain their complex, very expensive software to users at other companies who probably also produce complex, expensive things (possibly, but not necessarily, more software).
Since the internet bubble burst lo those many years ago, we’ve seen some large software companies stick around, although usually a little smaller they once were. And we’ve seen a few upstart companies turn into similarly large behemoths. Those companies still hire technical writers, although even then they tend to have different names, and often different roles. And they also hire people with funny new job titles like “content strategist.” Facebook has lots of them, in fact.
And then there are an uncountable number of small, nimble companies that will never hire large doc teams. Many of the hiring managers there don’t, and won’t, see the need for a technical writer. Or if they hire one…well, surely that’s enough, right?
After all, how much documentation do we really need, anyway? Says this hypothetical person with a budget and a product.
What do we need? A business case! When do we need it? 10 years ago!
Or maybe 20.
Here’s my point: Technical writers are terrible at ROI (return on investment) calculations. We’re just now seeing smart people put together webinars, articles, and training to teach tech writers about the ROI of what they can provide (structured content, for example). But when a CEO asks you, “What value do you bring to this company?” what do you answer?
“I write the user documentation.” Pfft. Whatever. Who reads docs?
What we do, though, is reduce the burden on the customer support team. The user documentation is passive support. The person answering the email/phone/chat is active support. And that support person can answer the question and tell the customer to RTFM for more information, as long as we have written the…*ahem*…Fine Manual.
But what’s the ROI on that? How much time have we saved the support person? What are the metrics for the number of tickets they can answer when documentation exists, compared to when it doesn’t?
I’ve tried to calculate these numbers (at a previous job), but there were so many variables that I couldn’t come up with more than, “We’re pretty sure that users are asking more complex questions.”
That’s because support tickets increased as I wrote more documentation. But we were also seeing a large growth in the user base, and an increase in the number of products we offered.
The business world runs on data, and we’ve been terrible about collecting and publicizing this sort of data. Documentation is an item to check off of a “required things” list because…well, because it always has been. And how else will customers learn to use complex products?
But other options exist
But what about videos? Or training? After all, companies can charge for training. That’s a measurable source of revenue, not a fixed cost to pay for a tech writer and their expensive tools.
But that’s another use for the content we create. The doc team can help create training materials, including reference material (for handouts), content for the courses, and videos.
Because I’m in charge of customer support and product documentation at my company, I’ve joined in training sessions to give a short presentation to show the customers where they can turn to for help after the training class. Customers have told me that it’s reassuring to know that there is more help available. For any product, the answer to the question “Where do I go to get more help?” is not always obvious.
We need to start educating internally
Demonstrate the business value that you bring. Prove it. Find ways to show how things were before, and how they are improving now that you’re on the job.
Learn to adapt and find ways to bring your skills to new roles: Training, marketing, and customer support can all use your expertise, just to name three off the top of my head.
As I argued before, these are strategic tasks. While large companies with large documentation teams should have directors and managers focused on this (“should”), technical communicators at small companies spend most of our time locked into tactical tasks. And while yes, there are plenty of those tasks to our days, we need to spent time plotting the longer-term course that will define what our roles are to become.
Start by figuring out what you do, why that’s valuable, and what else you can do that will be even more valuable to your business. Turn those into metrics.
Content reuse gives you metrics. Time saved by reusing content gives you metrics. Page views are good, but often incomplete (just as an example, some topics don’t get a lot of views but are vital to the small number of readers who need that information).
So what am I doing about it?
Because I’ve found that those new responsibilities are also more challenging and fulfilling to me. Even though I’m about 1/3 “technical writer” at this point (if we just count the writing part), I’m learning new skills as a technical communicator. So I’m a technical writer, a content engineer, a customer support agent, a moderately skilled information architect, a bit of a content strategist, a bit of a web designer, a bit of a technical trainer…
And that’s just me. I’m sure I’m preaching to the choir, and you have the same skills (and I left off UI and UX, too).
And that’s not all!
This has been a bit of a rant, but based on the comments on the first part of this, I think I’m stumbling around something that concerns a lot of us in this field. And those comments have given me even more to think about.
I’m also at the Write the Docs conference today (May 6). I’ve talked to a few people who are traditional technical writers, but I’ve talked to more who spend their time doing tech writing, customer support, training, content marketing, and/or product management.
Which leads me to wonder whether technical writing a profession in (painful) transition, or a transitional career? Probably some of both.
And the other thing that’s been repeated, at the conference and in the comments to the previous post, is that we need to treat documentation like code. Which means, at the very least, checked in and tracked like code. But the other clear message is “Get your damn docs properly structured already!”