Unless you work for a technical communications boutique that specializes in providing technical information solutions to other companies, there’s a decent chance that your boss’s boss doesn’t really understand what you do.

I think that tech writers in most companies are kind of like the IT guy at the dentist’s office: the rest of the folks are smart and capable, but their expertise doesn’t even overlap. The dentists and dental hygienists think IT is probably necessary, but they’re content to just trust the IT guy to take care of it so long as nothing goes wrong.

Some technical writers like it this way. When people are willing to just let you take care of things, they just take your word for what needs to be done and don’t bug you. Plus, there’s the more nefarious notion that keeping your job and job skills a secret gives you job security because no one else will know how to do what you do.

But that only works for as long as people think that what you produce is necessary, which isn’t going to be as long if they don’t understand your contribution. Besides, when people don’t understand what you do, they can’t imagine new and creative ways to utilize your skills. If you can’t capture your boss’s boss’s imagination with all the cool things you have to offer the organization, then opportunities for exciting new projects can be few and far between.

I say it’s better for your career and esteem not to hoard your tech comm knowledge. Instead, you should share your knowledge freely so that people can have a deeper appreciation for why what you do is so difficult and special and ultimately beneficial to everyone. Here are some methods I use to try to make people around me understand the product documentation effort:

#1 – Internal marketing

Well this one’s obvious: if you want people to know what you do, tell them. We are, after all, professional communicators. This ought to be right up our alley.

Speaking for myself, I try to use lots of interesting channels to make people aware of what’s going on in the Doc team.

Company newsletter

Every month a call goes out to the departments requesting blurbs for our internal corporate newsletter, and every month I send something in. Some months I don’t feel like there’s a whole lot exciting to say, but I send in my submission anyway—even if it’s about something I’ve talked about before—because I can never talk too much to this audience.

This month, a new person was doing the newsletter, and he gave me some resistance to my blurb about the new contextual user assistance system that we’re introducing into our new product. “Help me understand why this is news,” he said. That might sound a little confrontational at first, but I love it when people ask for more information in situations like this, because then I get to talk about my passion. So I told him,

[This UA system], as designed, is a remarkable advancement in user-assistance delivery, not just compared to legacy documentation products in our company, but in the entire field of technical communication. I was on the phone with the CEO of the company we’re working with to build it, and he told me, “I want to buy up the keywords related to this project, but you’re so far out on the bleeding edge that the words don’t exist yet.”

I refrained from actually typing “BOOM!” at the end, but that’s what I was thinking.

The DocuCast

Once a week I record a podcast (the DocuCast) that is less than 5-minutes long and email it out to coworkers who have expressed an interest in it. It’s just a quick chat about what’s going on in and around the Doc dept this week. The idea is this: if I ran into a coworker in the break room and they said, “hi, what’s going on with you lately?” this is the stuff I’d tell them.

The whole exercise takes about an hour a week: 15 minutes to write the script, 15 minutes to record, and 30 minutes for my audio guru to edit out my mistakes. But this exercise has more benefit than just communicating our progress to the world; it also forces me to evaluate what’s the most interesting and important thing happening this week and creates an audit trail of what we’ve accomplished over time.

Weekly project updates

For very big projects where lots of cross-functional roles are involved and people have trouble keeping up, I send out a weekly project update email. This is hard to write, sometimes because it feels like nothing has happened in the week and sometimes because it feels like so much has happened in a week that I can’t possibly sum it all up. But it’s essential to send no matter what because it keeps the project top of mind and reinforces the notion that the Doc team is central to the progress of the project.

#2 – Adopt an ‘Anything I can do to help’ attitude

To be central to business processes, you want people to be coming to you with their problems, which they will do if you have a reputation for being helpful. Everyone in business is super-busy right now so people often get a “not my job” kind of response when they act for help. When you’re willing to pitch in, you benefit in lots of ways:

• You set yourself up for that person to come back to you with future problems, which gives you visibility in more projects.
• You get the chance to show off a wider variety of skills.
• You get the satisfaction of helping someone achieve success, which reflects well on you and makes that person grateful to you.

This can be a touchy subject among technical communicators because people are afraid that being too willing to help with side projects will get them relegated to the role of project typist. It’s a real risk because technical communicators have many essential administrative skills that everyone on the project should—but does not always—possess.

So, when I’m asked to do something below my pay grade, like simple proofreading, I agree to help out and then turn around the job very fast to demonstrate that it wasn’t very hard. In addition to copy-editing mistakes, I’ll also point out any deeper document issues and suggest improvements to the structure, localization readiness, copyright usage, and other stuff that the original authors didn’t think of. The next time around, the authors are likely to get me involved earlier in the document creation process to discuss these kinds of issues up front.

#3 – Get other people to do your work

If you are in the information-hoarding mindset, it will seem counterintuitive that you make yourself more necessary by giving your work away. But there’s no better way for people to understand and appreciate your work than to try to do it themselves.

We create our product documentation in a MindTouch wiki that it available for anyone in the company to contribute to, and we encourage people to make additions and edits. In my experience, when given the opportunity to write their own documentation, about 75% of the people will try it, realize they don’t have the temperament for it, and then go forward doing a better job of incorporating the tech writers earlier.

The other 25% find that they do really like being able to contribute that way as long as they have your support for things like editing, voice, and automation. These people are also great because they allow you to take on more of an information management role and free up your time to dig deeper on other projects.

In summary

It’s true that information is power and that by hoarding information you can give yourself job security…for a while. But by giving your information away and getting people involved in your processes, you can make yourself truly indispensable.

Now, there is some irony in me writing these tips, because while I feel like these tactics have been beneficial to how my department is regarded within the company, I still think that there is more we could do to capture people’s imaginations when it comes to leveraging our skills in new and interesting ways. I’d like to know what tactics you have used to integrate your technical communications operation into the central business processes of your company. Use the comments to share your stories.