5 Ways to Make Executives Love the Publications Department

“Publications never gets any respect,” is a refrain I’ve heard over and over again during my time in the Technical Communications industry. In fact I’ve even said it myself a few times. The refrain is often followed by, “no one really understands what we do, or the value we provide.” The unfortunate thing is that in a lot of cases these refrains have some justification, but it needn’t be that way.

As an example over the years I’ve visited literally hundreds of publication teams in a variety of companies and industries, but one of my most striking memories is the sheer contrast between two publication departments at a couple of luxury car manufacturers.

At the first company, the documentation department had a nice modern office, in a new campus setting. They had all the latest computers and access to great technology. In the parking lot outside the publications office was a fleet of not only their own cars, but those of their nearest competitor. Any member of the publications team could use any of the cars, in exchange for filling in a small usability report. The publications team were a high profile part of the customer support organization and were considered by the marketing team as part of the product “life style” branding activities.

At the second company, the publications department was in an old hut (in fact it was an old coal bunker) at the back of the factory, far removed from the production line, engineering, or any other function it needed to interact with. Although cars were parked outside, the team had no access to them. They had only a handful of computers and their technology was at least five years behind their competitors. The sole mandate was to produce a small defined set of hardcopy manuals. And that’s all they did.

So why the difference? In short the team at the first company acted like they were part of the company and projected a positive image of their skills. As such they were recognized and rewarded. The team at the second company stuck to the “we are only tech writers,” approach. They were, in many ways, responsible for their own position.

So if you feel that your publications team is “in the coal bunker” – how do you change things so that you get the keys to the luxury cars?

The following presents a basic five point action plan to help you raise the profile of what you do and make your executives love the Publications Department.

1. Realize exactly what it is the Tech Doc team does. - Before you can raise your profile, you need to know what you have to offer. Chances are that most Publications teams have talents and skills that exist no where else in the organization, and I’m not just talking about the ability to write. Also most often the Publications team is the only place in a company where all the company’s intellectual property comes together. Publications isn’t about “producing user manuals,” it’s about managing your organization’s greatest asset - knowledge.

2. Tell a good story. – People react to stories on an instinctive level. It’s easier to remember stories than it is dry facts and figures. Publications is the natural bridge between the end user and the company design, engineering and production teams. Gather stories and tell them – repeatedly. Come up with your own stories that illustrate the importance, frequency and impact of your own work. Develop fun trivia about what Publications does that people will remember and repeat.

3. Offer your services for fun and profit – Develop an in-house user community, not just an external one. Look around for other functions that you could work with or offer your expertise to. Develop an entrepreneurial mind-set and you’ll find opportunities to transform publications from an overhead cost-center into a profitable contributor.

4. Hook an executive sponsor – Find an executive’s pet project that could need some creative input, e.g. a little wordsmithing, or some graphic design work, and get involved. While the work is progressing make sure to bring the executive into your environment, and show off what the publications team can achieve.

5. Change attitudes. – If you go around say “I’m only a tech writer,” or “publications never gets any respect,” then people will believe you and act accordingly. Be aware of what you do, what you can offer and be proud of it. Treat your team (even if it’s only you) as if it was your own business. Build brand awareness, market and promote what you have to offer, and sell yourself, your team and the profession.

Over the coming weeks I’ll take a expand on each of these and provide some examples and suggested strategies.

2009 Conferences - Never mind the quantity, experience the quality.

In the current economic climate one of the first items that get cut in any budget squeeze is usually travel, and subsequent attendances at industry conferences. But, judging by my experiences at the two industry conferences I’ve attended so far this year, DocTrain West and WritersUA, this is a false economy. Yes attendance was down at both, due to aforementioned budget and travel restraints, but they were two of the best conferences I’ve attended in years.

Simply put, those people who were at the two events, were fully engaged in the conference. The conversations were compelling, interesting, relevant, and thought provoking. The speakers seemed to be of a higher quality and all the presentations were equally worthy of note and attention. The organizers of both conferences had put together excellent sessions with distinct themes. Most of the time I found myself attending one excellent session while at the same time wishing I could have been at a different concurrent session that sounded just as interesting. The most difficult aspect of these two conferences was scheduling your time.

Having spoken to several people who also attended either one, or in some cases both, of these conferences, it seems that I am not alone in these opinions.

So why in a time of economic belt-tightening are the conferences so much better?

Firstly I believe that the majority of people who at the conferences, speakers and attendees alike, most likely had to give a good justification for being there. While you should always have a good reason for attending any conference, having to justify the expense can be a great motivator and help you to determine a real need. Everyone who was there, was there to learn. And if I perceived one over riding sentiment from both conferences, it was that they were unparalleled opportunities to learn from industry experts and peers alike.

It was noticeable that attendance at sessions on the last day was just as high as those on the first day, and that conversations started over breakfast continued on into the evenings. Conference attendees put in much longer hours than they do in the office.

Secondly, the organizers and presenters have realized that sessions that are little more than thinly disguised marketing pitches very quickly lose you confidence and respect. The result is that most sessions today are highly focused on presenting real world results, or best practices based on experience.

Everyone I spoke to at both conferences also believed that by being in attendance they had given themselves, and their companies, a competitive advantage. Whether it was new technologies that they hadn’t considered before, like wikis; learning how to apply industry standards like DITA; or new techniques that could save time and money, such as the application of controlled languages, or a greater use of graphics; all had come away with something that more than justified the cost of attending.

In a couple of weeks I will be at the STC National Summit in Atlanta, and I will be interested to see if the trend towards increased quality and excellence continues.

[If you are at the STC Summit I'll be speaking on Tuesday 5th May at 1:30pm in the Hanover AB room, or you will be able to find me at Booth #109 for most of the show.]

NOTE: This blog entry was first published as part of my WebWorks blog

The Future is Today

Back in December I posted an entry on this blog about how observing my daughter do a homework assignment had made me rethink the way we need to approach presenting information. In business we are still bound to the book paradigm that was created in the nineteenth century, and that we, as "adults," are more comfortable with because it's the way that we were taught to find and assimilate information.

My conclusion was that today's generation approaches information gathering and learning based on a different more chaotic model, where social interaction is more important than structure. In short to survive and prosper we should start designing information not for ourselves, but for the next generation.

Today I came across this video - which makes the point much better than I ever could - the video's focus may be education, but it applies just as well to the future of corporate communications.

Writing about Wiki - New Book Project

I mentioned this in passing on my Twitter account the other day, but as it was officially announced today, I thought I'd post a few more details.



WIKI: Grow Your Own for Fun and Profit
by Alan J. Porter

Looking for a way to increase team collaboration, manage your company’s knowledge? Do you need a way to manage projects with customers or suppliers outside your company firewall? Would you like your customers to provide feedback on the information you publish? Then a wiki might be just what you are looking for.

Perhaps you have already decided that you should use a wiki, but are not sure how to go about it. Maybe you have a wiki but would like to encourage more people to use it. Or you would just like to learn more about the practical applications for this fast growing technology.

Then this is the book for you.

WIKI: Grow Your Own for Fun and Profit will introduce the concept of wikis, and show why they are becoming the must-have communications and collaboration technology for businesses of any size.

The book will also include several case studies highlighting the ways that various companies are using wikis to solve differing business and communications issues, and the resulting benefits in terms of both efficiency and customer satisfaction.

WIKI: Grow Your Own for Fun and Profit will be available early next year, but we will keep you informed with excerpts and news along the way.

The official web site for the project is HERE, and it will be updated as the project progresses.

Why Technical Writers Shouldn't Be "Writers" - Slides

Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.

Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)

The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.

What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?

Several people have asked for copies of the slides I used, so here they are.

However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."

If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.

Why Technical Writers Shouldn't be "Writers"

View more presentations from 4JsGroup.

Should Customers Pay for the Manual?

Yesterday a friend of mine posted the following on his Twitter feed

OMG! (Company Name) actually charges for their owner's manuals! That's absurd.

Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?

Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.

Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.

Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).

The total cost of ownership for both products over the normal operating span turns out to be just about the same.

Let's take a look at the two scenarios in more detail.

COMPANY A - Documentation Included

This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."

That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).

COMPANY B - Documentation Sold Separately

In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.

One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?

So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.

BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.

On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.

And the customers liked it too.

Don't educate...learn!

Earlier today I came across the following post on a Tech Doc related discussion list.

We still use X and while we (the tech writers) think they are useful, I think our users mostly rely on Y. We've attempted to educate our users on the value of X, but based on the questions I get I don't think a lot of our users think of using X on a regular basis.

(AJP - Quote edited to remove names of specific processes)

Wow - so if I get this straight, the users of the information like to use it one way (Y), but the content creators think they should be using it another way (X) so they make every effort to "educate the users" as to how it should be done.

If the majority of the people who uses your content are following the same behavior pattern, isn't it better to look at why they are doing that, and the value that THEY find, rather than the value that YOU think is there.

Learn from your customers. Find out why they prefer Y to X, and then do what you can to make Y even better. If that means dropping process X, then do so.

Those of you who have heard me talk will have heard this before, but the documentation industry is not about us as content creators, it's about our customers and how they access, assimilate, and use that content.

10 Commandments of Storytelling as applied to Tech Doc?

One of the topics I am slated to deliver at various conferences in 2009 is my presentation on why I think “Technical Writers Shouldn’t Be Writers.”

Towards the end of that presentation I have a slide that mentions four recommended books as “must reads.” One of those four is Robert McKee’s “STORY: Substance, Structure, Style and the Principles of Screenwriting.”



Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie.

It seems I’m not alone in that thinking. Over at the excellent slide:ology blog a recent post applies McKee’s “10 Commandments of Storytelling” to PowerPoint Presentations.

Picking up on that thought I decided to see if I could apply McKee’s 10 Commandments to Technical Documentation.

1. Thou shalt not take the crisis or climax out of the protagonists hands.
So who is the “protagonist” of your documentation? It could be your product, but the most likely candidate is that your “protagonist” is the person using your documentation. Your documentation should be written in such a way that your protagonist can use the information so that they feel that they have solved the crisis (or put more prosaically, overcome the problem they have) themselves based on the knowledge you have presented. Another story telling trick, often cited by screen-writer Todd Alcot, that is worth remembering – ask yourself “What does the protagonist want?”

2. Thou shalt not make life easy for the protagonist.
This seems contrary to the very purpose of Technical Documentation. Isn’t it our job to make life easier? Yes it is. But in certain types of documentation, such as training materials, you may want to include challenges, and then guide the reader through them. This way you can build a sense of accomplishment as the reader progresses through the material.

3. Thou shalt not use false mystery or surprise.
Don’t hold back anything that is integral to full understanding of the product or service you are writing about. But also make sure to reveal information in a logical manner that is considerate of the reader’s needs. Make sure they have the information they need to know, at the time they need it.

4. Thou shalt respect thine audience.
The first rule of any sort of writing is “know your audience.” Know them, and respect their level of knowledge. If you are writing something for experts, then you may not need to include the basic information that you might use for a more general consumer market. The use of conditional text is a great way to handle different topics and statements designed for different audiences within a common documentation set.

5. Thou shalt have a god-like knowledge of your universe.
A joke I often use is “What’s the definition of an ‘expert’?” – The answer is “it’s a person who has read two more pages in the manual than you have.” So what does that make the person who wrote the manual in the first place? We may not know everything about what we are documenting, but we should give the reader the confidence that we do.

6. Thou shall use complexity rather than complication.
Most of what we write about in Tech Doc, is by its very nature, complex. We should take that complexity and break it down into logical steps and topics that can guide the reader. We should never use complexity as an excuse for making the documentation complicated.

7. Thou shalt take your character to the end of the line.
We learn in grade school that every story should have a beginning, a middle, and an end. The same applies to documentation too. The narrative should guide the reader through the process, or information, in such a way that it flows logically, and that at the end they know more, or have achieved more, than when they started.

8. Thou shalt not write on the nose dialog.
Wait, I hear you asking, there’s no dialog in Tech Doc – so how does this apply? Well the definition of “on the nose dialog” relates to the scene when a character says aloud, exactly what he is thinking or describes what is happening around him. So how does this apply to Tech Doc? Do you have sections of doc that are restating the obvious? Try reading your docs out aloud? Is it boring and repetitious? Try altering sentence lengths. Don’t think anyone ever listens to docs as if it was dialog? As a teenager I spent hours working under cars while a buddy nearby would read the steps from the manual for me to follow. How about a visually impaired customer using a reading device?

9. Thou shalt dramatize thine exposition.
Put simply “show don’t tell.” In prose this means have your characters reacting to an event, not talking about it. But isn’t our job to tell people how to do something? Yes it is, but the key word is “how.” Replace long descriptive texts on operational theory with a few active steps the user can take themselves, that demonstrates the product, and they will gain a quicker understanding. People learn more by doing than they do by being told.

10. Thou shalt rewrite.
Do I need to explain this one? Plan your schedule with time to write, have someone else review, and rewrite. Best of all scenarios is to write, have someone actually use your draft to accomplish the tasks you have written about, get feedback. Better yet, watch them try to use your docs. Then go back and rewrite based on your observations. They say that any good piece of art is never finished. Writing is art, even Tech Writing. You can always improve on what you’ve done.

Banging The Drum Again...

In his excellent blog post about the current state of the book publishing industry Mark Tavani, a Senior Editor at Random House, makes the following observation.

... books are a mere format. Yes, they can be beautiful and wonderful to hold in your hands, and yes, there are some books I plan to keep in my home until the day I die simply for their sentimental value. So I understand what is magical about books. But the most magical thing about them is the information they convey: the story they contain. The word “book” and the word “story” are not synonymous, just as eight tracks and music are not the same thing. Stories pre-date books by milleniums; and though books might someday go away, story will last as long as our civilization does.

Substitute the word "book" for "documentation," and the word "story" for "content" and I think the observation applies equally to the world of corporate publishing as it does to traditional book publishing.

=========

I need to add a couple of points of clarification here.
- Anyone who knows me and has heard me speak will know I love books (the traditional kind). I have a house full of them, and spend my evenings and weekends writing them. BUT while I'm a passionate bibliophile, I am also aware (as I mentioned in my last post) that the "book model" is perhaps no longer the best model to be using to ensure that content reaches the end user of a product or service.
- While I suggested swapping the word "story" for "content" in the quote above, that was more to illustrate a point. For me everything we write or produce that is designed to pass on knowledge or information is, and should be treated as, a story. The ability to tell stories is the most powerful communications tool we have at our disposal. As Tavani points out, we've being doing it for millennium, and will continue to do it irrespective of any technology or medium.

Move over DITA – Chaos is coming!

I’ve never really questioned the need for hierarchical structure and imposed taxonomies, - until I watched my teenage daughter doing her homework several months ago.

Let me explain.

I’ve been working with topic based authoring, structured content and mark-up languages for over twenty years now. This highly formalized approach to technical documentation has always seemed to be the right approach to take in handling larges amounts of complex information, and delivering it in a way that enables relatively easy navigation.

I’ve seen them all come and go – SGML, DocBook, XML, CALS, DITA plus a ton of various industry and company standards. I’ve even served on several such standards committees and working groups in my time.



For those of us raised on more traditional media (i.e. the printed word) we are most comfortable with the book paradigm. That information should come in a structured format, i.e. Chapters with Headings and Sub-Headings, and that navigation is best accomplished by either a map to that structure (i.e. a Table of Contents), or an alphabetical listing of subjects covered (an Index).

Naturally when we started to deliver information electronically we carried that paradigm over. Sure we made a few concessions to the new media (for instance I remember having a long, and somewhat heated discussion on why we didn’t need page numbers on a CD deliverable); but the underlying print based model stayed. Because that’s what we were comfortable with. It’s what we naturally understood and it matched the way that we handled locating and using written information outside of the work environment.

In fact for most of my working life to date, the technology I used at work far out paced that I used outside of work.

But not any more.

Now the technology I use at home has generally outpaced that found in most workplaces. In particular social media and the way that we look for information online.

Helping my teenage daughter with a school project on Pearl Harbor made me realize that the new generation now entering the workforce has a completely different way of accessing information.

Of course the first thing she did was google “Pearl Harbor” and started visiting links. First stop was Wikipedia.



Then she got on Facebook and YahooIM and started using messaging to ask friends who were online for recommendations. These friends were literally from all around the world, so she was given access to resources that gave totally different perspectives than those given in the classroom. As I watched she soon had six different windows open on her iMac and was pulling information from multiple sources into her own document. Building the structure and narrative as she went.

One friend suggested going to a social bookmarking site and searching using a variety of user applied tags. Instead of taxonomy she was now applying folksonomy.

Of course being a bibliophile and a bit of a history geek I had a few good old-fashioned print books on World War II sitting in my home office. I proudly placed them on the edge of my daughter’s desk and suggested she look through those for information on Pearl Harbor too.

She dutifully picked up a couple of the books and started flicking pages over, skimming through the contents.

“Why don’t you use the Table of Contents of Index?” I asked.

“That just confuses me. I can find stuff quicker this way,” she replied, looking in bemusement at her obviously aged father.

I sat back and watched her navigate the books for a few minutes. She quickly found what she needed – and then I realized what she was doing. She was “browsing” just as if she was online.

That’s when I started to question the paradigm that’s informed the way I’ve thought about online documentation for over two decades. The book driven, structured paradigm may have been ideal for my generation, but what about the new generation?

For kids raised as part of the “digital generation” where the first place they go to find out information is the internet and social networks, is the book an irrelevant model?

Yes the information they access still needs some sort of mark-up and tagging so the search engines can find it. It still needs metadata to enable user tagging. But instead of strictly enforced hierarchies, what is being built and accessed is more of a flat ocean of information (or a “Content Pool”) that users search rather than navigate, and then dip into to find the components they need to build their own solutions.

So where does that leave current favored structured standards like DITA? I believe they have a place in more rigidly defined and regulated environments, but how long they will remain useful is open to question.

As for more general applications I believe we need to stop trying to shoe-horn the current “flavor-du-jour” standard onto every publishing project, and instead take a step back and look at how your kids do their homework. Because in five to ten years they will be your new workforce, and perhaps more importantly, your new customers.