Rantings

This is a draft of a treatise about technical communication that I have been kicking around for years; I have yet to do something with it. I had thought of calling it ‘Transforming Communication: The Dynamic Nature of Key Content’ but at this stage it is just a set of rantings.


  1. Name Calling

  2. Introduction

  3. Transforming the Information Workplace

  4. Transforming Knowledge Development

  5. Freeing Dynamic Key Content

  6. Managing the Unmanagable


Name Calling


Most people do not understand technical communication as anything deeper than technical writing, which they perceive as something English majors do when they graduate and want to get a job in a high tech work force. But those of us who have some experience in the field know that there is a discipline behind it and it is our job to articulate it. Part of the problem is that there are many university professors who are teaching what they call technical writing but which is not what documentation professionals do in industry. Those of us who work in the field have neither the time nor the inclination to waste our time trying to articulate what we do or to convince anyone that it is an important job. But with changes in industry, there are reasons to take the time to explain it.


I have felt a lot of frustration working with people who do not understand the reasons for technical communication. And this includes many in the profession. It is not primarily about writing, as in writing a good book. It is about speeding the flow of information that must be put together in new ways for the health of the enterprise, not for the consumption of the individual. We differ from the novelist not simply because we do not express feelings and inward thoughts but also because we do not write for the individual reader. While some of what we create is the written word to be read by individuals, primarily technical communication must develop content and structure information with computers and for computers as well as with and for human readers.


There is this strange and persistent association of technical documentation with writing as taught in university English curricula. The sooner the profession breaks off the connection with university English departments the better. They keep monopolizing the discussion about what is the core of our profession.


What makes it a discipline is the business beyond the rhetoric — picking the channels of communication. In the past it was mainly documents and we distinguished ourselves from the broadcast communications media which was controlled by Madison Avenue and broadcast to the widest audience while we created documents spearheaded for specific audiences for specific reasons. Now we publish on the Internet, on the web, for the widest possible audience, yet aimed at a more specific audience for a more limited time as technology becomes obsolete more quickly. Broadcast media was public; technical documentation was corporate. Document types are blurring as we go online and out of time. White papers are advertisements and tutorials at the same time. Reports are reference material and marketing spin at the same time. Online help is technical support and user manual at the same time.


No amount of applied research into areas of no interest will save the profession. The journals on technical communication that come out of English departments add nothing to the profession. I have heard it expressed that what we need is not research but respect. Even when technical communicators know the value of good technical documentation and know how to develop and maintain it, companies will often not invest in it.


The difficulty is not with the professionals knowing who they are or what they can do. The problem is not with us as technical communicators. The problem is our placement in the larger technical community and lack of recognition. Until we are treated as technical equals with other professionals having a separate but equal professional status, having a separate professional society alone will not solve our problem. Our dilemma is NOT that we stand with our feet in two worlds (one technical and one literary) it is not that we are between two disparate cultures. We are experts in it and it comes easy to us. It is the other polarized camps, distant from each other because they refuse to recognize us, professionals who have different expertise, who refuse to recognize us. Until a large, international professional association, such as the IEEE, until the upper management in some leading IT corporation, until heads of name universities and colleges recognize that we are in a discipline of our own but a valid and professional one, then our problem of being a legitimate profession will remain.


This treatise is written for those who need to understand the critical role that technical communication plays in the work being done by corporations and organizations worldwide. I would like to use the phrase “knowledge development” because, as this book will show, there is more to the profession that simply passively communicating technical information. But one must use the language one has at hand to reach the intended audience, and most people use the phrase technical communication to cover the crafts of technical writing, technical illustration, web development, etc. As technical communicators, we have never had a clear, crisp definition of what our profession is and we have never wanted to be tied down by titles or be pigeon-holed when our responsibilities cover the spectrum of corporate duties related to creating and managing business-critical information. But as we journey deeper into what is being summarized as the Information Age, we should, as technical communicators, have some say in the direction that the information enterprise heads, and yet we hide behind old cliches and find excuses to avoid taking the helm. The plain fact is that information is not a static entity but a dynamic force and no one understands that better than those of us who work with it on a daily basis.


This treatise is an attempt to use the written medium, with which so many of us are so familiar, to face the fact that the future of our profession goes beyond this medium and that it is in our best interest to admit it and move on. This is not a pop-business book about the latest management strategy or corporate movement, but a carefully thought out estimation of what is the defining core of our profession. While many have spoken of technological trends or dismissed some technological advances as fads, the use and direction of the flow of information in and between enterprises is, for me, the most exciting profession in today’s world. As I have witnessed this growth through generations of technology, my vision of the transforming of communication (and the transformation of the enterprise by communication) is becoming clearer each day. It is this vision that I hope to share.


From my experience, the discussion of “single-sourcing” brings into the light several factors. Large chunks of this treatise will be dedicated to this discussion. To deliver information on the web both dynamically and in printable form, the databasing (or single-sourcing) of information must not be limited to the documentation team but must be in use by the entire enterprise and the tools for developing a large amount of that content (by full-time content developers) must be easy and quick (without the need for massive overhead for maintenance). While I am not offering any quick solutions to these, I think it is valuable for us to articulate the issues as we each face the challenge in our own corporate or academic setting.


It is becoming apparent that our profession is heading in the direction of treating content development as a transition to another stage. I encourage managers of departments and project leads to innovate with content development and delivery. Technical communicators are doing great work, but we are only beginning. What we are transitioning to may become clear as we dig into the discipline of technical communication. The first step is to learn what it is NOT and then begin to see that the real roots of technical communication lie not in delivering information from one party to another but in developing a kind of decision-making knowledge. But the story does not end there. For those of us who have worked for years with documentation and knowledge of this sort are beginning to see that what is called for is a democratization of information, a freeing of the constraints of knowledge in an enterprise that will have as much an impact on the structure and operation of the enterprise as political democracies have had on equally large social structures.


While not alive for the whole history of technical writing, I have been around for most changes. My career spans 20 years of some of the most dynamic years of the profession’s development. From the 1980s with advances in desktop publishing to the death of the plethora of dot coms in the 1990s to the wireless web of the present century. Perhaps the biggest trend that has not yet been articulated is that dynamic nature of information. Information changes and with it the profession that handles it. While the conclusions may sound philosophical, the beginning chapters, I hope, will present a clear and exciting picture of a profession that I have found rewarding and challenging.


The title of this treatise, in fact of this whole web site, “Transforming Communication”, reflects the two-way dynamic of the subject matter. Not only is business transforming the use technology and the way we communicate in business, but the way we communicate technical and business information for operational decisions is transforming the way we do business. Communications is transforming business and communications is being transformed. Management must admit the critical role played by technical communicators and technical communicators must be willing to change the way they do business based on new business realities.


Introduction


This chapter introduces the idea that technical communication is a profession and a discipline in its own right and that it must determine whether it will be part of the game or give the reigns of thought leadership to another group outside our profession.

Finding the Crossroads


Thought leadership in technical communication might seem like a straightforward thing, given that writing is seen as such a mundane task. But the distributed and dynamic nature of corporations (and corporate objectives) makes the task more complex. Add to that the misunderstanding of the true nature of communication by most corporate management and you have a very confusing state of affairs. The shrinking time scales of projects and the make-or-break position that some companies are in makes the task that much more critical. If the thought leadership is not going to come from the corporate management that seems to be calling the shots or from the IT arena that seems to claim expertise in everything technical or from academia that claims authoritative expertise about everything having to do with knowledge, then where will it come from. Strangely, it is going to come from people who do technical communication as a profession, who recognize its value and have an exciting story to tell.


Our profession is at a crossroads. We must decide where to go from here. Are we tied to the past or can we move forward? Will our profession stay rooted in the halls of academia or will it transform along with the rest of the business world? Will the professionals who offer the most expertise help steer the profession or will they along with the rest just wait to see what will happen? If we understood the goals of the profession, we would know which path to take. Recognizing the crossroads is the first step. In the 1980s when desktop publishing exploded on the scene, the Society of Technical Communication began a steady rise in membership that has not slowed until the late 1990s. As businesses begin to understand the Internet and move their businesses online, professional technical communicators wait and wonder, often confused by the dynamic nature of the business. Some are forced into the new paradigm as companies lay them off and they search for work and find it in small software startups. Some, in their quest for independence, discover telecommuting and realize how much work can be done online. No longer is it simply doing technical writing for a few dollars. Others are discovering our profession by coming from related professions, which becomes easier as the distinction between types of communication blur.


The distinction between content for training material and content for marketing collateral is blurring and the technical writer is asked to contribute to many types of publications. Information management is the latest catch-all phrase but it will change soon because it does not capture the dynamic nature of our field. The content in all its varied forms is boiled down to a common currency, information. And yet the developers of much of this information are some of the least paid and least respected in the organization. Often those in management turn to tools people, the IT department, to help sort out what to do with managing information. Unless the technical communicator can understand the vital role he or she plays in the changing theater of business, the profession will not progress. The first step is seeing the crossroads. Then it will be up to the professional to choose which of the paths is the most beneficial. For it is no longer the management of information per se, but the management of the flow of information that is critical to business. This second step, that of choosing the right path, is what this essay addresses.


Our insights are stolen or co-opted by other professions. IT personnel now push scenario-driven workflows in the 1990s when it was in the 1970s when technical communicators were writing about the same thing but called it user-centered task-orientation.

Clearing the Road Blocks


Choosing the right path would seem easy except, to continue the road analogy, the path is blocked. For visibility to be increased, the roadblocks must be removed. The real goals, the real core of technical communication as a profession, are little understood for three reasons. These are the three roadblocks


First, many have not made the shift to the new paradigm of the new information age where time is gone and the flow of information for making critical business decisions must be made timely. Never before has the slogan “time is money” had such relevance. The section Transformation of the Information Workplace is about the global changes we must acknowledge. These are not small changes like a new technology or a new business or a new tool. The entire way of seeing the world and way of carrying on business has changed and if we do not recognize it, we can go nowhere.


Second, the profession is too encumbered by its historical relationship to academic institutions that are steeped in the old paradigm, instead of to business, which is quicker at evolving. With their origin in academia and their continued association, many in the profession are afraid to step out and grab the baton and continue the race. The direction of technical communication is toward more complex relationships — relationships that are allowed in business but not well understood or encouraged by academia. The sooner we break those bonds, the sooner we can reestablish much needed newer ones that will help bolster our profession. This is described in Transformation of Knowledge Development.


Third, those who know most about the profession, those most in control of the future of the direction of the profession, just have not taken the time to do some serious planning as to how to develop the profession as a profession. Until we have real leadership in this profession and until we focus our vision, we will never be able to articulate its value and its authority. The direction we can take and how we can determine that direction are described in the section Management of Dynamic Information.


For those who want to see practical results and not just philosophical discussion, the appendixes offer concrete examples of what we could create.

Understanding the Contours


Another challenge is the shape of the road that changes daily. The subtleties of working in corporations include working with management that does not recognize the value we add by clarifying the process, by objectifying the creative outputs from development, or the small ways we help with communication at every level. In fact, at times management seems to want to withhold information and stifle the necessary flow of information. It is against this set of contours that we must travel in our career.


Thought leadership in technical communication might seem like a straightforward thing given that writing is seen as such a mundane task. But the distributed and dynamic nature of corporations makes the tasks of helping information to flow, of clarifying requirements, of making designs understandable that much more complex. The shrinking time scales of projects makes the task that much more critical.


Counterbalancing this is academia’s inability to change shape. Because of the prevalence of books about technical writing written by academicians, students have a skewed idea about the profession and executives underestimate the value afforded by those professionals. Somewhere between Web interfacing database designers and English grammar teacher, most are not sure what to do with technical communicators. Beyond the creation of user manuals, necessary in the 1970s and 1980s as technology became more complex faster than users could keep up and as audiences grew, both the software products and the automated hardware they found intellectual assets were at a premium. It is not just an IT issue of choosing the tool. Picking the authoring environment and online help tool is not the only deceision in solving info flow. You don’t just decide to have an intranet and then everyone communicates. But as long as technical communication professionals do not stand up to the task and communicate some real business decision rationales, then executives will simply delegate it to IT shops to provide a solution and the solution will be at best partial if all that is done is the purchase of expensive machines and software.

Facing the Combattants

[under construction]


Transforming the Information Workplace

This chapter is about the change in the workplace from the old system of manufacturing with clear distinctions between tasks and clear distinctions between jobs and the new system where old distinctions are blurring. Now even the place where work is done is not clearly defined as people take cell phones on the road and laptops into their bedrooms. This is the context in which technical communication finds itself.


Beyond Paper Platform


As technical communicators, much of our effort is spent working with documents, which is the way information flows in many institutions, and often those documents are on paper. Much has been written about the paperless office as a goal that was never achieved. But the goal of the paperless office was not to get rid of paper per se, as if project managers had an agenda against the lumber industry. There will be paper documents in use in the enterprise for many more generations. The goal was to overcome the limitations of paper in the enterprise. Now that we can communicate instantly and simultaneously with several people who may be geographically and even departmentally widely separated, we are discovering that paper, and even the document as a separate entity may be a thing of the past simply because it is too restrictive for the necessary communication. It is really the office-less office that was the goal, not the paperless office.


After the car was invented, it was called the horse-less carriage. It was difficult for people to change their image of transportation. The car is more than just a carriage without a horse. It can do more than move people. It provides the mechanism to move beyond the agrarian limitations of space. Now you can drive in a matter of days across a continent. And while it performs more efficiently, it also requires an infrastructure of gas stations and roads in order to really work well. In the same way, the network of computers does more than simply replace paper-based communications systems. The networked communication infrastructure does not simply make a paperless office, to use the metaphor of a previous age. It now makes possible the ability to communicate with all parts of an enterprise and destroy time. The goal was to free the decision maker’s need for timely information by replacing paper-published documents that could only exist in certain places at certain times. Now the flow of information to the community in the enterprise, the ultimate goal of communication, can occur instantly and the information can be available at all hours anywhere in the enterprise.


So besides overcoming the limitations of space by making the information available throughout the enterprise, the limitations of time are also overcome. Time to market is as important as product quality and product functionality. The pace of development of a product and the delivery of a solution is accelerating and the time of usage is shrinking as we obsolete our computer systems in shorter and shorter times.


The point of going online was not to get it to the computer as if computers were a much more impressive media than paper. It is not a high tech version of print media. Computers are not a new weapon in the paper-scissors-rock game, somewhere between scissors and rock. The now apparent goal is to get the information, whether it was documenting the code or summarizing the report of output data, closer to its source. If the computer program has a user manual, and the frequency of changes to the program increases faster than the updating of the hard copy manual, then one solution is to make the documentation effort more responsive to the changes by putting the documentation along with the code — put the electronic files in the same repository as the code or even embed it as comment lines in the code itself. Whether it is compiled online help that links to the program or comment lines that can be automatically extracted and reformatted for human reading, the goal is to get the information about the algorithm or about its use as close to the algorithm as possible. In other words, it makes maintenance, or what is today touted as management, of the documentation easier and cheaper.


The point is not that the document is replaced with some multimedia performance, as if adding sound or flashy graphics will make it work better. The importance of this new set of online communications is that is interactive in a way that previous single-media forms only approximate. The goal is to get the participant in training or the student in school or the prospective customer playing with a demo to interact so we can learn about customers, the uses of the product, retain more and really learn.


The goal with computer-based training is not that it is computer based as if the Luddite trainer is being replaced with a less expensive computer. The goal is not to replace the teacher but to replace the students who are sitting doing nothing by giving them all little teachers that can be rewinded or fast-forwarded at any pace and at any time. The goal is to put the information out there for you to access when you need it and thus to make it easier with which to interact.


Part of the new paradigm is a new way of businesses interacting with each other. No longer is a technical communicator working on one product for one company. The classic image of Kurt Vonnegut taking engineering notes written in jargon and gibberish and composing nice paragraphs explaining the usage of a single IBM computer was lost in the ‘60s. Today we write about a product that is then integrated into a larger system and another writer has to combine information. A third company sells the product and has to modify the documentation with their company image on it. The end user may be several people down a chain of resellers and planners and purchasers. A better description for the technical communicator would be one involved in the infrastructure of knowledge than as a writer of technical literature. And how the user interacts with the information may be very different from a person sitting reading a book.


The paradigm shift is not from hard copy to soft copy, it was away from paper documents that could only be read by humans one at a time to a medium that is always on and that allows machine processing as well as human reading simultaneously and at any time.


Also, here’s one small example of the direction that communication is becoming more interactivity that one-way communication. In the old days we had warnings, caution, and danger as admonishments that we used in our books as writers to readers. Now with computer documentation, you have information (click OK), warning (either click OK or cancel but something’s going to happen), or input (input a whole string and the system will act on it.)


———————————-


As technical communicators, much of our effort is working with documents, the way information flows in many institutions, and often those documents are on paper. Much has been written about the paperless office as a goal that was never achieved. But the goal of the paperless office was not to get rid of paper per se, as if technical communicators had an agenda against the lumber industry. There will be paper documents for many more generations. The goal was to overcome the limitations of paper in the enterprise. Now that we can communicate instantly and simultaneously with several people who may be geographically and even departmentally widely separated, we are discovering that paper, and even the document as a separate entity may be a thing of the past simply because it is too restrictive of the necessary communication. It’s really the office-less office that was the goal, not the paperless office.


After the car was invented, it was called the horse-less carriage. It is difficult for people to change their mindset. The car is more than just a carriage without a horse. It can do more than move people. It provides the mechanism to move beyond the agrarian limitations of space. Now you can drive in a matter of days across a continent. And while it performs more efficiently, it also requires an infrastructure of gas stations and roads in order to really work well. In the same way, the network of computers does more than simply replace paper-based communications systems. The networked communication infrastructure does not simply make a paperless office, to use the metaphor of a previous age. It now makes possible the ability to communicate with all parts of an enterprise and destroy time. The goal was to free the decision maker’s need for timely information by replacing paper-published documents that could only exist in certain places at certain times. Now the flow of information to the community in the enterprise, communication, can occur instantly and be available at all hours anywhere.


In this age, time is being destroyed. This is part of the paradigm shift. Time to market is as important as product quality and product functionality. Technical communicators better stop whining about not having enough time to properly document the product as if there ever was such a thing as a properly documented product. The pace of develop is accelerating and the time of usage is shrinking as we obsolete our computer systems in shorter and shorter times.


In the late 1980s there was talk in professional circles about technical writers becoming more like programmers as the documentation moved online (and thus closer to its source) and the distinction blurred between the disciplines of technical writing and programming. I really did not appreciate this direction because I had developed software myself early in my engineering career and I did not like doing it nor did I think it was something technical writers should have to start doing to do their job. But as the 1990s came and went, everyone began playing with the Internet and even programmers weren’t developing code as much as they were jerry-rigging previously created components to work together in a more object oriented framework. They were not so much writing linear algorithms in the language of the computer as they were having a dialog with the computer that was giving them as much code as they were themselves creating.


Again, the point of going online was not to get it to the computer as if computers were a much more impressive media than paper. It is not a high tech version of print media. Computers are not a new weapon in the paper-scissors-rock game, somewhere between scissors and rock. The now apparent goal is to get the information, whether it was documenting the code or summarizing the report of output data, closer to its source. If the computer program has a user manual, and the frequency of changes to the program increases faster than the updating of the hard copy manual, then one solution is to make the documentation effort more responsive to the changes by putting the documentation along with the code — put the electronic files in the same repository as the code or even embed it as comment lines in the code itself. Whether it is compiled online help that links to the program or comment lines that can be automatically extracted and reformatted for human reading, the goal is to get the information about the algorithm or about its use as close to the algorithm as possible. In other words, it makes maintenance, or what is today touted as management, of the documentation easier and cheaper.


Since I mentioned object oriented programming, and many have discussed whether the discipline of technical documentation, too, is tending toward modularization, let’s talk about that issue. Whether you think modularization is inevitable is another classic conundrum for technical communicators. As object orientation sweeps other disciplines, technical communicators coming at the discipline with a more liberal arts bent than the more geeky (more techy) programmers, resist the tendency to modularize even as they realize the pieces of their work (text and graphics) are being re-used in several disparate publications, both online and on paper. But before we delve into arguments about the value of tagging languages and metadocuments or the tactics of using a database for single-sourcing (really multiple-sinking, since information will always come from more than one source), we have to ask whether the information will really need to survive as long as these tools say it is possible to save it. While SGML was heralded as allowing us to keep information about complicated telecommunications equipment (for example) for 20 years, the entire industry was transforming itself into data communications and transforming its products in a span of only a few years. Suddenly, the equipment would obsolete before the documentation authoring tool was gone. Reversing the earlier trend, information does not need to be kept in archives for ever. As computing speeds increase technology is obsoleted faster and faster. While airplane, heavy equipment, and space stations still require documentation that will last as long as the equipment, there will be need for databased, machine independent information structures. But for all the years I have worked in industry, companies have played with tagging languages without making the commitment to have several departments commit to using a common database (datamine, datawarehouse) for information management. This is another indication (foreshadowing the discussion of a later chapter) that we do not take ownership of our profession to the extent that would ensure our success.


The reason is simple. To handle the acceleration, we can not stay anchored. We have to throw over the baggage that is slowing us down.


Beyond Appliance Analogy


To understand the paradigm shift you have to understand the steady growth of the technology from the computer as an appliance to the computer as a communications device to the computer network as the communications medium. In the ‘70s when personal computers were stand alone computers, they were like appliances. But now they are more like an outlet into the energy source. It is not how many programs you have on your hard drive, because the network has all the knowledge, has all the servers, has all the printers you could possibly need. What you need is access. I used to want my own computer, then I wanted a laptop so I could travel with my communications device, now I want to be able to access information where ever I go whether I have a device or not. With the rapid pace of change in the area of communications technology, it is access to the global wealth of information that is important, not the individual power of an isolated processor.


Gone is the individual as the major emphasis in our technical communication work. There will always be users of machinery and there will always be user centered task oriented user manuals. But there is a growing body of reference material or data that is better crunched by computers that read by human eyes. You see, the direction of the technology in support of the corporate structure is not to allow humans to buy books at amazon.com. The goal is not to simulate real book buying, but to take massive amounts of data and make them able to be rendered by other machines or data engines. Until technical communicators stop pretending that they are writing literature for individual human readers, we will never advance as a profession because we will ignore reason for our existence and continue to ignore our major impact on corporations and the source of our livelihood.


Beyond Multimedia Madness


The point is not that the document is replaced with some multimedia performance, as if adding sound or flashy graphics will make it work better. The importance of this new set of online communications is that is interactive in a way that previous single-media forms only approximate. The goal is to get the participant in training or the student in school or the prospective customer playing with a demo to interact so we can learn about customers, the uses of the product, retain more and really learn.


The goal with computer-based training is not that it is computer based as if the Luddite trainer is being replaced with a less expensive computer. The goal is not to replace the teacher but to replace the students who are sitting doing nothing by giving them all little teachers that can be rewinded or fast-forwarded at any pace and at any time. The goal is to put the information out there for you to access when you need it. To make it easier with which to interact.


Part of the new paradigm is a new way of businesses interacting with each other. No longer is a technical communicator working on one product for one company. The classic image of Kurt Vonnegut taking engineering notes written in jargon and gibberish and composing nice paragraphs explaining the usage of a single IBM computer was lost in the ‘60s. Today we write about a product that is then integrated into a larger system and another writer has to combine information. A third company sells the product and has to modify the documentation with their company image on it. The end user may be several people down a chain of resellers and planners and purchasers. A better description for the technical communicator would be one involved in the infrastructure of knowledge than as a writer of technical literature. And how the user interacts with the information may be very different from a person sitting reading a book.


The paradigm shift is not from hard copy to soft copy, it was away from paper documents that could only be read by humans one at a time to a medium that is always on and that allows machine processing as well as human reading simultaneously and at any time.


Also, here’s one small example of the direction that communication is becoming more interactivity that one-way communication. In the old days we had warnings, caution, and danger as admonishments that we used in our books as writers to readers. Now with computer documentation, you have information (click OK), warning (either click OK or cancel but something’s going to happen), or input (input a whole string and the system will act on it.)


Beyond Static Standards


There is no need to write about the direction of technical communication in the telecom industry. It is too common place, but there are some lessons to be learned about our profession that should be sorted out. First, there can be no single standard DTD because there is no single industry. It is away from monolithic standards but toward unwritten industry standards. It involves a change from single company industries, such as AT&T toward highly competitive market even with companies outside of telecommunications. There are cable companies and electrical utilities on one hand that have some form of wires going to everyone’s house and there are data communications companies expanding the connectivity at the other end. Industries are merging.


Second, there can be no single set of requirements only responses to customers. There is a move toward developing quality systems which simply are assuring that consistently delivered product or service that meets customer requirements at an appropriate time.


Third, there can be no single standard because content is king. Just as product determines all in the 70s, process determines all in the 80s, requirements determine all in the 90s. You can not have a standard on content because the content is changing with each release. Perhaps industry standards on process are the only that will work. Or industry standards on usability and emphasis on minimalism.


Finally, there is no need for TOPs now. First there was TOPs, then there was no TOPs, now there is the fulfillment of TOPs without TOPs. It was before its time with modularized procedural elements that predated SGML and the software databases to handle them. Now that databases are here, we don’t need TOPs.


Content as Product


History lesson.


First Telecom Deliverables: Product, Documentation, Training.


Now the deliverable is: product with integrated online help and online tutorials and a product that is itself becoming more information itself. Not just information driven, but information itself. Content is becoming part of the product.


No such thing as a business monopole except all of industry.


Setting up of the quality system assumes that you can allow the process to mature without it changing radically. It assumes that the delivery of the supplied goods requires that process.


It assumes a contract dipole. That is, there is no such thing as someone in business without customer and no customer without supplier. Buyer and supplier exist together as a yin yang duality and the process of communication between them becomes the focus. Now it is the information and confirmation of requirements that flows between them that becomes the source of wealth.


It’s (Already) All in your head


Even if you are not there yet in the development of the documents, you already are there with your handling of information that you organize in your head. There is a skill that technical writers have and it has nothing to do with the authoring tool for publishing. It has to do with creating a schema that others can use to organize in their heads and publishing that schema in a way, textually, graphically, whatever, that allows others besides the designer (notably the users) to make use of the design of the product. What distinguishes designers from the rest of us is there ability to form schema that allow them to design a product or system. What distinguishes technical communicators is that they can create a different schema, a user centered schema AND can convey that schema is a publishable, that is sharable, way. What distinguishes trainers is their ability to interface with humans and present that learnable schema, but more and more that schema in the domain of the technical communicator can either become the interface or integrated with the product so closely that it does not require a separate person to perform. So the skills of the technical writer involve manipulating language or whatever medium can be used convey schema, not just facts about the product, not just the technical jargon of the designer and their goal is not simply translating the schema into English but transforming the schema itself into a usable schema and then translating that into publishable form.


The discussions these days about telecommuting are another example of our failure to understand the direction of the profession. We argue about whether telecommuting is a movement that will be coming or not. We either say, look, every manager I’ve ever worked for has never let me telecommute, they always want the control of knowing where I am, or we site individuals who telecommute to disprove those who say it will never catch on. Of course, again, both parties are wrong and are arguing about the wrong thing. Telecommuting is not a myth, but it is also never going to be systematically implemented in a way that writers conceive of it today, nor should it. The fact is that so much of business is online and manager read their email at home and make decisions over the phone from other places than work. So in one sense, with the Internet available at cafes and in gas stations, more and more business is being transacted all over the place. Lots of businesses are now run out of peoples’ homes, many more are spread across cyberspace. The focus on telecommuting is misplaced and distracting. The real issue is the realization of telebusiness.


Another aspect of this is that technical communicators who should take control is that if they feel committed to telecommuting as a way of running a business, why not start a business or own a business and make it happen. Why is there a constant barrage of criticism about the cost effectiveness of telecommuting but these same writers do not run a business with it?


The group that formed to re-write the IEEE Std 1063 represented a diverse and distributed group of technical communicators who understood that a baseline or bare minimum of software documentation was essential for projects to succeed. The goal was not to form a complete description of all the documentation possibly used by all projects. The goal was not a universal catalog but rather to provide assistance to engineers and project managers who needed a place to start. Just as the electrical exists to ensure safety in house wiring, so this standard exists to make clear that if you try to develop software without these minimum standards of documentation, you do so at your own risk. With this standard, we re-wrote the requirements taking into account the new technological realities since the days of desktop publishing advanced and the Internet became not just another medium but the main medium.


During review of the sections of the document, we communicated almost entirely by email. Contributors created and shared drafts and exchanged comments electronically and posting of the assembled draft on the web made international access possible.


Transforming Knowledge Development


From Knowledge to Decisions


The problem with the research into technical writing is that it looks at individual humans instead of looking at the efficiencies to an organization. We go no where by looking at psycholinguistic results or cognitive human factors if we only use the insights for individual humans. The perfect example, seen all too often, is the research into which is better, online copy or hard copy, and then interview individual human participants about the speed of their retrieval information or understanding of content. The research fails to look at the organization’s ability to maintain information electronically, transmit and make available that information, and its ability to re-use the information when it is in that form.


Knowledge as a static entity, as a by-product of technology will always be secondary, will in fact decrease in value. What is needed and what technical communicators must create is knowing systems to help decision makers make decisions and gain ability to decide quickly. Information is the product, doesn’t mean that information is moving from documentation into the GUI though a good amount of it is. It means that decision making input is as important as the hardware sold in the brick and mortar businesses. Information, if seen as objective knowledge that can be objectified and thus separated from the action inherent in the use of technology, must be written in documents and stored in libraries. But if information is seen as fodder only for decision making and nearly disposable after consumption, the best way of managing it is for more democratized, more readily available, more modular and databased schemes. These are far closer to the solution than electronic books. It is not so much writing in the traditional sense but organizing machine understandable information . And the machine is not necessarily a human or even an individual computer but a corporate machine that has its own logic.


The letter to the editor of the IEEE PCS newsletter is so arrogant because it implies that we have never thought of these questions before and that these questions are so valuable. The fact is that we have thought of them before, but they are trivial questions that we have all asked the first day we were exposed to the technology. The fact is that the Internet is not just another media as in another way to display words and pictures. It is a conceptually different media as different from printed books as printed books are from oral speech. The important value of the web is not that it displays works or pictures on a screen, but that it makes the same information available instantly to the widest possible audience. Emails are not memos in electronic form; now they can be broadcast instantly to everyone in the company who can then use the information to make decisions and create other information. It was said more clearly by Chris Kowalchuk:


“…”true” writing is a more active, creative, synthetic process. A tech writer should probably have a bit of dirt under the fingernails from time to time…”


He came close to the point when he said that technical communicators offer value when they can minimize the time it takes to understand the content. But to take it a bit further, it is not just the time spent by the individual human reader, but the time taken by any part of the corporate structure in furthering the goals of the corporation. David W. Locke is right in saying that we reduce cost (something corporations want to do) and that it is not the production cost alone but the cost reduced by reducing the time spent in getting information from source to sink (often thought of as developer to end user) but he could go even farther and say that we align our behavior with the results desired by the enterprise. More modular information makes the move to online easier and even in some cases, in as much as it makes the information more easily accessible across an enterprise, motivates it. So much of technical communication theory to date addresses the writing, the creating of the text and the graphics as if the maintenance and distribution are secondary when in fact the delivery systems, as much as they are not only disseminating systems but digesting systems, are an essential part of the not only the process but the product.


Technical Writing as Context Communication


At the heart is the definition of the profession of technical communication. Just as medicine is healing people by curing illness (improving healthcare), just as engineering is controlling the external world to human ends (technical innovation), so technical communication is manipulating means of communication, most often written language to meet the needs of the context. For business, it is the ability to communicate business objectives, for research, it is the ability to put into writing the findings that should last until the next paradigm shift, for data communications, it is the ability to communicate vendor information to supplier and supplier requirements to vendor, and engineer to engineer or engineer to customer or engineer to management or customer to management. It is not one direction or one context, it is all these contexts, but it is one thing, it is the manipulation of the media to make the ends justify the means of communication.


The Third Leg


In the latter part of the 1900s, technical writers were seen as translators between technical subject matter experts, often programmers, and users of the product. But this is a limiting and limited role and shows that companies do not really understand the true value and actual role of the technical writer. Rather than standing between the two, they stand as a third independent leg of business trio — the third leg that is necessary for the stool, the business, to stand. A business needs to have the technical writer to stand apart as the third point in the triangle, the third leg of the stool, helping with communication between the two, but doing that by providing an objective, commonly understood language, establishing that communication independent of them both in order to objectively establish a business case that the rest of the enterprise can use. Yes, it is about satisfying the customer, but if what it takes is not objectively established, able to be understood by more than one developer and one customer at one time, then the work can not be organized completely, accomplished efficiently (and repeatedly ), and built upon.


Misapplied Awards


Like certification, the use of awards is an indication of our misplaced values. A real technical publication award, one that reflects what our profession is at its core, would not put so much emphasis on the appearance of the publication, though it is one important factor. Instead it would reflect success in such aspects as:


Whether the publication is available to its audience all the time, anywhere the audience needed it or wanted it.


Whether the publication could be maintained (managed) quickly and accurately without the department or company responsible having to bend over backwards to accomplish it.


Whether the business results (the payoff) was evident — whether that was a satisfied customer, or a flawless operation, or a savings in terms of effort of technical support.



Flow of Information


The marketing slogan I used in the first company I started was “Key Documents: unlock the flow of information”. It was a valid effort: unlock the data, the ability to let the information flow. Providing the missing piece that the IT department does not provide. Discover how to really manage and organize and make available the data needed for making crucial technical decisions. The IT department gives you the computers all networked and tools like email that work in that network, but if you can’t capture the data and make it accessible using these tools it is like having a truck with no key to start the engine. Or no map to know where to go. If technical communicators can not grasp their true calling and do the work necessary, the other professions will do it and get the credit and prestige that goes along with knowledge management in the information age.


“High performance access to remote users.”


That’s what I call infrastructure.


What, in technology, is not infrastructure?


I disagree with Donald Norman as much as he is an expert with how things work for individuals. He does not realize that corporations are successful when they can organize activities and information around corporate (group) structures that outperform individuals. Just as John Henry could beat the train but died trying, so individuals today scream that individuals are more important than corporations and yet give them all their power.


Our profession must grow. There must be steady growth commensurate with the growth of business. Not radical revolution, not slow evolution, but steady growth in keeping with the nature of the profession. The real industry of technical communication came after World War II (’50s)when mass production became mass design and mass education. As corporations grew bigger, the profession grew. But in the 60s, when more became mechanized, the profession changed. Editors and writers and publishers were no longer separate. Associations merged. In the 70s, we danced with universities and played with forming curriculum and programs in English departments. In the 80s, when desk top publishing, we burgeoned with people publishing and struggled to define ourselves. In the 1990s as companies merged, and more and more companies broke into pieces, as organizations flattened and cherished positions in telecommunications companies disappeared, as the nature of their business changed to data communications with the explosion of the use of the Internet, the role of the profession came into question as the associations became too big to change quickly.


Now as the new millenium begins, it is not about information as static but the flow of information, the movement of information that can sometimes have a very short life. It is no longer time to market, but the destruction of time. Internet time means no ordinary span of time any more — it means instant design and delivery and use and feedback.


Another aspect of the difficulty in claiming our profession is that historically it was the product engineer, the inventor of the product, who was the center of the intellectual property of the company. The rest of the organization was seen as support personnel for this genius. But as enterprises began to realize that technical communication, process automation, customer training, and quality management could all lead to major customer deals and major bottom line savings, they began to replace the engineer at the center with the engineers and the rest at the periphery. With the decentralization of intellectual power, technical communicators can claim their rightful ownership of an important part of the process of business. To do less is to give over the profession to those who will take the credit but deserve it less.


Some of the misunderstandings in our profession are made evident in the Management SIG (special interest group) of STC. First, some think that it has members of management involved in our profession. This is wrong. The most we have right now is project management and as organizations flatten, more senior technical writers become project leaders and handle project management issues.


Second, some think that you have to be a manager of people or of projects to be a member of the SIG.


Third, we limit our own progression in the profession by thinking that management is the only way to go. Unfortunately, in most big companies those that manage technical writers were never themselves technical writers. There is a lack of management in our profession and a lack of management of our profession. How many of us work for engineering managers or marketing communication managers and not technical documentation managers? How many of us are lone technical writers for small companies or small business units? In a small company, while having the title of manager, they are not executive management. Why are so many in leadership in the STC professionals with their own company? There is no vertical route for technical writers. There is no technical writing management. And while there is no representation in management there will not be any recognition of the value of the profession. Part of our goal will have to be to have technical communicator be a valid path up the career ladder. We can start by having a management track within corporations that get filled by technical writers who show skill in managing other writers. Another small step would be for organizations to offer a parallel track to senior writers besides management. With years of experience, a technical writer should have the opportunity to progress to higher technical levels of pay and responsibility. This technical track should be just as rewarding monetarily as the management track.


Third, just as companies are merging and becoming bigger, we may want to consider more mergers of professional associations. Merging STC with ASTD is a natural as technical writing and technical training professions merge. Merging STC with AIIM would be a good idea, since AIIM is very tools oriented and has allowed itself to become the defacto organization defining knowledge management and data warehousing when STC dropped the ball.


Great minds do not necessarily think alike. Great minds think together. By putting our heads together with a common mission we can solve the dilemma caused by staying with the status quo when the status quo limits us because it is the old way of working.


I do not know why management of people or of projects should be adverse to those in our profession any more than in other professions. To some extent doctors are not so much managed unless they work in a large hospital.


It is difficult to change. With the technology changing so rapidly, we are forced to change professions from writing about machines to writing with machines while in the same position in the enterprise. Though we return to the same workstation in the same cubicle, the workstation is networked, the applications on it are new, and the role we play just got more exciting and more challenging.


From Passive Communication to Active Objectification of Knowledge


It’s not that we’re writing down what exits; in fact, we’re writing down what doesn’t exits yet, except in someone’s mind and the value we bring is that we write it down AND thus bring it into existence. For corporate management to ignore this valuable function is to ignore our real role. We do not simply translate jargon into English, translate design information into customer-consumable documentation but bring into existence an objective statement of purpose that previously was imaginary.


Our professional association is weakened but our profession is not weakened by a lack of focus. In fact, if we had a clearly delineated focus we would be an engineering discipline and we are definitely not. Because we are our own profession, a craft involving writing and engineering and business, we need to find our own form of association.


Controlling Content: Intellectual Puberty


Making the information temporarily static — objectification.


There has been too much emphasis rules of formatting. For our profession, the goal is not WYSIWYG (what you see is what you get) though it has made desk top publishing so easy, but WYSIWIM (what you see is what I mean). Our primary focus should be to add meaning to the information, not just to pretty it up. If the information is legible, deliver it. If it needs white space, pictures, and glossy paper, so be it. But the core of our profession is to tackle the important issues about how information is systematized and articulated and how that communication can happen on corporate levels beyond individual readers’ consumption. Remember that someone has to develop ways to store information in digital form to be read by the widest audience and consumed the quickest to be successful. If we want to let another profession beat us to it, fine. But technical communicators are the closest to the goal; we just have to go the last few feet to reach it. The answer to storing information digitally (to make it available) is not simply a tools issue.


The first factor that is getting more visibility, which may be called the myth of single-sourcing, is that information is never coming from a single source within an enterprise. The approaches discussed so far deal with documentation efforts that assume that you can draw a line around all the created information (whether in a database or in documents) and from there, you assume that you are dealing with a single source. A more accurate name would be multiple-sink, because there are indeed multiple audiences and multiple outputs, but for my entire corporate life, I have never assumed that information comes from a single source. Whether it is content in technical notes created by developers or API documentation automatically generated from the code or overall product overviews developed by marketing engineers, there are plenty of sources of information that originate outside the documentation team and there is no sense re-fitting the information by our team so that it can be reused. As a department, we own a lot of the product content, but not all of it. The approach of re-using information and delivering it to multiple audiences or multiple outputs is a good idea but it must address the issue that information is distributed throughout an enterprise and perhaps the name single-source limits our dealing with the challenges of information flow by thinking only of the content we have created.


The second factor that is more obvious to me every day is the lack of a content development environment for authors of content that would be similar to the unified toolset used by programmers when they develop code. Within a single application they can edit, compile, and build the software, find bugs, add comments, and more. They do not need to load three or four applications and convert files between them. Most technical communicators struggle to create content in FrameMaker or MS Word, use RoboHelp or ForeHelp to create online help, use DreamWeaver or GoLive for web pages, or use Quadralay WebWorks to bridge some of the gap between FrameMaker and online help or HTML, but there is no single environment. As we recognize the need for a single database, as we struggle with larger amounts of content and shrinking time to market, there is a real need for a single content development environment and I am really surprised that the market has not delivered one.


From Outlining to Onlining


As technical writers, we like to focus on what we are good at – at composition, at developing prose, at writing – especially when we want to distinguish ourselves from the engineers around us and when we get defensive about the value we provide to the enterprise. But writing is a small part of our task and becoming smaller. At least, in the traditional sense, the task of writing is becoming a smaller part of what we are doing.


Another area where academia does not help is its application of writing discipline like outlining.


The problem is that the subject matter often does not exist beforehand. At school you could make an outline because all the info was there. In computer software, the development is occurring in real time. In her defense though, software is software and you need to cover standard topics like installation, getting started, etc. To ignore these outlines would be inefficient but to assume that you can know everything before the software is finished (and it never is) is foolish. It’s this tendency toward academic behavior.

Working iteratively is more the technical writer’s behavior.


From Planning to Purposing


Another area where academia travels a different route is usability testing research. Usability will be a top priority if users can not get information they will go elsewhere but at the same time usability research will under go as dramatic a shift as the technology has gone. We no longer have the luxury of usability tests of documents because the time to market has shrunk so much and the rate of change of technology is such that traditional manuals are obsolete by the time they are printed. Electronic documents (on the web for example) are only valid until next month’s changes require updating that information. IN a sense the new paradigm shift requires moving from traditional documents to information databases. Now verification testing during development replaces after-the-fact usability testing.


The problem is not that we want to be involved with user interface, it’s that we say we want to be more responsible for the user interface, but do not take the responsibility for it to the extent that would let us be more involved. We shrink into the easier discussions of usability after the fact as a way out of what we should be doing.


And again, the reason this misses the mark, is that it focuses on the human use instead of the corporate use, the use by the technology that thrives on information. This is a case not of knowledge for the growth of an individual mind, not what a individual human would learn, but decision support answers that help humans make answers in the service of corporate objectives.


Ed Weiss started the argument in The Retreat from Usability: User Documentation in the Post-Usability Era. But he was still talking about user documentation and he did not call it a transformation as much as an elimination of user documentation. But we know the reverse is true. But his points about usability are correct. The interfaces have grown more complicated, more limiting, more confusing.


And beyond usability, is the whole area of planning. Project management is a farce, if you will, because no one starts a project from scratch and has the time to plan. Rather, work is inherited in mid-stream; products are under development then moved into production and documentation is necessary to make it happen. But there is no up-front planning of the product, and none for the documentation.


From Coursework to Collaboration


Somebody’s catching on. But not entirely. But it’s a start. “Below is a description of the July/August issue of The Technology Source, a free refereed Web periodical at http://horizon.unc.edu/TS. Ready for a ride into the future? Alan Cummings takes his imagination to 2020 in this issue’s Vision article and predicts that, by that year, the worlds of business and education will have merged. Students older than 10 will study at home with teleconferencing tools provided by corporate sponsors and learning packages designed by education brokers. Parents will update their job skills with online training software and consult employment brokers for professional planning. In the business-oriented culture of the twenty-first century, qualifications will matter greatly; social status, age, and gender will count for little; and actual performance will be everything. Could it really happen? Cummings says yes and offers readers a fascinating scenario of the future.


In the July/August Commentary, Charles Morrissey argues that higher education administrators should take a close look at the corporate world, where virtual work-teams of employees are now collaborating and problem-solving online. “The field of professional education,” he writes, “would do well to develop an educational equivalent to the virtual workplace.” Specifically, Morrissey suggests that colleges and universities establish what he calls a Virtual Knowledge Network: a continuous, online learning spectrum where faculty, students, alumni, and community members can interact to the benefit of all. Read on to learn how a Virtual Knowledge Network could propel your institution into the twenty-first century.”


There is a need in this profession for the articulation of the collaborative aspects of the discipline. How was collaboration achieved and what results came? How did you, as project leader, build a team? What organizational structure was involved?



From Audience to Automation


Audience Analysis


The article by Dr. Jean-Luc Doumont about secondary audience misses a valuable point. The Harry Potter novels reach beyond a primary audience of kids by reaching a secondary audience of adults. His article discusses secondary audience trivially as those who have not read the first novel, but start with the second in the series. While it could be argued that people of all ages enjoy reading JK Rowlings books, I would not have read the books apart from my son’s interest in them. Doumont would have made a better example of secondary audience by mentioning the parents who read along with their kids. This is a more applicable analogy for technical documentation because it addresses a completely different type of reader. In this analogy, the parent or adult reader as secondary audience is analogous to management (or at least system administrators or advanced users) where end-users or technical readers may be the primary audience. To reach both, or at least to offer both some valuable information, in a single document is the real challenge.


We do not adapt to our audience so much as we reach our audience. Technical communication is, at its core, reaching its intended audience with technical information so that it can decide or act. In the recent past, when division of labor was more the norm inside an organization, the single audience was easier to target. Now with blurred distinctions and fewer people taking on more responsibility, the technical communicator must either set the context of the information to allow viewing by multiple audiences or deliver content in modules that can be packaged differently depending on the audience.


It’s not that subject matter experts cannot translate their jargon into lay terms – most technical documentation is not for lay audiences; it’s that subject matter experts are experts in their subject, not in communicating. It is the technical communicator who must not just advocate for the user (the consumer of the content) but must arbitrate and thus create a document that both the expert (producer) and user (consumer) can agree upon. Our job is not to hold the interest of anyone but to develop only the information that is essential for the decision or act that must be made or done.


Computer as Audience


The reason modules of information (instead of books of paragraphs) is becoming more the trend is not because we are getting lost or distracted by machinery and sophisticated tools as authors but because our audience is becoming increasingly not just humans but computers (namely search engines) and many parts of corporations or extended enterprises that is in itself a sort of machinery. Gone are the days of writers writing for individual readers.


The chapter about the differences in tech comm and traditional writing must include “creating modules” or “developing info” as opposed to “writing text”.

The first factor that is getting more visibility, which may be called the myth of single-sourcing, is that information is never coming from a single source within an enterprise. The approaches discussed so far deal with documentation efforts that assume that you can draw a line around all the created information (whether in a database or in documents) and from there, you assume that you are dealing with a single source. A more accurate name would be multiple-sink, because there are indeed multiple audiences and multiple outputs, but for my entire corporate life, I have never assumed that information comes from a single source. Whether it is content in technical notes created by developers or API documentation automatically generated from the code or overall product overviews developed by marketing engineers, there are plenty of sources of information that originate outside the documentation team and there is no sense re-fitting the information by our team so that it can be reused. As a department, we own a lot of the product content, but not all of it. The approach of re-using information and delivering it to multiple audiences or multiple outputs is a good idea but it must address the issue that information is distributed throughout an enterprise and perhaps the name single-source limits our dealing with the challenges of information flow by thinking only of the content we have created.


The second factor that is more obvious to me every day is the lack of a content development environment for authors of content that would be similar to the unified toolset used by programmers when they develop code. Within a single application they can edit, compile, and build the software, find bugs, add comments, and more. They do not need to load three or four applications and convert files between them. Most technical communicators struggle to create content in FrameMaker or MS Word, use RoboHelp or ForeHelp to create online help, use DreamWeaver or GoLive for web pages, or use Quadralay WebWorks to bridge some of the gap between FrameMaker and online help or HTML, but there is no single environment. As we recognize the need for a single database, as we struggle with larger amounts of content and shrinking time to market, there is a real need for a single content development environment and I am really surprised that the market has not delivered one.



The crux of the transformation is the shift from hierarchically ordered outlined knowledge as if arranged by an autocrat or king or emperor or point-power-source who knew how the information should be arranged to decentralized information that can be arranged more democratically. Each module becomes more separate and equal. The move to modularity is not just chopping information into bite size chunks for our human short term memory, but to more independently arrangeable information chunks that can begin to decide on their own how they will be arranged. Those in the old paradigm shout “Oh, no, chaos would ensue if no one is in charge, if no order is imposed” but those in the new system know that it works, that it does not lead to chaos. In fact, it leads to a higher (longer maintainable) order.


It is not just online, not just modules, for the sake of computers or for the sake of modules, but separation of the particles of information for higher freedom and higher order.


From Reading to Reason


Technical communication, in the final analysis, is really based on our abiility to objectively represent the product or service or items of business. The user manual or demo is a way to make real to a customer the otherwise ephemeral software product, for example. It is almost that we create the vehicle of communication, not just translate designers’ ideas to customers. Like a legal contract between two parties, the objective representation created by the technical communicator makes it possible for the two (or more) ends of a technical process to agree on a use of the product. Whether architect to developer or developer to tester or developer to end-user or management to labor or management to customer, the objective representation becomes the key to communication. It is the reason for the communication. The act of articulating is necessary for this to work — not just communicating in the sense of talking from one to another, but objectifying so that there is something that can now be communicated where before was only idea. The key skill is not writing (or creating something to read) per se but objectifying (of creating something that can then be agreed upon.) Articulation may be in words or pictures or sequence of any of these. It may be online or hard copy, it may be plans of the future or diagrams of how something works. But it is creating the objective thing that can then be communicated that is the reason for the profession. If you do not know how to create a document, then all the writing skills in the world will not make you a technical communicator.


Freeing Dynamic Key Content


[This chapter needs to be edited and reorganized.] This chapter is about the necessity of technical communication in the corporate enterprise and the ultimate political ramifications of allowing content to organize itself. It is about applying what we have learned in the previous chapters and it begins with understanding the collaborative enemies of the technical communication profession.




  • Part of academia who lives in the past and develops arcane terminology to describe unreal experience and is not interested in defining the existing discipline that crosses the territorial boundaries of English and Engineering.

  • Consultants who want to keep it all a secret craft so they can keep their fees high and their expertise marketable.

  • IT departments who do not have a clue about the true nature of human communication and are often given free reign to simply apply technology rather than solve underlying problems.

  • Corporate management (from software development managers to executive management) who gain power in the organization by hiding information in order to be able to make decisions, rather than by sharing information which would share power.



Adjusting Academia


[under construction]

Self Management, Self Training


In a corporate environment that does not offer training and education in the traditional sense, because traditional education is gone, the tech comm professional must find his or her own training. And tech comm professionals are uniquely suited to fill that gap by offering to manage their own projects, their own careers, and offer their own training to each other.



Curtailing Consultants


[under construction]


Crafting Certification: Which Skills


Certification is an issue because we do not know how to develop or mature as a profession without saying that we can do a skill and we do not know how to measure our abilities in the information age so we keep using old academic models: written tests. Sigh. It is not about writing alone. It is about realizing what role we play in corporations and proving ourselves. I am not against certification per se because I prefer it to doing nothing, and I prefer it to stressing university academic rigmarole. But certification is not the answer for a profession that is banging around in the dark.


Just because the entire field is diverse should not preclude certifying a subset of the profession. Not all people in the healthcare industry are medical doctors, and medical doctors are not expert in all areas of healthcare, but they are the vanguard of that profession.


Just because a certification is a piece of paper does not mean that it will replace writing samples, portfolios, oral interviews, or become the only measure of skill level. Just because some people look good on paper but do not perform well, does not mean the profession should avoid certification altogether.


If you do not think that good technical writing can be as life critical as a doctor’s work, you have not read user manuals for critical, medical, or very dangerous equipment. If you think certification is not a good idea, you are too late. Already editors, training professionals, web design professionals, already have certification programs. We can not go back.


Yes the tools of the trade are constantly changing; they are for engineers too, but a profession is not limited to its use of tools. There is a body of knowledge about technical communication but it has not been captured by academia yet. Only as the


“When two people disagree, they are probably both wrong.”, I think was said by Albert Einstein, but I am sure he was not the first. On the issue of certification there are those who would restrict the membership in the club to those who can pass a certain test: those are the elitists and they believe the answer is the answer is certification.


Then there are those who would never limit a description of our skills and an understanding of our profession to a few multiple choice questions because writing is, to the artistes, an art form, a trade that is either passed on genetically or through experience but cannot be measured.


Both are wrong because for the elitists the goal should be to improve the profession not exclude undesirables, and for the artistes, they must understand that the test is not to encapsulate the knowledge of our skill.


The value of having certification – of giving a test and awarding a professional ranking based on those tested skills – is of value in a world with no bearings. A certification program does not determine what technical communication is about, rather it determines who will establish what technical communication is about. Just as a medical doctor (MD) or a professional engineer (PE) takes a test and just as that test is not really what that professional does on the job, not what they actually do, but it determines who gets to determine their profession. By nature of the MD certificate awarded to the healthcare professional, she is then given the credentials (is pronounced an expert) to establish what healthcare is.


Academic credentials is a first step, but the avante garde of technical writing is not in academia, but in the work force. In a previous section we saw how outdated and un-uniform the university curriculum are. If academia can not provide the gauging system, then professional certification is one possibility. It really should be desirable by those in the profession as a way of discerning quickly in a short hand way if someone else is also in our professional community. It should build community not destroy it. But the point is not the contents of the test but that we agree to have a test. And the point is not just giving a test or getting a certificate, but defining a profession. If STC is not up for the challenge, then leave them. Some group of professionals will establish certification or guidelines or standards or some measure. I would rather it be us.


Intervening IT



Managing Management


[under construction]

Befriending Management: Showing Value


[More to come.]


Beyond the democratization of information — documentation must server a business purpose.


Recognizing the Value: Assets that Flow


Building an Information Infrastructure


So what does a corporation do to make use of the dynamic nature of key content? First, it values information and information flow as an asset and then it puts in place an infrasture that more readily shares the information across the information. This goes against so much of corporate hierarchy that has bolstered its higher positions with NOT sharing information. But just as democracies replaced oligarchies in Europe in the previous millenium, so corporations this millenium will face democratization of information across corporations.


Managing the Unmanagable


Proposed Curriculum


We are not easily categorized as a profession. Am I a technical person working as a writer or a literary person with an engineering degree. Both. There is often a gulf between the profession of engineers and that of writers but our primary value is not bridging a gap between them but doing deeper to fulfill both. Expressing the objective reality introduced by engineers (as well as remaining aware that it is a design of the artificial) and giving writers something about which to write (as well as showing the power of their articulation skills.) This is no mere rhetorical exercise. We are neither technical ONLY nor writer ONLY. We are both. Not just interdisciplinary but supradisciplinary. It is a discipline of its own but it overlaps both.


The problem is kept exasparated by university programs that relegate the courses on tech comm to either the English department (with the emphasis on writing) or to the Engineering dept (with the emphasis on technical nature of the subject). The solution is to offer the courses through the business school as an information development curriculum, recognizing that the essential factor is one of business.


As an example of how far afield the current offerings are at universities and colleges, allow me to propose what could be considered a university curriculum that should be standardized and would be more relevant to the community of technical communication. Notice how different this is from any existing curriculum and notice how it would probably not fit within the existing structure of English departments of those institutions. At the same time it would not fit well in any Engineering school either. Perhaps the only place where it could be taught, if at all in universities, would be the business school.


How can academics theorize and write about something that is at the heart of business? To do so, you must understand business — you must appreciate that business has its own reason for being. Technical communication can not be considered in isolation from business objectives. Without the business context, it is nothing.


In the information age, information is not the latest commodity, it is the new form of currency. But information is not a currency in the same way as money was a currency for value. You do not keep it in the bank but give access to it to the largest number of users.


Information management is a curious phrase because looking at our current predicament, it is not clear if we are managing the information or if the information is managing us. The most valuable way to view our profession is to say that information is the key to understanding how management can function in the enterprise of the next century. Information is not data to hoard in bigger data warehouses or deeper in data mines; rather, it is decision-making currency that must be accessible instantly from any location at any time.

© 2004-2011 Bill Albing

Leave a Reply

Your email address will not be published. Required fields are marked *