Your perspective shapes your work and your future

For tech writers, perspective is very important. How you look at your job determines what kind of documentation you deliver, how valuable it is, and what kind of success you’ll have.

Gaining perspective in stages

In more than 10 years of writing full-time, I’ve gone through three successive stages:

1. Serving the product of the company which pays me
2. Serving the company which pays me
3. Serving the customer who pays the company which pays me

This development has led me from introverted writing to extroverted content management, from specific manuals to abstract content strategy. Each stage gets more difficult and increases the demand for managerial thinking, even though you may not formally manage anything but your documentation and yourself. (See my previous post “Manage documentation as a lone writer“.) But each stage also adds more value to the documentation you produce – and hence for your company and for you, too.

Which stages are available to you depends not only on your motivation and skills, but also on the expectations on you and your job. In fact, a mismatch between your perspective and outside expectations on your job is a problem. You and your boss may talk about documentation, meaning different purposes and different ways of doing it.

Serving the product

This is the conventional, old-fashioned perspective: You create a description of the product and all its features. This is fairly easy because the selection and structure of the documentation is largely determined by the product. In software documentation, you often see one section per menu or menu item.

This documentation adds little value beyond spelling out what’s where. Your readers learn which function does what, but they may still have to learn how to use the product for their purposes. User of a word processor who try to create a book in ready-to-print PDF with table of contents, headers, footnotes and an index are easily at a loss with disjointed instructions about page layout and reference marks.

Serving the product sells tech writing short, since we can do so much more. With this perspective, documentation is often seen as a necessary evil. People who think no one reads it outnumber those who use it. I’ve seen tech writers stuck with this perspective; changing this perspective  to one of the other stages is fairly difficult and requires motivation, persistence and self-marketing – or even a new job…

Serving the company

This is often an implicit, informal task for tech writers or other job profiles, especially when the company is better at producing information than at structuring and maintaining it. If you hear: “We really should have a glossary,” this is your company. If you’re in charge of the glossary, you’re serving your company. With this task, you spend a lot of time assembling and structuring existing information about the product, its uses, benefits and markets. The role often feels like a research librarian.

This adds some value, because users and the company get a more coherent idea what the product is and how it should be used. You literally help the company “make up its mind” and stay on message about the product.

Serving the company gives a tech writer more freedom than serving the product – but also less structure within which to work. Even though it feels vague and in limbo, it can actually be a pretty stable and satisfying position if you feel you can successfully apply many different skills. This can also be a great position to re-orient yourself and aquire additional skills. It tends to get dodgy, however, when the company goes through fundamental changes, because this role lacks a clear profile and you may find it difficult to prove your worth.

Serving the customer

This is the task-based perspective on documentation: You show the user how to achieve his tasks with the product. You combine elements of the previous two perspectives. You take the features and functions of the product, combine them with the use and markets that the company intends, and translate it all into the user’s language and purpose.

This is the most difficult of the three perspectives, but also the most valuable. Your documentation helps users to get stuff done. It ensures that the product is actually as successful as sales and marketing claim it is. You’re rooting for the actual standard user – not the potential users who haven’t bought the product yet, or the complaining ones of customer service who need specific help.

Serving the customer raises your tech writing profile as the users’ advocate and demonstrates best which value you add – but it won’t make you universally loved: As you champion usability, you compete with marketing and product management which push for benefits they want to sell and with development and with production which focuses on the specific functionality that they can produce efficiently. However, if you can show that improving usability pays off in higher sales or lower support costs, you can directly contribute to the company’s success.

Your turn

Which perspective do you think is most useful for tech writers? Are there others that I’ve missed? What’s the best way to get yourself and your boss into the one you prefer?

Advertisement