Apr 062016

[Ed. Note: This is the second of a two-part article on techcomm in service organizations. Part One is here.]

Part 2 – Challenges Facing Technical Communicators in Service Companies

Last time I told you about the value technical communicators can bring to service companies. Service companies give technical communicators a chance to prove the value of documentation outside the traditional “product documentation” role. But service companies also present challenges. Some challenges stem from the short-term business strategies and fragmented management structure of many modern organizations, while others stem from the habits and expectations that many documentation professionals bring from previous product-orientated roles.

Bringing Long-Term Value in a Short-Term World

A typical resume today resembles a list of casualties. Many jobs last less than two years, and companies fail or merge with other companies so often that many former employers from prior years no longer exist. Faced with these odds, many companies are built around short-term business plans, with the goal of selling the company or launching an IPO within several years of the business’s founding.

Managers immersed in short-term objectives might be tempted to view documentation as a long-term project that has to wait. This view quickly changes, however, when the company experiences a service outage and technicians scramble to find the information they need to diagnose the system’s failure.

Arbitrary Management Structures

noun_204504_ccTechnical communicators often report to different departments during the course of their career—or even during a single job. Documentation groups can be part of Product Management, Development, Quality Assurance, or even Marketing. Most writers are used to being randomly placed within organizations. In product-oriented companies, the reporting structure seldom matters. The technical communicator’s goal is to produce usable documentation for end-users and system administrators that is delivered with the product.

In a service organization, the technical communicator contributes to many company departments and projects. Onboarding, knowledge management, and inter-company communication benefit the entire company. But the technical communicator’s salary is still paid out of one department’s budget. Writers should look for opportunities to show how their work is crucial to the team they are nominally assigned to, even when they spend time writing content for different teams. For example, if a writer who is listed as part of the platform engineering team spends several weeks working closely with a different application development team, those efforts still benefit the engineering team by ensuring that the two technical teams work in sync. If the teams aren’t kept abreast of each other’s work, they are likely to pursue incompatible solutions that thwart each other’s progress when problems arise later in the deployment cycle.

Expectations About Writing

Many technical communicators have long histories in product-oriented companies. These companies demand perfection in their documentation. The fonts, terminology and use of emphasis follow detailed style guides. Most writers can recall times in their careers when they debated the fine points of literary style with bosses and colleagues, and afternoons spent underlining suspect word choices with a red pen.

noun_325456_ccKnowledge managers of service companies seldom have the time to worry about perfection. Much content isn’t produced by professional writers, but by customer support teams, developers, or network administrators who are simply maintaining functional specifications or technical diagrams as a rote part of their job. Knowledge managers are hard pressed to track all this information and keep it up to date. They must keep a mental map of the content and distinguish between the content that requires perfection (documents that may go to customers) and the content that must simply exist in a basic, usable form.
Many professional writers are threatened by the realization that basic documents written by non-professionals can be useful. If a Google document written by a customer support engineer, with misspellings and poorly formatted paragraphs, can still contain essential information, then what is the value of professional, polished documentation? These fears are misplaced:

  • The value of rough documentation proves that documentation is inherently valuable and useful. If not, then no one would write it. The fact that organizations are literally drowning in documents produced by non-writers to solve workaday problems demonstrates that documentation is as important as ever to a company’s success.
  • noun_231347_ccDocumentation is useless if no one can find it—and documents that are painful to read are more apt to be forgotten and overlooked. While rough documentation might be useful to its creators, few companies can count on retaining any given employee for more than a couple of years. A Google spreadsheet with minimal formatting might work for a small team of network administrators, but they aren’t likely to be the only people who need access to this information during the company’s life. Without a dedicated staff member to keep the information findable and usable, it quickly becomes lost. Lost information can’t solve a service outage or bring a new employee up to speed on the service’s architecture.


The growing service sector offers many opportunities for skilled communicators. These companies depend on reliable information for their day-to-day operation, and few professionals from other disciplines are prepared to design and manage the flow of written material between technical teams. The central role documentation plays in service companies shows the value that technical communicators can bring to the internal functioning of their own organizations as well as to end-users of software and hardware products.

About the Author

Jason Dickey is Principal Information Architect at Interactions Corporation in Franklin, Massachusetts. He has worked as a technical writer, user experience designer and knowledge manager for telecommunication, cloud storage, artificial intelligence and financial services companies. He is currently researching best practices for designing voice and text interactions between human users and artificial intelligence agents using natural language processing, voice biometrics and automated speech recognition in service environments.