Tech Comm 2.0: Reinventing Our Relevance in the 2000s

By Jack Molisani | Fellow and Scott Abel

Authors’ Note: This article was written by U.S.–based members and cites examples from U.S.–based companies, but the problems and solutions presented apply to all STC members, no matter your country of residence. This work is the sole opinion of the authors, who do not necessarily speak for the Intercom staff, the STC Board of Directors, or the Society as a whole.

The technical communication field is experiencing big changes. Some of the changes are very exciting; others downright frightening.

You’ve likely heard about some of the exciting ones: XML authoring, socially enabled documentation, video documentation, eBooks, tablet computing, even augmented reality—cool technologies providing new opportunities for technical communicators who take the initiative to learn in-demand skills and market themselves in new ways.

Perhaps you have also seen—and chosen to ignore—the gradual, imminent, frightening changes that are doing the most damage to our place in industry: the commoditization of technical writing.

Change Is Inevitable

It’s always been our responsibility to learn new technologies, adopt new publishing tools, and master new approaches. But until fairly recently, the fundamental role of the technical communicator hadn’t really changed all that much.

The rise of developing nations like India (combined with the almost brutal slashing of development budgets in the United States) is responsible for many of the drastic changes that are occurring.

In an increasing number of organizations, technical writing is viewed as little more than a commodity—a service to be acquired for the lowest possible price given an acceptable level of quality. Gone are the days when a company will pay $85+/hour for a tech writer to document the fields in a computer program (such as “Enter your name in the Name field”) when someone in a developing country will do the same work for $6/hour.

And who can blame companies for seeking the best bang for their content-development buck? Offshore writers are quite capable of creating the technical communication most consumers are accustomed to today. If a writer has graduated from most any university on the planet, it’s likely they can author step-by-step procedures complete with beautiful bulleted and numbered lists, following a basic template structure in Microsoft Word. There’s no special (marketable) advanced skills required for such jobs.

“We’re still placing technical writers,” says Kelli Lawless, account manager at Content Rules, a U.S.–based firm that provides content development resources to organizations that need them. “But, the content development professionals most in demand—the ones getting snapped up most quickly, and the ones commanding the highest wages—tend to be specialists.” Lawless says her clients are looking for technical communicators who have experience and skills necessary to create interactive content for mobile apps, document complex application programming interfaces (APIs), and software development kits (SDKs). “There’s also a need for technical marketing communicators—workers who straddle technical communication and traditional marketing roles to create high value content like white papers, strategy pieces, software demonstrations and simulations, video documentation, and training materials.”

“What we’re not seeing,” says Lawless, “is a lot of people asking for print or traditional documentation anymore. It’s not a growth area.”

Joan Lasselle, president of Lasselle-Ramsay, a professional services company that helps clients connect with customers using content, agrees. “Our clients are not calling us and asking for five writers. They used to. But, those days are, for the most part, over. Today our clients are asking us for technical expertise—for help automating manual content production processes, incorporating video into their content offerings, and moving their content onto mobile devices.”

Lasselle says writing is perceived by many today as an easy-to-obtain commodity. To be successful, technical communication professionals must present themselves in a way that clearly describes the value they bring to organizations. Companies need information architects, content strategists, publishing process engineers, content marketers, social media and online community managers. Many technical communicators have the skills to fulfill these roles. What many lack, however, is the insight needed to take advantage of the many opportunities available to them—opportunities that allow for personal and professional growth.

“In many instances, you are better off if you don’t market yourself as a writer,” Lasselle says. “Writing isn’t a special skill that’s in demand. If you’re able to leverage your skills and position yourself as a provider of value, you can add $50, $100, or even more to your hourly rate.”

The question we are asking today is: why are so many technical communicators preoccupied with attempting to maintain the status quo? Put another way, why are technical communicators continuing to focus primarily on writing, grammar, and punctuation? And, by extension, why aren’t technical communicators taking advantage of the many opportunities available to them if only they would step outside their comfort zones?

We believe we know why and what to do next.

SWOT Analysis

An effective method for determining where a person or organization can expand their sphere of influence is by doing a SWOT analysis: Strengths, Weaknesses, Opportunities, and Threats.

We’ve already mentioned threats (commoditization of technical writing), so let’s do an honest inventory of our core competencies (Strengths), but also areas where technical communicators as a whole could do better (Weaknesses).

One challenge in assessing the strengths and weaknesses of a “typical” technical writer is that technical communication as a profession is as diverse as the types of fish in the sea. But while there may be huge differences between seahorses and sharks, both have fins for swimming, gills for breathing, and a mouth for eating.

Just as there are commonalities between the broad spectrum of fish, so are there commonalities across the broad spectrum of technical communicators. In an attempt to list the core competencies common to most technical communication roles, we looked for commonalities across many types of roles in our industry. The tool we used was the content development lifecycle, identifying which skills are needed at various stages of the lifecycle. (For more information on the content development lifecycle, see Jack Molisani’s article, “Creating a 3D Model of the Content Development Lifecycle,” Intercom June 2011.)

As we compiled our list, certain skills (detailed below) appeared more often than others.

Critical-Thinking Skills

Did you notice that the first skill identified is not “writes well”? Because technical communicators do so much more than writing, “writes well” falls closer to the end of this list, later in the content development. But each phase of a technical communication project requires critical-thinking skills.

What do our customers need? What type of user assistance would best meet their needs? What is the best solution given the resources we have available? What is the best solution given the time we have available? How will we make such determinations? How will we test our assumptions? What is our strategy for success? Technical communicators dissect a project into its component parts, think hierarchically, evaluate what’s important (and what’s not), evaluate problems (and offer solutions), and measure the outcome of our efforts. These abilities are what make us so valuable. Critical thinking is required in almost everything we do.

Problem-Solving Skills

While problem solving certainly requires critical-thinking skills, we felt problem solving is sufficiently important to list as a discrete skill. Why? Because everything we do as technical communicators is done (to a greater or lesser degree) to solve a business problem.

Face it, there is not one organization in the history of man that has hired a technical communicator because it had gobs and gobs of money with which it didn’t know what to do. No, organizations hire technical communicators because they have business problems that need solving. Perhaps a company needs someone to write a user manual. Why do they need a user manual? Because their customers can’t figure out how to use their product without one. Why can’t customers use the product without assistance? Because the product is hard to use, which frustrates customers and often causes them to call technical support. Of course, that is actually two problems: the product is hard to use and the company is spending money on technical support costs (although, they may be able to recoup that cost if they charge for support). But how long will they retain customers if the product is that hard to use? And, while no one likes to seek help from technical support, they likely enjoying paying for it even less.

While doing the analysis for this article, we were surprised at just how ubiquitous problem solving was in the content development lifecycle. Consider all the levels or types of problem solving we do:

• What problem(s) is the user is experiencing?
• What problem(s) is the company experiencing?
• What problem(s) is your boss experiencing?
• What development problems are you experiencing?
• What are your budget limitations?
• What are your schedule limitations?
• What are your authoring tool limitations?

While the number and type of problems may be endless, so are the number of solutions and ways that you can become the “problem solver” for your company.

Project-Management Skills

All phases of the content development lifecycle require project-management skills to a greater or lesser degree. At the beginning of a project, one must create a project plan (define the deliverables, project schedules, timelines, etc.). But technical communicators also have to be masters of their own time by planning daily activities, prioritizing tasks, coordinating schedules, etc.

Collaboration Skills

Contrary to what some might think, technical communicators do not sit in dark cubicles creating information in a lonely void of outside input. Rather, we work with subject matter experts, other communicators, graphics designers, editors, testers, support personnel, trainers, subject matter experts, and customers (just to name a few). We follow standards and best practices. We wrangle input from developers and provide suggestions to the user interface designers (the UI for both the product and the content). We work with software engineers in India and marketing teams in Europe and support technicians worldwide.

To do well in a global economy, collaboration skills are a must.

Communication Skills

Finally, we get to the writing! But notice we didn’t say writing skills, we said communication skills. Gone are the days of delivering user assistance solely in the form of text, especially printed user manuals. Today, users want us to help them overcome challenges by providing them with content targeted to their specific needs, formatted to work on the device they are using when they determine they need assistance. Will there be user manuals for the foreseeable future? Absolutely. But just as absolutely will be the need for other forms of user assistance, such as online help, embedded help, how-to videos, animation, eBooks, enhanced eBooks, apps, augmented reality—the works! As professional communicators, we must look at how best to communicate to our target audience.

Chances are, it won’t be solely via writing in the future.

Technical Communication as a Profession

So let’s take this list of core competencies (critical thinking, problem solving, project management, collaboration, communication) and see where else you can make a difference in your organization (the Opportunities in our SWOT analysis).

When we started this article, we evaluated which skills were needed in the content development lifecycle. Then we took a broader view and evaluated the product development lifecycle, what it takes to build a product—any product—and identified the roles involved:

• Product Manager—A product manager identifies a customer need that can be solved by a new product or by an enhancement to an existing product. Once the product is approved, they manage the development process.
• Business Analyst—An analyst investigates the idea, performs a needs analysis, and defines user requirements.
• Product Architects—An architect (software architect, building architect, etc.) designs a product that will solve the customer’s need and communicates that architecture in a design document.
• Designers—User interface designers specify what the user interface will look like.
• Usability Specialists—Usability professionals evaluate designs and suggest ways to make products easier for customers to use. They also work to ensure products aren’t overly complicated and that learning to use them is as easy as possible. They focus on developing a deep understanding of customer needs and applying their skills to all customer-facing interfaces (the product, the documentation, training, support website, etc.).
• Accessibility Specialists—Accessibility professionals make sure the product, the documentation, training, support website, etc., are usable by customers with special needs (vision impaired, hearing impaired, elderly users, etc.) and complies with accessibility guidelines and legal and regulatory accessibility requirements.
• Product Development—Engineers and other development processionals build the product.
• Content Strategists—Part content professional, part business management expert, content strategists help the organization identify how to best utilize its resources (human, technological, financial, and otherwise) to efficiently and effectively create, manage, and deliver all product content in accordance with defined goals.
• Content Development—Content professionals of various types (writers, illustrators, instructional designers) design and develop product content (embedded user assistance, user manuals, assembly instructions, maintenance instructions, repair guides, tutorials, demonstrations, simulations, etc.). These tasks are often performed in parallel with product development. Deliverables include a wide variety of information products in an increasing array of formats (text, audio, video, multimedia, interactive media).
• Trainers—Training professionals educate others. They transfer knowledge to both internal and external audiences and work with a wide variety of information products (demonstrations, simulations, assessments). They may deliver training in-person, onsite, or remotely. Increasingly, they are tasked with delivering training and other educational events via the Web.
• Testers—Testers assure the quality of the product and the content supplied to those who will use it, as well as those who train others how to use it.
• CM and Deployment—Configuration managers maintain build iterations (versions of the product as it is developed) and coordinate deploying/shipping the final product.
• Manufacturers—If the product is hardware, the completed design is sent to a manufacturer to be built.
• Project Managers—Project managers coordinate the entire development process and aim to keep the project on time and on budget.
• Marketers—Advertising, marketing, and public relation professionals promote the new product and the company as a whole.
• Sales Reps—Sales representatives sell the product to customers or customers buy it directly.
• Tech Support—Support professionals service new and existing customers.

Lather, Rinse, Repeat

As it turns out, many of the skills needed to perform roles across the product development lifecycle can be done by people with the same core competencies that technical communicators possess.

So why aren’t more technical communication professionals performing these roles? Perhaps because many in our industry lack a broader understanding of production problems and real-world experience in overcoming them.

As a discipline, we have well-established practices for information development that could make us valuable players in the product development lifecycle. Unfortunately, most people involved in product development aren’t aware of our skills, abilities, and areas of specialty. They don’t know we are able to work small miracles with impossible deadlines, curate content from complex sources, visualize information sets, and improve the user experience, while also spotting and mitigating challenges that could negatively impact the development process.

They have no idea we understand usability, readability, findability, translatability, reusability, searchability, accessibility, project management, time management, quality management—all of which directly impacts an organization’s bottom line. And why don’t they know? Because we keep labeling ourselves as “writers.”

By identifying ourselves as writers, we prevent others from instantly recognizing the value we add to organizations. While even we (the authors) disagree on how, exactly, we should identify ourselves, it is clear that many (if not most) people outside our profession have a preconceived negative notion of what writers do and (consequently) what little value we add.

For example, iFixit.com is an eCommerce site that sells tools and parts that do-it-yourselfers need to repair consumer electronics that malfunction or break. To sell their wares (replacement parts), the company offers customers free, easy-to-understand, graphically rich repair procedures.

When the company launched it’s Web-based service, they decided that traditional technical-writing approaches weren’t a good match for the task at hand (producing easy-to-understand, graphically rich repair procedures) and thus didn’t use traditional technical-writing approaches to develop the content. Instead, they took advantage of communication professionals with strong graphic design and Web communication skills, and leveraged the knowledge and experience of professional photographers.

“No one wants to spend time reading blocks of text, which is what a traditional approach to documenting products and services would have led us to do,” says Eric Doster, marketing director for iFixit.com. “We knew we had to be visually appealing and concise in order to attract and engage the community we hoped to build.”

iFixit.com did that by graphically presenting the repair procedure in bite-sized bits, each step illustrated by a photo. The photos are the dominant information element; text is only used to provide supporting information. And all of the content is created in accordance with a new XML standard, oManual, which makes it possible for the content to be automatically formatted for use on smartphones and to mobile devices like the iPad.

“We use and value traditional technical communication skills, but we leverage them in different ways,” Doster says. “To overcome our challenge, we had to step outside the technical writing box and allow ourselves to think differently about communicating technical information. And, as it turns out, that’s exactly what led to our success.”

Is what they did technical communication? Yes. Did they use “pure play” technical writers to do it? No. Why? Because technical writers only write.

The Upshot

If we (the authors) had our way, we would change the name of our professional society from “The Society for Technical Communication” to “The Society for Solvers of Content-Related Business Problems.”

We understand some in the Society might resist that initiative, so let us also offer an easier and more to-the-point suggestion: Stop calling yourself a “technical writer”!

Increase your sphere of influence. Seek out problems in your organization and leverage your core competencies to fix them. Then make damn sure management is aware of the value you add. Stop whining about how our profession is not respected. The only way to elevate the reputation of our profession as a whole is to elevate our reputations as individual contributors, each and every one of us.

Ready?

Start!

Recommended Reading

The World is Flat by Thomas L. Friedman

Managing Enterprise Content: A Unified Content Strategy by Ann Rockley and Charles Cooper

eBooks 101: The Digital Content Strategy for Reaching Customers Anytime, Anywhere, On Any Device by Ann Rockley and Charles Cooper

Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services by Robert Glushko and Tim McGrath

Content Strategy for the Web by Kristina Halvorson

Business @ the Speed of Stupid: How to Avoid Technology Disasters in Business by Dan Burke and Alan Morrison

JACK MOLISANI is an STC Fellow and the president of ProSpring Technical Staffing (ProspringStaffing.com), an agency specializing in staff and contract technical writers. He also produces the LavaCon Conference on Digital Media and Content Strategies (Lavacon.org). Follow Jack on Twitter: @JackMolisani.

SCOTT ABEL is a content strategist and communication process improvement evangelist. He is president and CEO of The Content Wrangler, an internationally recognized online source of information about digital publishing, content marketing, social media, and content management. Scott is a frequent contributor to a variety of journals, magazines, and online publications and is a popular speaker at content industry events. He co-produces the Intelligent Content Conference and Content Strategy Applied North America. Follow Scott on Twitter: @ScottAbel.