October 2012

Evolving Roles of Technical Writers

CIDMIconNewsletterSteve Ballard, Intel Corporation

Whether ensuring that your technical writing team is adding significant value in a flat-to-down business climate or addressing team member performance to expectations, it’s important to carefully define the team charter, scope, and employee skills and roles. This article focuses on roles: how they fit with your team charter and business partner goals and how they are the basis for technical writers to grow into new and existing job titles.

Many HR managers in US corporations define Technical Writer roles based on definitions in the Occupational Outlook Handbook (OOH), published by the US Department of Labor’s Bureau of Labor Statistics (BLS). Definitions follow.

  • OOH Technical Writer Definition: Technical writers, also called technical communicators, produce instruction manuals and other supporting documents to communicate complex and technical information more easily. They also develop, gather, and disseminate technical information among customers, designers, and manufacturers.
  • OOH Editor Definition: Editors plan, review, and revise content for publication.

When compared to the various definitions for engineers, it’s easy to see that the OOH and BLS definitions have yet to acknowledge the diversity of roles and growing complexity of tasks that technical communicators perform. Engineering over the past 50 years has evolved from a handful of job types into hundreds. Technical Communication is now to the point which such an evolutionary step is necessary—to grow from these basic two, to perhaps 20 and beyond in the next decade.

The global movement from desktop publishing to XML/DITA “database publishing” is a key driver, as is the need for localization and efficient content reuse across a company’s enterprise.

Impact of Evolution from Desktop Publishing to Database Publishing Era

One of the great things about Desktop Publishing (DTP) over the past 30 years is that everyone could “do their own thing” as long as the output met the corporate branding look and feel requirements. And it could be done in a fraction of the time compared to the mainframe-based solutions of that era.

For international companies with large

and/or complex products, DTP is just about out of steam. When working in a corporation that develops and sells products worldwide—and one in which business units must share technology and content in their product lines with high direct reuse—the small “mom and pop” tech writing teams are becoming a thing of the past.

An emerging requirement is that you must deliver the “release candidate”—the finished document or information set—in more than just print or PDF. Whether for internal reuse or external delivery to customers or agencies for localization or other, the demands for content structure are going up. We often think that “technology” such as new authoring tools and repositories will provide a solution. Be aware that in addition to these tools, you must have a plan for your information architecture, people skills, and business processes.

As the technical communication manager, the best place to start is with your team. Define your team’s charter, the employee’s roles in documentation development, as well as in the overall product development lifecycle, when and how they engage with business unit partners such as subject matter experts (SMEs), program managers and product development teams, and peer technical communication teams across your enterprise.

Define Your Scope and Charter

Human Resources (HR) at most companies intentionally use broad job descriptions to allow maximum flexibility of resources across business units, product lines, and information types. Typically the Technical Communication Manager tailors the specific charter, scope of products and/or information types, employee skills requirements, and roles to address the immediate needs of the specific business unit, taking into consideration the corporate requirements of branding, legal, IT, and more.

This example charter statement explicitly identifies roles, product types, business partners, and scope in product development:

Plan, develop, reposit, and deliver product specifications for silicon, software, and board products in partnership with subject matter experts throughout the product development lifecycle.

This example implies that internal product and specification development is not supported; the team only supports content which is externally visible:

Ensure external-facing product specifications conform to corporate publishing guidelines.

When moving beyond the Desktop Publishing era in which only final output was addressed—to realize optimum efficiency and Return on Investment—the XML/DITA Database Publishing era requires well planned, high-quality content as soon as possible in product development. It typically requires that you partner directly with SMEs throughout the product development life cycle to minimize their time on roles that are outside their primary scope and to increase the value of technical communicators, all with the goal of delivering higher quality content sooner.

It is incumbent upon us managers to precisely define our business model for

  • Employees—to ensure optimum performance
  • Internal clients/SMEs—to ensure close integration with their programs and roles
  • Management—to ensure our contributions and methods are understood and contributing to the bottom line
  • Seamless integration with peer technical communication managers within our companies

XML/DITA requires a higher degree of consistency over DTP—so do our organizational definitions.

Primary Roles for Technical Communicators

For most of us managers, the macro definition of roles may include: Plan, Acquire, Author, Edit, Review, Reposit, Render, Localize, and Deliver/Publish (see Table 1). We often take for granted that virtually all content development efforts require performance of these roles:

  • On small projects, one person may implicitly perform all roles; the subject matter expert (SME) may perform all roles without assistance from a technical writer
  • On medium projects, the roles may be shared among SMEs and technical writers (TWs)
  • Large programs with enterprise requirements may require coordination of tens or hundreds of SMEs and multiple TWs


Table 1: Macro Roles Defined

Careful definition is required to scale up to enterprise solutions, which are typically required for XML/DITA implementations.

Figure 1 shows example macro roles on the left and example titles used within the Technical Writer job descriptions. These are examples only; roles on your team are likely to vary. This model is useful for showing the employee a career path and also for indicating how various grade level employees can work together as a team on programs.


Figure 1: DTP Roles and Example Job Titles

Implementing a Roles-based Solution

At Intel and many high-tech companies, the SMEs for silicon and software products are Architect Engineers and Customer Applications Engineers. Other contributors, reviewers, approvers, and recipients include engineers from Design, Validation, Test, and more. When new engineering teams form (through acquisitions or reorganizations, for example), the engineers often attempt to perform all roles on all product specifications. As they encounter the need to reuse content from one product to the next or receive incoming content in a variety of information architecture, format, grammar quality, and markup, their time on documentation climbs from an acceptable amount of ~25 percent up to 50 percent or more. Further, when quality and schedule availability start to suffer, the engineering teams recognize the need for people who specialize in these product information development roles.

As manager, the challenge is to assess the roles as defined in Table 1 and Figure 1 and then map out a plan for how TWs and Information Program Managers can take on the roles and task assignments from the engineers. This move drives down the engineering time on these content roles and tasks.

Return on Investment of Technical Writer/SME Collaboration

A typical ROI scenario is generally calculated as follows:

  • Assume that a team of 25 engineers spends 50 percent of its time on documentation
  • Adding 1-2 HC headcount (HC) of TW/IPM (Information Program Manager) to the team promises to drive the engineering time to 25 percent
  • This equates to a 6 HC savings for engineers, minus the cost of two HC for TW/IPM = 4 HC savings, which is between 15 to 20 percent
  • Further, our historical results show the business unit (BU) also realizes higher quality content sooner, which means the internal customers can begin their work sooner with less rework required

Table 2 indicates how roles and tasks migrate from SMEs to technical writers and Information Program Managers as program complexity and content quantity increase. Bolded highlighting indicates the roles and tasks that the technical communication resources can offload from the subject matter experts.


Table 2: Roles and Assignments Vary with Complexity

The goal is to ensure SMEs are primarily focused on technical issues while TechComm focuses on content project planning, content development, facilitation, and delivery.

Integrating the Team in the Product Development Lifecycle

Virtually all product development processes require a minimum of four phases:

  • Explore: assess if the desired product can be created at the right cost on schedule to meet market segment demand with available resources
  • Plan: define the functional, performance, physical, and usage requirements, plus deliverables, schedules, and risks/assumptions/dependencies
  • Develop: simulate and then build the prototypes and products
  • Deliver/Production: manufacture and ship the product to meet customer demand and ROI goals; supporting customers after the sale

On medium and large programs, the engineers require TW support with product specifications through all phases. All too often in the DTP era, TW roles of edit, format, and deliver were required throughout but only assigned to the final customer facing output. As shown in Table 2, the TW as IPM or documentation project lead is low level or non-existent. This model of SMEs performing all documentation roles typically does not scale.

The quality of content late in product development may have issues that a TW cannot address in the time allowed. As a result, TWs may only have time to perform required legal edits, “look and feel”, grammar, and format improvements, ensure links and cross-references are working, run spellcheck, and create the PDF.

In this scenario, the technical communication manager must demonstrate to management and SMEs the need to integrate with product development to ensure that the highest technical communication value is added from the start.

When engaged early, the TW team members may perform roles that align to job titles such as

  • Information Architect: Ensure the appropriate content deliverables are planned with appropriate content outlines to identify the topics that align to physical, functional, performance, and procedural groupings
  • Information Program Manager: Develop a Technical Information Plan which identifies all document (or content) deliverables, technical writing resources, roles to be performed, schedules, risks, assumptions, dependencies and more
  • Trainer/Mentor: provide usage instructions on tools, templates and processes for authoring, repositing, illustrating, and reviewing
  • Content/Repository Manager: Establish the folder structure in the repository; populate with document templates for all deliverables; acquire existing content for rework/reuse; define, implement, and manage security and entitlement; train participants on how to use the repository and collaborate
  • Author/Co-author: Generate new content and significantly revise existing content
  • Editor: Perform technical, grammar, format, legal, production (as previously defined) checks
  • Output Render: Generate the “release candidate” document in PDF, HTML, or other output formats
  • Convert/Transform: Incoming content including the human readable text/tables/graphics; address the underlying markup and metadata
  • Governance/Business Process: Ensure that workflow and processes associated with all of the above are in place, understood, used, and maintained throughout the program

On small and medium projects, the TWs may invest 5-10 percent of their time on these roles. On an enterprise scale, these roles may become full-time jobs, driving the need for specialists and a consolidated team vs. several smaller teams performing multiple roles.

If your company and team are planning a move to XML/DITA database publishing, be aware that these roles are generally if not specifically required. If not the technical communication team, then who will assume these responsibilities?

As manager, the sooner that you move the right people with the right skills into the full product development process, the sooner you can plan your move to XML/DITA solutions.

Moving to XML/DITA: Equation for Success

Enterprise Content requires a complete solution. Enterprise Content can be defined as human readable content in which consistency is required across all business units.

In your environment, Enterprise Content may include business documents such as program planning specifications, market requirements plans, product requirements specifications, training materials, and more.

For semiconductor technical information, examples include functional overview, registers, performance specs, block diagrams, packaging/pins/signals/thermal data, procedural “how to” instructions such as installation and getting started guides, reference information, programming instructions, online help systems, and more.

ENTERPRISE CONTENT EQUATION = Content Model + Authoring Tools + Repository + Roles + Processes + People + Usage Model + Governance


  1. Content Model (AKA Information Architecture): Required and optional unique topics
  2. Authoring tools: The acceptable tools for creating and editing text, tables, graphics, and others
  3. Repository: Enterprise content management system that conforms to corporate Information Security
  4. Roles: Plan, Author, Edit, Review, Reposit, Deliver, Reuse, and Approve
  5. Processes: “How to” efficiently perform defined roles
  6. People: Appropriately trained resources with expertise in the solution
  7. Usage Model: Content that is appropriate for who, how, and when
  8. Governance: Prescription of all the above; training on best practices

Take these factors into consideration when architecting your XML/DITA solution. When your employees who contribute to your company’s documentation are working in an environment that conforms to the Enterprise Content Equation, the transition from a DTP model to an XML/DITA solution model is much smoother.

Scaling the XML/DITA Solution to the Enterprise Drives Roles Specialization

It’s often easier for an experienced TW to grow into new job codes and roles than for a new hire who does not have the years of experience in TW disciplines. For example, it’s proven to be much more difficult to bring in and train a generic program manager to lead the planning and development of ~30-50 document deliverables and interact with SMEs and TWs than it is to grow a TW into this role. That logic follows on most of the jobs and roles listed here.

Jobs and roles similar to DTP

  • Information Program Manager
  • Project Lead
  • Information Architect (strategic)
  • Information Re-Architect (tactical)
  • Author
  • Editor
  • Publisher

Job and roles unique to DITA

  • Consultant
  • Analyst
  • Metrics expert
  • Metadata expert
  • XML/DITA evangelist
  • Trainer / Mentor
  • Localization (several)
  • Librarian / Information retrieval
  • DITA configuration manager
  • XSLT software engineer
  • Governance board leader

In summary, as you transition from a DTP “unstructured content” environment to the structured XML/DITA generation, adherence to the five steps identified here will help ensure a smoother transition and anticipate the emerging roles and job codes associated with next-generation enterprise content development.

  1. Define a team charter, roles, and tasks
  2. Manage programs and employees based on the roles and tasks to be performed
  3. Ensure the team is involved throughout product development
  4. Evolve from desktop publishing to enterprise database publishing
  5. Consolidate roles and tasks with specialists in the new job codes CIDMIconNewsletter

Steve Ballard

Intel Corporation

Steve Ballard is a Technical Communications Manager for Intel’s Intelligent Systems Group. Products include platforms, processors, and associated software. He is a leader at Intel in the evolution from desktop publishing to XML/DITA ‘database publishing’ from defining the vision and solution to enterprise-wide implementation. He currently manages a team of 20 technical communicators in support of large product development programs across multiple business units.