The diversification, not death, of technical writing

It’s been a month of organizational changes at work. Actually, just a particularly chaotic month, after about 5-6 months of changes. Which is stressful in general, and I’m finding it also saps my will to blog, and leaves me with few new things to blog about. The “document the product” part of my job has taken a distant third place to customer support and establishing a training program.

It also means that I have to make decisions about what I want to do. And, again, stop being a damn hero and trying to do everything every day. I want to be a “working manager”: Leading a team, but also doing a bit of day-to-day work (content development, ideally, but that could also include customer support). And although it’s different from when I started as a tech writer, it seems like the working manager is now the norm.

Writing and managing

Getting two for one is always a good deal, even though management tasks always take more time than anyone anticipates. But because doc teams are much smaller than they used to be, there’s often less of that to do on a daily basis.

Of course that depends on the skills of the people you’re managing. It’s worked for me in two out of three management roles. I’m not sure that 66% is an enviable success rate, but the difference was whether I had any say in who was hired. But it’s certainly possible for smaller teams in smaller companies.

And a quick, unscientific look at job postings on Linkedin suggests that companies are looking for manager/writers.

All-in-one writers

A company named TarrenPoint followed me on twitter recently. I haven’t worked with them, but I took a look at their blog and one line in particular leapt out at me:

Specialist or generalist: In the past, jobs or positions were narrow in scope and tied to a particular task or objective. With the changing landscape of multimedia, mobile, context-driven content, those that are associated with technical documentation must expand their horizons, learn new skills, and provide value in new areas or run the risk of being left behind. Specialization is giving way to generalization.

This is a good summary of my argument that traditional tech writing is dead. Knowing how to use one tool, or how to output to one format, just isn’t enough anymore, and executives demand that we show how we bring value to the company.

But “dead” is the wrong word

I was imprecise, and I realized this while conversing with people in the comments. But an article about a completely unrelated topic does a great job of explaining this:

And so what happened to being dead? Well, the point is that people will always tell you something is dead, when actually things are simply diversifying, or splitting apart, or hybridising or mutating.

So technical writing isn’t dead (or else recruiters wouldn’t be calling me), but it’s definitely diversifying and mutating. DocBook is old and busted, DITA is moving more slowly than I’d like, and we’re just starting to see the open source movement making a dent in the tech writing field. I’ve seen some very interesting examples of people using Github as a publishing tool. Tom Johnson is working on some DITA implementations that also look really interesting, and hopefully something that I can shamelessly copy for my own work.

But it’s definitely a changing world. I still produce PDFs, but as short handouts for training courses or one-off deliverables of customized content to a single customer. Most of my content is conceptual, usage, and admin info in an online knowledge base, and by next year I’ll need to deliver content for all of that as well as for in-app tutorials and an API reference.

I can’t specialize in one type of documentation, or even one tool. I’ll probably need a handful of tools: at least one authoring tool, a publishing tool, a video creation tool, and audio recording tool, a screenshot editor…

Not to mention the customer support application I manage, a project planning tool, enough knowledge of git commands to keep the test code up to date, and the task tracking tool that engineering uses. Each of which I use at least once a week.

As the writer at TarranPoint said, “In the past, jobs or positions were narrow in scope and tied to a particular task or objective.”

That world is gone, and has been for a while. Time to hurry up and mutate to fit in this new, highly diversified world.

Advertisements

2 thoughts on “The diversification, not death, of technical writing

  1. Maybe my experience is atypical, but in my dozen plus years of writing docs for software, I’ve yet to come across a technical writing “specialist,” at least in the narrow sense that you use the term here, Neal — someone who knows how to use just one tool, or produce just one kind of output. On my current team, which is mostly responsible for what still seems to be unfortunately called “end-user” documentation, we all use multiple writing tools/editors, version control, project planning tools, code editors/IDEs (not just for the API doc writers), video recording software, screen capture and screenshot editing software, and more. I’ll spare you the list of all the different types of content we produce, but you get the idea. The same has been true at other companies where I’ve worked.
    That said, I certainly have read the latest bouts of hand-wringing over the fate of technical writers that you address here, and I have to wonder whether some of this phenomenon isn’t based on a straw man.
    At the same time, I look at the CMS that my current company has implemented — and the way it’s been implemented — and I definitely see a system that’s designed to produce “writers” who can only follow one set of rules, without much thought for the content that those rules are supposed to help produce.
    And … I guess to come full circle back to your argument … I also see a move at my company toward emphasizing content quality over slavish adherence to rules. But it’s a struggle. This isn’t quite what you discuss in your post, but I think it’s related.
    Maybe the changes we both see are related more to the work, and less to the workers themselves? Just a thought, with thanks as always for the thought-provoking post.

    1. Thanks for commenting! You might be right that I’m building a strawman. I stepped away from Framemaker 9 years ago, and even then I was also working with Robohelp and straight HTML. But I’ve also talked to tech writers who wanted to keep using the one tool that they have grown to love (or at least tolerate), and who had little interest in learning to use yet another tool (and all of its quirks). And if we all need to learn to use a lot of different tools, how proficient can we be with any one of them? Or what will be considered “good enough”?

      I also hate any system that exists to control the writers’ output that thoroughly. I like to have some flexibility, and I want to trust my team to not abuse that. Mainly because I don’t think it’s possible to come up with a perfect answer the first time, and setting those rules at the beginning limits the ability to adjust and find better solutions.

Comments are closed.