The death of technical writing, part 2

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!”

Advertisements

28 thoughts on “The death of technical writing, part 2

  1. Good points, Neal — although your brush is a bit broad at times. For example, we’re not all terrible at ROI calculations. Still, your point is well taken: historically, as a profession, we’ve shied away from having a business-oriented mindset, to our detriment.

    We’re not technical writers any more. But we’re not dead either. We’re evolving into content experts: professionals who understand that content has business value and who know how to produce and manage content in such a way that its value is maximized As you said, we need to educate our employers about the value we bring, and in many cases we also need to educate each other.

    1. Yes, it is indeed a very broad brush! We’ve seen these arguments from techcomm experts for a while now; I’m a bit afraid that I’m just piling on at this point.

      We’re evolving into content experts: professionals who understand that content has business value and who know how to produce and manage content in such a way that its value is maximized

      Exactly. That’s basically what my second post says, but I said it in a much less concise way!

  2. Yes, technical communication is diverse, and I’m with you entirely on the idea that people who are or who have been called “technical writers” need to move into more areas of technical communication to stay relevant. (See my blog post on The Best Job I Ever Had, and the diversity of technical communication it involved: http://everypageispageone.com/2013/12/17/the-best-job-i-ever-had/).

    But in terms of selling the value proposition, I think we have to do more than make cost reduction arguments. It depends on the industry, but in growth companies market expansion and revenue enhancement often speak far louder than cost containment.

    We need to start making the market-expansion/revenue enhancement argument. This involves a bitter pill that many tech writers don’t want to swallow: technical communication is marketing. But anything that impacts the customer’s relationship with the company and its products is marketing.

    Regarding technical content as marketing does not mean making it shallow: technical communication is the deep end of marketing. But successful tech comm does something far more important that keeping people from calling support. It makes them buy products, it makes them buy upgrades, and it makes them recommend the product to their friends and colleagues.

    The true role of technical communication is to maintain a harmonious and profitable long term relationship with the customer. That is a market growing, revenue enhancing role of the first importance. The problem today is that tech comm often does not know how to play that role and play it well, and often resists playing it at all.

    1. technical communication is the deep end of marketing.

      Brilliant. That needs to go on t-shirts and bumper stickers. The fact that techcomm is marketing was a revelation that hit me a few years ago (probably through your blog, in fact), but I’m now a convert. Now we just need to get the cool tracking tools that the marketing departments have.

      The true role of technical communication is to maintain a harmonious and profitable long term relationship with the customer.

      And this is the definition of the “new” field Customer Success. So it makes sense that I’m now reporting to the VP of Customer Success at my company.

      1. Great, interesting blogs, Neal. I, like you, think that’s a cool slogan (or slodgen, as my daughter used to call it, before she grew up). Mark – can I use “technical communication is the deep end of marketing”? Love it!

        On this topic, I strongly recommend Roger Hart’s presentation which I attended at TCUK 2014, where he shows how Google’s ZMOT (“Zero Moment of Truth”) can be the technical communicator’s best friend… http://www.slideshare.net/RogerHart/collateral-damage-do-marketing-and-tech-comms-have-to-fight-when-users-get-informed

      2. Thanks for that link, Emma. That’s a great presentation. I agree that the technical communication department should report to a customer-facing org. But it requires a chief marketing officer who really understands the roles of techcomm vs marcomm. I guess that’s another place where we need to start educating the executive team.

  3. “We need to treat documentation like code. ” I like that a lot; that should also go on a t-shirt! And just like software code is less proprietary than it used to be and is now often open source, so is technical documentation. It’s more and more out there, searchable on the web, maintainable by users, updated regularly, available in all sorts of formats. This is why we need structured documentation that is very mobile and flexible.

    I’m really enjoying this thread, Neal, not only your thought-provoking posts but also the comments. We’re obviously a very involved and committed community. We’re clearly not dead yet 🙂

    1. “We’re clearly not dead yet.” Point taken! I wrote with the assumption that we are a smart, involved, opinionated community, and we’re fully capable of adapting to changing requirements.

      I really like that idea of docs created and maintained like open source code. It sounds like we need to have a structured, easy to use wiki. Maybe it’s time to create DITAwiki.

  4. I’m sorry to be a stick in the mud, but I really think this is all old news. I have a neighbor who worked in the oil industry years ago. I asked him what he though of *his* technical writers… It wasn’t good. And he didn’t add anything new to the list of complaints — nor did he raise anything that has become obsolete.

    The tipping point finally came with PDF and the death of paper. Agile was a final salvo. For eons (in technology time) tech writers have been the keepers of publication schedules. They were the only ones who could manage the localization and printing issues, largely because nobody else wanted to do it. Thus a pubs dept had a reason to exist… To move large amounts of MATTER from one warehouse to another. This gave the pubs dept. veto power over product changes, and a number of other powers that are now wholly obsolete.

    Nothing is more pathetic than a “pubs” dept. that clings to this model. Yes, it still exists… I know one or more people who recently escaped from such a department, and it was a nightmare for the years he-or-she (or they) had to suffer through it… Trying to provide VALUE in that environment is not easy. And nothing is more damning to the trade than the existence of such an old-school department.

    Sarah O’Keefe had it right in a comment to the previous post… Look at the business case and go from there. In other words, ask the question, “What VALUE can I add to this team?” That should be your driver.

    Different industries have different value opportunities. Different people have different capabilities. But I’ve been saying this for at least 5 years now, and I’ll say it again…

    No matter WHAT the project, in the developed world ANY project is primarily an exercise in information management. Building a bridge, farming chickens, or building software… It doesn’t matter — the majority of the work is with information. We are information professionals. The spectrum of information work is broad. There’s lots of room to add value. I don’t know what else to say about that.

    For myself, I’ve gone the technical route… Implementing help and embedded doc managers as well as providing the content. But there are many other areas to explore:
    * Product management
    * Project management
    * Testing
    * Training
    * etc. (Others have filled in this list)

    Each team and each project is different. LOOK at your situation and find where you can add value. If you have nothing to add, look for another team or project.

    1. Good point about agile. The content creators have two choices: get technical or get *fast*. Do execs want to hear why the docs are one (or more) sprints behind the product? Customers need that info NOW! In fact, your internal and external customers want it before the release (at least mine do). By the time our pretty little docs are ready they’ve already figured out which buttons to push and written their own cheat sheets. Marketing needs info now. Training needs info now. Their schedules don’t let them wait for us to create perfect documentation.

      Alternatively, if we can offer API docs and code samples, then we have something of value.

      1. I learned a few things by working in Agile teams.

        First, tech writes have more to contribute than pages. In a scrum where you’re supposed to be 100% devoted to a sprint (or however that terminology shakes out), you need to be PRESENT all the time. But you won’t start producing actual pages until late in the sprint. So what do you do? In the final analysis, you contribute to solving the larger information management problem… Pick up tasks and go with them.

        Second, you can improve your process to make it more “Agile”. You have to OWN your process first. That’s a real problem with some pubs departments, I might add. An old-school manager will never let go, because it looks like a loss of power. In fact, it’s quite empowering to own your processes and tweak them to suit the given sprint. That’s the more, better, faster thing. For example, in my current gig I have set things up so I commit DITA as part of the product source. My changes get into the nightly builds with no effort on my part… They’re just there. Nobody did this for me, and nobody gave me “permission” — I had to just do it. Note… This is actually an exercise in information management.

        Another area… Define new deliverables. For example, why load pages with content that can fit into the GUI? So… I started out owning the tooltips, and that morphed into implementing formatted tooltips and a tooltip manager. Then we said, why not put content on the GUI surface? Ok, that turned into implementing a help-text manager and owning that content as well. Our customers asked for “overlays” — a developer implemented that, but I own the content. More information management…

        Also, you can provide liaison with the outside world. How does the team keep in step with marketing or industry terminology, for example? What are the common customer problems with your product? Yet another exercise in information management.

        And yes, API docs are a world of information management all their own.

  5. After 20 years in the technical writing field, I am seriously considering leaving it. I’m quite well positioned for the future, quite tech savvy, and I adhere to all the best practices for maintaining viability in today’s environment. So I would be leaving it by choice.

    I have one primary requirement for my next profession: its value must be self-evident. The ROI must be self-evident. In fact, the next time someone asks my value proposition as a technical writer, I will likely say, “If you can’t see it already, I’m done” and walk out the door. And find something else to do for a living. Probably programming, possibly QA, maybe even training. Something in which the ROI is simple to see. Enough of this constant justification.

  6. In 2002, Michael Hughes published his article “Moving from Information Transfer to Knowledge Creation: A New Value Proposition for Technical Communicators”. Somewhat foreshadowing the current interest in content strategy, he outlined a role for writers in, effectively, recording institutional memory. I still regard this as a viable prospect.

    1. Paul, your point absolutely applies in this discussion. Technical communication is but part of the larger scope of information management. A common model, “data -> information -> knowledge -> wisdom,” is useful in at least showing that there is a spectrum of value that technical communicators can bring to their craft. Content strategy is a trendy term for the right side of this spectrum, but in today’s web content world it has been narrowly focused on generating conversions (getting site visitors to take an action based on content). Technical communicators have the opportunity to enlarge that definition in a number of ways: helping site visitors be successful in completing a task, satisfying a request for specific information, providing understanding of how and why thing behave as they do, and increasingly, interpreting the meaning or significance of information in ways that influence opinion, inform on decisions and policies, and going beyond simply recording institutional memory: making it actionable by documenting business rules and guidelines and by testing the usability of that knowledge both by human readers and by tools that may be driven by it (where API writing happens to fit, IMO). Necessarily, upping your value towards the right (or “in the reading direction” to be Localization Correct) means upping your skills in information management. This does not mean “death of technical writing” but rather “transcendence of technical writing.”

      1. Thanks for this info, and that’s a good point about techcomm being part of a larger whole. And I agree when you say that we as techcomm professionals can, and should, “enlarge that definition in a number of ways.”

        “Transcendence of technical writing” is a great way to phrase that.

  7. Thanks for your thought-provoking posts, Neal! Ironically, our skill set is more in demand than ever before, precisely because of the Web and simple publishing tools. Today, everybody can post to the Web and be read by everybody else, and everybody DOES post to the Web to be read by everybody else!

    You mention that at your startup, everyone (more or less) contributes to the wiki, which sounds typical. But I suspect that what you have is a pool of content creators of widely varying communication skills. They weren’t hired for that skill set, so there’s no reason to expect they have it. Further, some are writing in English as a second language. (I’m not knocking it—I couldn’t function in any language OTHER than English!) So, I’m guessing that only a small subset of content is being created by knowledgeable, reasonably skillful writers working in a language they’re comfortable with. And if these are the documents you present to your customers, you may be having the typical problems such documents create. When you find yourself in a contract dispute with a client over what an ambiguously worded document actually says, the costs become clear.

    I do not mean to spread FUD. All I want to point out is that the skill set we possess has value. I like your idea of trying to raise the bar by passing on that skill! It might be that a transitional role for technical communicators is that of information curators.

    Recently, we had a problem with our coffeemaker, and I found many YouTube videos on how to fix the problem. The one I chose (which worked, by the way) was made by a 12-year-old boy. The company’s official video on troubleshooting the problem had seven times as many hits, but the kid was in the race. In a world where a Google search for your product will return hits from company sources, customers, pundits, bloggers, and dissatisfied customers alike, how does one know where to turn?

    I think in future we will have to add a new C to our mantra of creating clear, concise, and correct information products. We will also need to make the information credible as well. Credibility comes from being an “official” source, but otherwise our work has to stand on its own. Presentation, format, hygiene (spelling and grammar) and accuracy all contribute to credibility. Fortunately, again these are areas we’re good at, so our skill set remains vital and valuable. We just have to sell ourselves better…!

  8. I have to admit that I approached your articles with a biased opinion–dead? How could the profession I’ve worked in for the past 35 years be dead? But, I realize that you were not really talking about the profession as I know it…you were discussing a “technical writer” in the sense of user documentation. To me, that’s just a piece of the technical communicator pie. Years ago, Andrea Ames did (and may still do) a presentation on Strategic Communicator versus Commodity Writer. I try to work and teach the skills needed to be a strategic communicator. It seems many of those who have commented on your articles also see the profession in that manner. And, as you have pointed out, so do you. So, if your title of “The death of technical writing” was meant to get attention, it sure did! And, it’s probably true. Technical Communicator, however, is alive and well and thriving. We are needed everywhere to help communicate clearly and concisely–whether that’s in a wiki, in a blog, or in the background design of an app. We’re there. We might be called something else, but we bring that broad knowledge base with us that helps others get the messages they need to work, live, and play. It’s a grand profession to be in and one that I’m proud to have had and help support for a long, long time.

  9. Technical writing is more UX than Marketing.
    Technical writers are too verbose, forget who they’re writing for, and are terrible at marketing they’re skills.
    Technical information is increasing, not decreasing.

  10. Nice piece and full of valid points.

    Small side note. I find it interesting that you call ‘content strategist’ a funny job title, while at the same time calling upon technical writers to perform ‘strategic tasks’. You even state that you’re acting like a content strategist part of the time.

    What’s in a name?

    Maybe higher management will notice a content strategist a little easier than a technical writer; however unfair that may be. I call myself a content strategist, but what I do differs from project to project. But the label – besides the work I do – does get me places.

    1. “Funny” is meant to be tongue-in-cheek to go with “new” (“funny new titles”). In my experience, “content strategist” is not as familiar as “technical writer,” although that’s changing. As I said, I know that Facebook has a ton of content strategists, and at least some of them are creating content. I don’t know whether they have anyone with the Technical Writer/Technical Communicator role. Maybe they call them Copywriters (*shudder*)?

  11. I think your observations on the topic, and the comments left in May are all great!

    For the last year I’ve been mulling over definitions, titles, descriptions for both what I do, as well as what I want to do.

    Increasingly, I find that I want to write, to collaborate online, and to keep a comfortable schedule that allows a full family life. By the way, I loved your more recent post written while awaiting your daughter’s dance recital!

    For my own goals, I plan to continue creating content, and to use that platform to generate customer leads. At the same time, however, I want the scales to tip toward content that provides an opportunity for passive income based on the services and products that I rely upon. As an example, I have a What I Use series on my blog that answers questions that I get about the ways I produce video or #techcomm in general.

    I’m alone in those goals, as I’m seeing more #techcomm folks writing on variations of the field like strategy, marketing, video, and others. It will be interesting to see how we’re all making our way through the world in the next few years. While our job titles may all be different, I strongly suspect that we’ll all be using our skills to connect with our customer, much as we (should) do now.

  12. I find reading this article and the comments a bit strange. I have been working mainly in the safety space for well over ten years now. At first for a railway organisation and now for an air safety organisation. Almost nothing I have read here resonates with me and my experience of writing in this environment. I have not been concerned with ROI, and I hope never will. I was more concerned with preventing blood on the tracks in the railway industry, and with trying to ensure that aircraft are operated without incident in my current position.

    The ability to remove ambiguity and to sort through the engineering issues or the legality of an operation’s activities will probably never be replaced by automation. This ability helps to make our complex world work at a fast pace whilst maintaining the kind of security that we expect. This doesn’t happen by accident, it happens by diligent smart people figuring out how to communicate safe processes to the operators or engineers working at the pointy end of an industry.

    Maybe part of this discussion should in part be on the wide range of what constitutes a ‘technical writer’. As for my own goals as a technical writer, I want to make this world a safer place, I think a lot of the discussions in this blog are trivial. For example; punctuation, spelling and grammar are almost irrelevant other than as a basic communication requirement. Much more important to me is being able to digest sometimes disparate concepts at a very high level and where required to investigate how something should really work until you are totally satisfied with your understanding. The final step of being able to encode that understanding into clear English that your audience will grasp quickly is often by comparison a trivial step in the process. However having said that, even the last step often requires an ability to express a complex concept simply, and that is a skill which I do not see any machine being able to replicate for quite some time.

    1. I’m reporting my experiences, and that’s in the startup/enterprise software area. Maybe you’re in field that isn’t seeing a lot of change, but many of us in the high tech field are dealing with new requirements (ROI calculations, minimum viable product, agile development) that change what we do and require that we constantly learn new skills. Some of these concepts might apply to you: increased collaboration with other teams, a move to more efficient doc processes, and increased communication with your customers to learn what content they need and how they want to consume it.

      Maybe these changes haven’t affected your industry. But they’ve certainly affected me, and I’ve had exec teams closely evaluate the cost centers in the company to see where they could afford to run leaner. Which means that I need to articulate the value I create for the company. If I want to buy new tools or hire someone for my team, I need to be able to explain why in terms of dollars saved or generated.

      Some of this is a change in the software industry (lean startups that are much more concerned about keeping the burn rate low); some of this is because I’ve moved up the ladder from a junior writer to a management position. But I’ve seen (and interviewed for) more and more job openings where writing documentation is only one part of the role, and they’re also looking for someone who has programming/API experience, who can create videos, who can help with content strategy, who will be the user experience expert, or a combination of those.

      While there are still traditional technical writer jobs out there, we must expand our roles and our skills if we want to remain competitive (and employed) for the next 10 years.

      (I was going to say “10 or 20 years,” but I don’t believe the “technical writer” job will exist at all in 20 years, or as anything more than a niche role in a very small number of industries.)

    2. I love this quote!:

      “For example; punctuation, spelling and grammar are almost irrelevant other than as a basic communication requirement.”

      I’m relieved that I’m not the only one with this perspective. Over the years I’ve experienced quite a lot of guilt (or cognitive dissonance?) from my lack of interest in the minutia of grammar. If a sentence causes you to pause to consider proper punctuation and grammar, it should be rewritten so that you don’t have to pause to consider proper punctuation and grammar.

Comments are closed.