---
title: "Part IV: Enabling information flow"
date: 2017-12-28
description: "Docs aren’t the espresso machine Outsourcing doc needs The value of information flow The value of information flow  <div..."
canonical_url: https://idratherbewriting.com/2017/12/28/value-of-tech-comm-in-company-part4/
---
# Part IV: Enabling information flow
## Docs aren’t the espresso machine

One problem is that docs aren’t sexy — they don’t have a high value or esteem in an organization. Many people dislike the very idea of docs. As mentioned earlier, for UX designers, the inclusion of docs might suggest a failure in design. For product managers, the idea that their product (which is supposed to be easy and intuitive to use) should actually require a lot of documentation also suggests failure. Imagine product managers chatting with each other: *Your product needed documentation for users to understand it? Oh, my products are so intuitive, our users don’t even need documentation.* Docs are like a crutch for a product that should stand on its own.

Users, too, do not welcome a hefty user guide. A writer once described the sound a thick manual plunking down on a desk as an “almighty thud” — the thud fills users with despair for all the learning that will be required.

If docs are our only contribution, and almost everyone dislikes the idea of docs, will we ever rise above our low place on the totem pole of value? Can we move past the idea that technical writers merely contribute documentation? What would our additional forms of value look like?

## Outsourcing doc needs

If the only value technical writers provide to an organization is documentation, their value may eventually be outsourced. Here’s an experience to illustrate. I once worked for a non-profit corporation in Utah where we tracked our time against various cost centers. For example, if you worked 3 hours on Project ACME for the day, you entered this into a time tracking spreadsheet, applying the 3 hours toward Department X. Inside the corporation, each department had a certain budget of how much they could spend. Our time spent on documentation for their department was applied against their budget.

We thought the setup was just some annoying accountant trying to track spending. But one day, the company announced that they were laying off *all* the technical writers (in addition to about 7% of the total IT workforce). This shocked us. We didn’t think they would remove an entire function within an organization. Maybe 1-2 writers, but not *everyone*. But alas, it was true. *Audios, writer amigos!*

In retrospect, I think this is what happened. Behind the scenes, some bow-tie-wearing, clever accountant was doing an internal-versus-external cost analysis, similar to a buy-versus-build cost analysis. Was it cheaper to employ full-time technical writers at, say, $80 an hour, or to outsource technical writing needs to an external vendor for $60 an hour? The decision must have been to outsource because it was less expensive, and the company would still get documentation in the end.

The corporation provided generous compensation packages, and I made my way to California and started a new life there. Over time, I learned that the corporation hired some of the tech writers it laid off as long-term external vendors and paid them more than they were earning as salaried employees. Some departments even re-hired full-time technical writers on an individual basis (rather than having a centralized tech writing team). So clearly, the decision to outsource as a way to cut expenses was not a slam-dunk for cost savings as the accountant had hoped. Why not?

One reason may be that, ultimately, documentation wasn’t the only value the tech writers provided. Contract technical writers are contracted to provide one service: documentation. Because the contractor’s role is fixed around this end, the contractor can cheapen the rate, charging only $60 an hour and coming across as less expensive than the full-time salaried technical writer.

But the contract technical writer is not going to provide any of the extra services that are typically included in the salaried technical writer’s role. The contract technical writer will write only the needed documentation topics as specified by the contract. The additional services not included by the contractor might be as follows:

 - Testing out the instructions in detailed ways (maybe even trying to break the system)

 - Logging bugs when identified

 - Providing user interface feedback

 - Analyzing trending support logs, and then providing documentation to address these trends

 - Setting up and maintaining the authoring and publishing system

 - Maintaining existing documentation over the life of the product with each new release

 - Informing other groups, across organizational boundaries, about relevant docs and information

 - Training field engineers on the new functionality

 - Meeting with field engineers to gather input about user pain points, and then relaying those pain points back to engineering teams and UX designers to improve the product

 - Working with Marketing groups to review upcoming blog posts and ensure the information syncs with the documentation harmoniously

 - Staying abreast of industry trends around the product to identify information needs in the documentation and product, and so on.

Contractors avoid these additional tasks because these activities drain their time, and they agreed only to write the given documentation. Salaried technical writers tend to perform these other activities, though they often don’t get credit for them and the activities go unnoticed. For example, the only resource tracked in that accounting spreadsheet is “hours” for “documentation.”

If all a company does is analyze hours for documentation, the tech writer will eventually be outsourced because it’s simply cheaper to get documentation from an outside vendor. As more support for this idea, follow this thought experiment.

Suppose you were to start *selling* documentation as a product to other groups in the company who need it. Do you need documentation for Project X? All right, based on the estimated 50 pages needed, we will charge $16,000 for the documentation. (50 pages x 4 hrs per page X $80/hr = $16,000.)

This might seem like an ingenious way to assign a direct value to documentation. It would tell you exactly how much your documentation is worth, right? If the groups won’t pay the money, documentation isn’t worth the cost. But you hope they will pay it because surely they can’t release a product without documentation.

But now Department X starts doing some research. Although your tech writing team wants to charge $16,000, they find that a contractor will do it for $10,000. This becomes a no-brainer. They just saved $6,000, which they can use to pay an intern to do even more work.

I’d love to find examples of tech comm groups that actually started charging for docs to see if my thought experiment is correct. But my point is this: It’s not enough to just provide documentation. Tech writers must provide additional value to the organization. Where might this additional value come from? One benefit might be to foster **information flow** within the organization.