Using Business Models to Describe Technical Communication Groups

Saul Carliner

Abstract

Purpose: According to the management literature, a business model explains how an organization makes money (generates revenue). These models not only affect revenue but, because generating revenue is central to the survival of an organization, affects all other operations.

Method: Applies the theory of business models from the management literature to technical communication groups, using descriptions of technical communication groups from empirical studies to identify the most common business models for these groups and suggests how the source of revenue affects operations.

Results: Technical communication groups typically fall into one of these models: (a) Venture Capital Model—groups that produce content published for sale; (b) Design Model—groups that design the architecture and oversee implementation of Web sites, large information campaigns, user interfaces, and designed-in information; (c) Agency Model—groups that produce marketing communication, employee communication, and other high profile content; (d) Development Shop Model—groups that support a strategic effort by developing help, user’s guides, reference manuals, and similar product information; (e) Technical Support Model—groups that produce materials for internal users; and (f) Contractor Model—groups that update documentation for products and services have long life cycles (often lasting for decades). Although the literature on technical communication advocates for the Design model, most technical communication groups operate under the Development Shop, Technical Support, and Contracting Models, as well as mixed models.

Conclusions: This theory does not prescribe actions technical communication groups should take to change their status; rather it describes why technical communication groups in different organizations might have different experiences.

Keywords: business models, management, power and influence, value

Practitioner’s Takeaway

This theory describes why technical communication groups in different organizations might have different experiences.

• Why different technical communication groups work on different types of assignments
• Why different technical communication groups value particular skills (for example, why user interface skills are better used in some groups than others)
• Why some technical communication groups might thrive under one placement (such as in Research and Development or Marketing) while others might flounder under the same placement
• Why some organizations seem to value technical communication products and services more than others
• Why some technical communication groups have more control over their destinies than others.

---

Introduction

Theories describing the core work of professional technical communicators are widely documented in the literature in technical communication, such as theories on the process of writing (for example, Flower & Hayes, 1981), theories on the role of genres in directing writing activities (for example, Berkenkotter & Huckin, 1995; Swales, 1990), and theories linking the creation of genres to the environments (activity systems) that create them (for example, Spinuzzi 2003).

Similarly, the literature on technical communication also documents the situations in which professional technical communicators work. For example, the literature describes the different organizational structures in which technical communicators work. Various membership surveys taken by the Society for Technical Communication (STC) and its chapters and special interest groups suggest that some technical communicators work in stand-alone departments, some work as teams within departments that have responsibilities beyond communication, while others work as lone-writers—the only technical communicators in their organizations. (As a result of these differences, I use the term group rather than department as the overarching term to refer to the situations in which technical communicators work.) The peer-reviewed literature describes differences in the range of authority that technical communication groups have. For example, in her study of the production of technical communication products in four organizations, Hovde (2010) contrasts one organization whose technical communication staff consists of a part-time university student whose authority is limited to production issues with the operations of other groups. One of those other groups is a department of full-time and experienced technical writers who propose the structure and content of their documents but do not have final approval of their work. Although raising concerns about the “second-class” status of technical communicators, Hovde’s research actually presents situations in which technical communicators in different situations have different levels of influence.

What the technical communication literature lacks is a theory that, at the least, classifies these differences in situations in which technical communicators work and, at the most, suggests how the conditions for technical communicators varies under these different conditions, such as differences in the nature of the work they perform and differences in influence in different situations.

Although our literature lacks this theory, it does exist in the literature on management. In particular, business models, a popular and increasingly researched theoretical construct, provide a theoretical basis to explain differences in status, reporting structure, and assignments among technical communication groups. The concept was initially developed to explain how organizations generate revenue, especially organizations engaging in e-commerce (Weill, Malone, D’Urso, Herman, & Woerner, 2005).

But the concept has been broadened to apply to other industries, like communication, to organizations other than for-profit businesses, as well as to internal departments. In terms of the communication industry, business analysts have used the concept to explain problems in the mass communication industry (Carr, 2009; Clifford, 2009; Perez-Pena & Arango, 2009; Rich, 2009). In terms of government and nonprofit organizations, some social service agencies that once relied almost exclusively on government funding have changed their business models and now seek alternate sources of income as that funding shrinks. Such agencies offer some services on a fee-for-service basis and are more actively soliciting donations and sponsorships. Similarly, Maguire (2008) notes that nonprofit organizations that publish magazines and academic journals, such as the ATTW, IEEE, and STC follow implicit business models to publish these journals.

Business models also apply to individual groups within organizations, such as a Research and Development division and a Technical Communication department. These groups all receive funding. For many groups, the funding comes in the form of a yearly budget allocation. For others, the funding comes as payment for services, sometimes a single payment to cover an entire project, sometimes payments for actual hours worked and related expenses incurred. Although many technical communicators might think about the amount of funding they receive, fewer have probably considered that the manner in which they receive income has an impact on their operations beyond the mere money. At the least, such differences in payment schemes could explain the financial flexibility of technical communication groups in different situations. At the most, such differences could explain situations in which technical communicators work and how these differences result in differences in power and status within organizations. That, in turn, could provide a theoretical basis for describing the differences in power and status among technical communication groups. Power and status is a recurring theme through the years in the literature on technical communication. Not only does Hovde (2010) mention it; so does Spilka (2000). Coppola (2011) and Savage and Kynell (2003) go further, editing multi-part works to the issue.

This article applies the concept of business models to technical communication groups. First, it explains what business models are and contrasts the concept with other descriptions of the management of technical communication groups. Next, this article provides a taxonomy of common business models for technical communication groups. An example of a large technical communication group with several departments that each operate under a different business model illustrates the practical implications of these different business models, The article closes by considering some broader implications of business models to the theory and practice of technical communication.

About Business Models

The central purpose of a business model is to explain how an organization makes money (Afuah & Tucci, 2000; Chesbrough & Rosenblum, 2002)—also referred to as generating revenue. For example, does the organization receive a lump sum (apportionment) at the beginning of the year as most cost centers do? This is the case with many internal technical communication groups (Carliner, 2012; Carliner, Qayyum, & Sanchez Lozano, 2012). Or does the organization receive payment for each project, as most firms that provide consulting and contracting services do (Chesbrough & Rosenblum, 2002)?

Management researchers have noticed that the manner in which organizations generate revenue also affects all other aspects of their operations. For example, researchers have noticed that the manner in which an organization generates revenue influences the processes for creating products and delivering services. The means of generating revenue also affects the flow of information and other resources (Weill, Malone, D’Urso, Herman, & Woerner, 2005). In organizations that have a guaranteed source of income, like internal technical communication groups that receive an annual apportionment, the process usually begins when a technical group (Engineering, Software Development, or a similar group) initiates a request for an assignment. Most communicators in these groups interact with clients through a project or departmental manager. In contrast, in organizations that receive funding by the project, like contracting and consulting firms, the process usually begins with a request for a proposal for a project, and work would not begin until the client approves the request. In these situations, communicators might interact with clients through an account manager rather than a project or department manager.

A second aspect of operations affected by the source of revenue is the cost structure of products and services (Chesbrough & Rosenblum, 2002). For example, what percentage of costs are direct costs (that is, go directly to the service, such as the cost of a technical communicator’s time) and which costs cover overhead, additional costs, such as rent on the office where the technical communicator works and the cost of the manager? For those organizations that do so, what is the percentage of profit (that is, the funds left after expenses are subtracted from revenue)?

A third aspect of operations affected by the source of revenue are relationships with clients, suppliers, and others (Weill & Vitale, 2001). For a technical communication group working under an apportionment system, for example, the guarantee of funds require that technical communicators be available for all projects planned within the organization. These technical communicators receive approvals for budgets, hiring, and other aspects of operations from their sponsors. Sponsor is a generic term that refers to the internal or external client who can either authorize or stop payment on technical communication services (Robinson & Robinson, 1989). In contrast, technical communication groups that are paid by the project only work with their sponsors when a need exists. Furthermore, sponsors typically expect the technical communication group to manage its own internal affairs like budgets and hiring, although sponsors might voice opinions.

A fourth aspect of operations affected by the source of revenue is the way that the organization creates value for its sponsors (Linder & Cantrell, 2000). For example, a technical communication group funded by apportionment is usually part of a larger organization and creates value for the sponsor by providing a piece of a larger product or service, like the documentation of a computer, the training provided as part of a professional services contract, or the user interface of a software program. In contrast, a technical communication group funded on a per-project basis fills a gap in the skill base of the customer organization.

How Business Models Contrast with Other Explanations of Differences among Technical Communication Groups

Business models contrast with other explanations of differences among technical communication groups. Some of these other explanations are rooted in the opinions of their authors and make assumptions about the ways that technical communication groups do and should operate—views that empirical evidence often does not support. For example, several authors have suggested that the ideal structure for technical communication groups is as profit center (Boiko, 2009; Kline, n.d.; See, 1995). In the most basic terms, a profit center is a group that charges for its products and services with the intention of generating more revenue than is needed to provide the service (a profit) (See, 1995). The limitation of such suggestions is that they often lack concrete details about how a technical communication group might operate under such an approach, much less how they might make the transition. Commenting on Boiko’s advice that technical communication groups should operate as profit centers, Hamilton (2009) comments that Boiko “conceded that this is hard to do.”

Other explanations of differences among technical communication groups are strongly rooted in theory or empirical data. For example, Hackos (1994) adapted the Software Process Maturity Model (Pfleeger & McGowan, 1997) to technical communication projects. The Process Maturity Model differentiates among organizations by the sophistication of their project management processes, ranging from ad-hoc processes to ones that are optimized through feedback loops. The advantage of the Process Maturity Model is that it suggests that technical communication groups are likely to experience different working conditions based on the sophistication of project management in the organizations. However, this model does not suggest the types of projects on which technical communicators might work, the skills they might use, or the level of influence they might have within an organization.

Hackos (2007) proposed a second approach, the Project Portfolio Model. The project portfolio model advises managers to evaluate the types of projects on which they can do well and those on which they can’t, and to adjust their workload to focus on those projects that groups can do well. The advantage of such a model is that it recognizes that technical communication groups do not perform all projects equally well. However, this approach is not predictive. It is, instead, a framework for evaluating work.

The third, and perhaps most popular, approach is value-added (Redish & Ramey, 1995), which suggests that, by collecting concrete, quantifiable evidence of ways that technical communication projects have added value to the organizations that published them, technical communicators can add to their prestige within the organizations that employ them. As a variation, the Aberdeen Group identified specific ways that technical communication products affect satisfaction and revenue of the products they support (Houlihan, 2009). However, both of these approaches only explore the impact of individual communication products. It only explains how to determine whether technical communication products and services ultimately added value, rather than explain how organizational structure and processes supported or constrained technical communicators in producing such valued work.

Researchers further assume that providing empirical evidence of value results in tangible benefits to technical communication groups, but no research explores such impacts. Empirical evidence of similar issues in the field of training suggests that evidence of value-added is often not as persuasive as hoped (Subramony, 2006).

Business Models for Technical Communication Groups

Business models can address the shortcomings of the approaches just described and explain how technical communication groups operate within larger organizations and the extent of influence they have within them. This section applies the theory of business models to technical communication. It first explains the methodology used to derive the application, then it describes a taxonomy of business models for technical communication groups.

Methodology

The common models for technical communication groups are derived from two sources:

• Empirically derived case studies of the work operations of technical communication groups (such as Hovde 2010; Kain, 2006; Power, 2009)
• Surveys of the work practices in technical communication groups (Carliner, 2004, 2012; Carliner, Qayyum, & Sanchez-Lozano, 2012)

Although conducted for other purposes, patterns recurred in this literature, showing consistent patterns of operations and influence associated with different types of assignments. The taxonomy emerges from this observation of patterns.

The literature on business models suggested that the way an organization receives funding affects all of its operations—not just getting money, but also the way an organization manages projects, how it defines work quality, and how it interacts with sponsors. So the operations of technical communication groups operating under each business model identified was analyzed from a number of perspectives suggested by the literature, including:

1. The types of projects on which the group is likely to work
2. The value of information (content, communication products) to sponsors
3. To whom the group might report
4. The skills that the technical communication group values
5. The time frame of projects on which the group works
6. The nexus of respect that the group earns from its sponsor
7. How sponsors assess the success of the work they receive from the technical communication group (suggesting, in turn, what constitutes “value” to them)

A Taxonomy of Business Models for Technical Communication Groups

To think about this in practical terms, consider the example of the Technical Communication group at MegaCorporation, led by Director of Technical Information, Vicki Harrington. Vicki has direct responsibility for 143 technical communicators working in 9 departments and indirect responsibility for another 20 temporary workers. The nine departments include:

• One (1) User Experience Department, which designs the user interface and develops comprehensive user support plans for new and significantly modified software applications.
• One (1) Special Projects Department, which works on a wide array of projects on an as-needed basis, from white papers about the applications documented by the Technical Information departments to displays and presentation materials needed by programmers and other technical staff attending conferences and business shows.
• Four (4) Product Information Departments. Three (3) of those departments develop the user assistance designed by the user experience department. The fourth develops user assistance for a different division of the company.
• One (1) Maintenance Department, which maintains documentation for older products.
• One (1) department known as “The Press,” which produces after-market books and other materials for sale to end users and other parties.

The temporary workers include five consultants working for a user experience firm and assist the User Experience Department with special projects, as well as 13 contractors working for an agency that helps the Maintenance department when the workload exceeds the capacity of the department (which is often).

Other directors have noted to Vicki that they have had different experiences—and perceptions of—the different departments in her group. When discussing the situation with some of them, Vicki casually mentioned that the departments reporting to her receive funding in different ways. One of the directors picked up on this and suggested that Vicki “follow the money.”

That’s because the central proposition of business models is that organizations optimize their internal processes to maximize their revenue. An analysis of previous research suggests that, like the six categories of departments in the group the Vicki directs, most technical communication groups can be described by one of six common business models. Figure 1 names these six models. The following sections individually describe each of them. Each discussion specifically considers the implications of the seven issues named in the Methodology section and illustrates the model by relating it one of the categories of departments in the group that Vicki leads.

Model 1: Venture Capital Model

Groups that operate under the Venture Capital Model produce communication products for sale, such as books, magazines, DVDs, and websites that generate revenue either through subscriptions, advertising, or both. Although the revenue generated by the sales of the communication products eventually funds ongoing activities of the organization and future products, the first publications are usually funded by an up-front investment or loan. These investments often come from venture capitalists: hence, the name. But funding can come from within an organization as some organizations have the resources to do so. Publishers of third-party books, like the Dummies series, are examples of organizations operating under the venture capital model.

In the Technical Information group that Vicki leads, the Press department operates under the Venture Capital Model.

Groups like this are funded on a per-project basis and each project is usually funded separately. Furthermore, some projects might have several components that may be funded separately. To receive funding, the project leader must present a compelling business case to a funder. The case not only describes the content to be published, but must also describe and estimate the size of the market for the project, as well as realistically forecast the revenue and expenses for the project. If funders agree that the project is worthy and that the forecasts of expenses and revenues seem realistic, they approve funding. In some instances, the funder provides all of the funding at one time. More realistically, funds are paid as the organization successfully passes certain milestones. Should projects fail to meet their milestones, venture capitalists might terminate the funding and end the project (Hellman, 1994).

The communication products published by organizations working under the Venture Capital Model are strategic to the organization. That is, the success or failure of the organization rides on the sales of the communication products. For example, if fewer people purchase the Dummies books than is needed to cover the costs of preparing, publishing, distributing, and marketing those books, the publisher could go bankrupt.

Technical communication groups operating under the Venture Capital Model are ultimately accountable to their investors. Some investors take an active role in managing the organization, suggesting strategies for management and marketing and, sometimes, for which technical information to publish and how to publish it. Other investors take a hands-off approach, and let communicators make all of the key business decisions.

A technical communication group operating under the Venture Capital Model emphasizes these skills:

• Financial management: Minimizing expenses without sacrificing quality while maximizing income.
• Business leadership: Successfully capitalizing on market trends; demonstrating a willingness to take calculated risks to retain existing customers and appeal to new ones; and nurturing the “brand” (that is, recognizing the key components of the intangible value in a brand name—like “TechComm Press,”—and taking advantage of that value) (Keller, 1993).
• Project management: Identifying and securing all of the resources needed for a project; setting a realistic schedule and using it to create a realistic budget; and managing resources so that the product is produced on time and within budget (Hackos, 1994).
• Information architecture and design: Defining the audience and purpose for a communication product; linking the product to the business objectives of the organization; establishing objectives for the content; establishing quality guidelines for the content; designing one or more products that meets those objectives; choosing the most appropriate formats and media in which to publish that content; and evaluating the extent to which the published products actually meet their objectives (Carliner, 2003).
• Interface, information and experience design: Designing and developing user interfaces, related components of software, content, and similar types of materials so that users are delighted with the experience (Cooper, 1999).
• Technical communication skills: Effectively communicating content, such as instructions for using an application or device, policies for using internal computer networks, and safety training (Lanier, 2009).
• Customer service skills: Effectively interacting with sponsors and other members of the team producing a communication product, including the venture capitalists, executives of the organization publishing the content, other sponsors, and members of the team working on the product (Fredrickson, 1993).

The time frame for projects funded under the Venture Capital Model is medium- to long-term, usually 12 to 30 months.

Groups operating under the Venture Capital Model usually generate respect for their work through three sources of power:

• Leadership power: The ideas for projects come from the technical communication group, as does the initiative to secure funding. As a result, all people in the organization look to the technical communication group for intellectual leadership on a project.
• Referent power: Other people in the organization defer to the expertise of the technical communication group. The term referent comes from the term “refer,” because people see the technical communication group as the source of reference on projects.
• Financial power: Groups operating under the Venture Capital Model have control of their own finances on a project, and can determine how much to fund activities such as research, writing, and production. Note, however, that the technical communication group is still accountable to the funders for the ultimate use of funds, and some venture capitalists might seek final approval, but the technical communication group generally determines how to allocate funds on a project.

In a technical communication group funded under the Venture Capital Model, investors assess the success of their investment by the return it offers. The return is the amount of money that is paid back on the investment. At the simplest, investors consider the profit earned, and their share of that profit. But most take a more complex view, focused not only on dollars received in income, but the percentage of return on profit compared with other possible investments, including interest on a bank account.

The Press department in the example of MegaCorp generates revenue by publishing books, e-learning programs, how-to videos, and similar materials, and selling them to customers directly and through major retail outlets, such as Amazon, book stores, and technology retailers. The majority of its authors are freelance writers who earn some or all of their income from royalties on the books, although the Press does publish some materials by company employees. Because it has responsibility for generating its own revenue and must meet both revenue and project targets established by the company, the Press prepares a business case for each project it considers publishing. The business case not only estimates the total cost of writing, editing, producing, publishing, inventorying, supporting, and marketing the materials, but also estimates the numbers of copies to be sold, including best and worst case scenarios. The Press only publishes content that can generate at least 19 percent profit under a worst case scenario. The Press thrives or suffers based on its sales; failing to meet sales projections in one year has a negative effect on the budget in the coming year.

Furthermore, although the Press provides freelance authors with access to Subject Matter Experts in the company, authors have full responsibility for the accuracy of the content published and bear full liability for errors in publication. The Press does not make Subject Matter Experts available for technical reviews of the content. That liability concerns some of the technical communicators in Vicki’s group; these information developers only feel comfortable when Subject Matter Experts verify the accuracy of content.

Model 2: Design Model

This model describes technical communication groups that are part of a larger organization, and who play the leadership role in designing and developing the products produced by the organization. For example, a group operating under the Design Model might not only document the web-based travel application that the organization produces, but also design the entire user experience associated with that application.

In the Technical Information group that Vicki leads, the User Experience department operates under the Design Model, as do the five consultants working for the independent consultancy on user experience design.

The Design Model is often recommended in the literature (for example, Albers 2002, Ames 2001, Dykstra 2001). In many ways, the Design Model is like the Venture Capital Model. The primary difference is that groups operating under the Venture Capital Model are typically independent and the projects on which they work are self-contained. Groups funded under the Design Model are typically part of a larger organization, work on projects that are part of larger product development efforts, and usually engage in the business of software development. In some instances, these workers might work for consulting firms.

Like technical communication groups funded under the Venture Capital Model, technical communication groups operating under the Design Model are funded on a per-project basis. The funding may be phased, as might happen on a project funded under the Venture Capital Model. That is, at key milestones, senior executives determine whether to continue funding the project.

Projects funded under the Design Model are strategic to their organization, and typically include:

• Web sites (designing the architecture and branding for the site, as well as overseeing the implementation of the plans)
• User interfaces
• Designed-in information (such as all of the on-screen content for an application and the keytop names on specialized keyboards)
• Information that’s external to the software, such as help, manuals, sales materials, and training

Technical communication groups operating under this model typically report to a software or product development executive. In a few organizations, technical communication groups operating under the Design Model have their own executive, who reports to the president or CEO of the organization.

Technical communication groups operating under the Design Model emphasize the same skills as groups operating the Venture Capital model—business leadership; project management; information architecture and design; interface design; experience design; technical communication; and customer service. But technical communication groups operating under the Venture Capital typically emphasize business management skills more than those operating under the Design Model. Those operating under the Design Model, in turn, probably emphasize information architecture and interface design, information design, and experience design skills more than those operating under the Venture Capital model.

The time frame for projects funded under the Design Model is medium- to long-term (6 to 36 months). That is because many of these groups are internal to an organization and already have access to confidential information about the organization.

Groups operating under the Design Model derive respect through leadership and referent power. To a small extent, they also have financial power, because the technical communication group prepares and justifies the budget for a project to the senior executives before it commences. But the technical communication group often does not have final authority over allocations of budgets.

In a technical communication group operating under the Design Model, the value of the technical communication effort is assessed in several ways. When feasible, organizations track the revenue generated by the communication products. But in many instances, that is not feasible, so organizations assess the value added by the technical communication group; its ability to respond to input from others inside and outside of the organization and the results of surveys of satisfaction with the product and project, and usability tests (if conducted).

The User Experience Department that reports to Vicki has had responsibility for designing the user interfaces of all software designed by the division for the past five years. The Vice-President for Research and Development, to whom Vicki reports, typically involves a member of the department during the product definition phases. When the market planners successfully receive initial funding for their projects, the Vice-President for Research and Development turns over the project to the User Experience Department to lead the design and initial prototyping of the user interface for the project. Typically, the User Experience Department prepares a detailed beginning-to-end description of the entire user experience with the software, related support, and any relevant off-screen interactions that might affect use of the software. The department then prototypes the software and, once it has a viable prototype, oversees the development of detailed specifications by software development groups.

The User Experience Department receives funding by the project. These budgets often provide the department with considerable purchasing power and include funds to interact extensively with customers, conduct competitive research, and receive assistance from outside consultants. But the department must justify these expenditures up-front. For example, because it does not have full-time researchers, the User Experience Department typically hires the consulting firm to conduct focus groups about new products and to oversee the testing of prototypes and a usability analysis of competitive products. Budget also comes with additional responsibility; when the price tag for its plans exceeds the budget available for the project, the department must determine which aspects of usability to pursue and which to shelve.

The User Experience Department has primary responsibility for the usability of the products. As a result, the Vice President for Research and Development uses independent product reviews as well as customer perceptions of products as measured by surveys conducted by industry analysts and the marketing department to evaluate the department. Product sales are also used to assess the department.

Model 3: Agency Model

This model describes technical communication groups that work on special projects, such as proposals for external clients, white papers for new products, PowerPoint slides and related handouts for senior engineers giving speeches at conferences, and displays and posters for trade shows and conferences. Usually these projects are short-term and have high-visibility. This model receives its name because technical communication groups typically manage these projects as if the group operated like an independent agency, whether or not they actually work as one. Whether the engineers hire an outside communications firm or assign the work to an internal technical communication group, the projects just described is an “agency” project.

In the Technical Information group that Vicki leads, the Special Projects Department operates under the Agency Model.

Organizations operating under the Agency Model are funded by the service or project by sponsors, who either use the communication product themselves, or re-sell it. Fees usually cover time and materials—the actual number of hours worked plus other project-related expenses like printing and purchasing specialized equipment and software for a project. For example, if a PowerPoint presentation requires 50 hours to produce and involves travel to another site to meet with an engineer, then the technical communication group would charge the client for 50 hours of work plus travel expenses. But fees are occasionally paid on a project basis, as is typical of funding for groups operating under the Venture Capital and Design Models. For example, the technical communication group would provide a single price quote to the customer for preparing a PowerPoint slide presentation, then manage the project to make sure that the number of hours and expenses do not exceed estimates.

In contrast to the strategic nature of information published by groups operating under the Venture Capital and Design Models, technical communication products published by organizations working under the Agency Model, while highly visible, are usually not strategic. Rather, the information usually supports another effort. In some cases, the technical communication products are merely cosmetic, produced to appease the person who requested them. Although the person requesting the work might believe that the communication product is strategic, others in the organization might not agree.

Projects developed under the Agency Model typically include communication products used in marketing, employee communication, and other high profile uses. Examples include proposals, employee handbooks, white papers, marketing collateral (brochures), sales-promotion materials (flyers), short online demonstrations, materials for trade shows, video presentations, and interactive media presentations.

Internal organizations operating under the Agency Model report to a communication manager. Many external agencies also operate under this model.

Technical communication groups operating under the Agency Model emphasize these skills:

• Project management: Ensuring projects are completed on the often tight schedules and budgets imposed by sponsors. Because many groups have the expertise to produce these types of materials, many groups operating under the Agency Model emphasize that they follow a unique and proven methodology that allows them to use time most efficiently and produce materials at the level of quality sought by the client.
• Creative problem solving: Offering creative ideas that work within the budget and schedule constraints, and other limits set by the sponsor. In fact, the ability to do this often builds a loyal following to groups operating under the Agency Model.
• Relationship marketing: Matching the sponsor’s needs with the services offered by the group; overselling (providing more services than a client really needs) could ultimately destroy trust, as could under-selling (providing fewer than the client really needs).
• Production: Preparing materials for print or for publication online. For printed materials, clients expect technical communication groups operating under the Agency model to manage the printing or duplication process, as well as the subsequent shipping and inventory management processes. For those materials being published online, clients expect technical communication groups operating under the Agency model to manage all of the various tests that precede publication and manage the tracking that occurs afterwards (such as click tracking for websites and learning management for e-learning programs).
• Technical writing: Writing clear, concise, and accurate informational materials (Lanier, 2009).
• Instructional design: Preparing clear, concise, and accurate materials for learning and that meet the needs of both learners and the organization (Villachica, Marker, & Taylor, 2010).
• Graphic design: Preparing clear, concise, and accurate images.

The time frame for projects funded under the Agency Model is short-term (3 or fewer months).

Groups operating under the Agency Model primarily have referent power within an organization.

In groups operating under the Agency Model, the value of the technical communication effort is assessed by word-of-mouth: how internal customers talk about the experience of working with the technical communicators and customers’ feelings about the products produced by the technical communicators. Specific issues considered often include timeliness of service, perceived utility of the final product, perceived appearance of the final product, and cost (Carliner, 2012).

Groups operating under the Agency Model assess the value of the technical communication effort by the amount of repeat business they receive from customers. In addition, some sponsors who request that technical communicators develop marketing materials for them might have in place systems for measuring customer response to the materials.

The Special Projects Department that reports to Vicki works on a wide a variety of projects. Some recur regularly, such as preparing white papers for the Marketing department, research reports that engineers and computer scientists submit to peer reviewed journals, and preparing presentation slides and handouts (and occasionally scripts) for staff giving presentations at business shows, conferences, and user conferences. Some occur once or twice a year, such as preparing the annual report of the Research and Development group and the semi-annual newsletter for the Research and Development staff. “Short” describes the lead times for most of these projects. For example, some programmers submit requests to the Special Projects staff as few as three days before a presentation. Then again, the programmers usually submit a first draft of the slides with these late requests. The drafts are usually “dreadful;” through its “magic,” the Special Projects staff “transforms” these drafts into “professional-looking” slide shows. The visual transformations on such short deadlines earn the appreciation of the Research and Development staff, and the fast pace and wide variety of assignments appeals to the staff of the Special Projects Department. Unlike the Press and User Experience Departments, however, the Special Projects Department does not select the content presented in any of the projects on which it works, much less has responsibility for the accuracy of the content. In fact, the department has no full-time technical writers on staff. Although all staff can write, two primarily work as editors, six primarily work as production specialists, and three primarily work as project managers.

The work itself is precarious. Because the department is funded by the project, many of the projects are considered expendable in a budget crisis, so the manager and his staff regularly worry about long-term prospects for the group. Although the staff of the Special Projects Department has strong knowledge of the products and services of MegaCorporation, the manager knows that, in a pinch, that knowledge offers only a limited competitive advantage and the company could outsource the work.

Model 4: Development Shop Model

This model describes organizations in which the technical communication group prepares communication products to support a strategic software or hardware project, or a new initiative in the organization. A fundamental characteristic of the Development Shop model is that technical communicators do not have approval rights for the design of the project or service on which they work (Dykstra, 2001; Kove & Drexler, 1998; Storey & Hartman, 2000), although they might have an opportunity to comment on these designs.

In the Technical Information group that Vicki leads, three of the Product Information Departments operate under the Development Shop Model.

Groups operating under the Development Shop Model are funded on an apportionment basis. As noted earlier, under an apportionment system, the technical communication group typically receives its funding as a lump sum at the beginning of the fiscal year following a budgeting process. In some instances, however, the budget comes on a project basis and is calculated as a percentage of the larger budget for the project that the technical communication effort supports. Although the percentage varies by organization, it usually ranges from 5 to 20 percent (Thomson, 1998).

The technical communication products published by groups working under the Development Shop Model typically support a strategic effort in the organization. On its own, however, the technical information is not considered strategic. These technical communication products typically include:

• Help, user’s guides, reference manuals, and similar product information (both printed and online)
• Tutorials
• Project documentation
• Special projects, such as technical support websites, and materials for user group meetings

Technical communication groups operating under the Development Shop Model usually report to a manager or director of technical of product development or of technical or customer support rather than the top executive in software development (except in the smallest organizations). Groups operating under this model are usually kept informed of product development plans and may receive opportunities to comment on the plans. But these groups usually do not have the right to approve or disapprove of product development plans.

A technical communication group operating under the Development Shop Model emphasizes these skills:

• Production skills
• Technical writing (both for print and online)
• Inventory control: Managing the quantity of the inventory of information (both printed and online) to minimize costs to the organization. For printed materials, this means keeping an adequate supply while minimizing storage and scrapping of outdated materials. For online materials, this means re-using content whenever feasible
• Project management. Like groups operating under the Agency Model, groups operating under the Development Shop Model emphasize that they follow a proven methodology that allows them to use time most efficiently and produce materials at the level of quality sought by the client

The time frame for projects funded under the Development Shop Model is short- to medium-term (2 to 18 months, depending on the project).

Groups operating under the Development Shop Model have position power within the organization. Position power refers to the “authority and influence bestowed by a position or office on whoever is filling or occupying it” (Business Dictionary.com) (Viewed at http://www.businessdictionary.com/definition/position-power.html, visited July 11, 2009). In other words, technical communicators in groups operating under the Development Shop Model merely have influence because they publish the technical communication products; others in the organization may or may not see additional inherent expertise in those activities.

In groups operating under the Development Shop Model, the value of the technical communication effort is primarily assessed in terms of word-of-mouth from their client organizations. Of particular importance to these clients is the ability of technical communicators to “get” the technical content (that is, the extent to which subject matter experts trust technical communicators to accurately report the technical material) (Carliner, 2012), and the ability of technical communicators to manage projects (more specifically, to bring in the project on schedule and within budget) (Carliner, Qayyum, & Sanchez Lozano, 2012). Other attempts to more substantially measure the value of technical communication products and services are ultimately seen as secondary measures, even though the people who make these attempts take these activities seriously.

The three Product Information Departments that report to Vicki develop the online help, user guides, references, and other content identified in the designs of the User Experience Department. The designs usually state the objectives that the content should achieve, and identify the format and medium used to deliver the content, as well as the guidelines that the content must follow, such as standard sections in help and user guides, and layouts for web content.

The majority of Product Information staffs are technical writers. Each of the three departments also has its own editor and project manager. Technical writers conduct additional research on the content, and prepare detailed outlines. Technical writers develop as many as three drafts of content for review and approval by the same groups before producing the content, publishing it, and providing ongoing maintenance for it. As a result of a new content management system installed in the company, all published topics have an “expiration date,” and technical communicators must review the content, update it, and receive approvals for the updates before republishing the content.

Although the technical writers and editors working in Product Information Departments receive strong training on company products and underlying technologies, the Vice President for Research and Development requires that all content produced by the Product Information Departments be reviewed and approved by the User Experience staff and software developers—software engineers, product developers, and similar technical experts. That is, Product Information Departments do not “own” the content they produce.

When the company decides to develop a new product or service, the approval covers funding needed by Product Information. Rather than the managers of the Product Information departments submitting requests for funds, Vicki does so on their behalf. Typically, the Product Information groups receive 10 percent of a project budget. When she first assumed her job, Vicki argued for a higher percentage on some projects but Research and Development executives always balked at the additional expense so she has not tried for the past three years. Vicki also learned that these executives do not approve funding for great ideas that emerge while the project is under development, so she encourages Product Information staffs to do “innovative thinking” as early as possible on a project so she can include it in initial budget requests.

Model 5: Technical Support Model

This model describes organizations in which technical communicators work with groups that provide technical services to their organizations, such as Information Systems (IS) and Information Technology (IT) groups. Typically, technical communicators working under the Technical Support Model provide ongoing training to users, prepare documentation about all internal applications (whether or not those applications are strategic), maintain an internal knowledge base for the help-line desk, and prepare specifications and other internal documents (Hovde, 2010). Although groups operating under this model usually support an IT/IS group, sometimes, they support other groups, like repair teams (Carliner, 2012).

In the Technical Information group that Vicki leads, the fourth Product Information Department operates under the Technical Support Model. This is the department that reports to Vicki but works on contract to another division of the company.

Organizations operating under the Technical Support Model are funded on an apportionment basis.

Like information produced by groups operating under the Development Shop Model, technical communication products published by organizations working under the Technical Support Model typically support a strategic effort in the organization, although the technical information on its own is not considered strategic. Communication products published by groups operating under the Technical Support Model typically include:

• Help
• Training materials (often self-study)
• User guides
• Reference materials, especially for use by internal technical experts
• Newsletters for frequent users
• Lists of frequently asked questions

These groups also publish design specifications, although they typically do not write the original content—they edit the work of others. The content published by groups operating under the Technical Support Model is typically intended for internal audiences.

Groups operating under the Technical Support Model usually report to the manager or director of technical support, or directly to the manager or director of IT/IS.

A technical communication group operating under the Technical Support Model emphasizes these skills:

• Writing
• Instructional design
• Facilitation: Leading live and webcast training classes and similar presentations (Hovde, 2010)
• Production
• Marketing
• Customer service

The time frame for projects funded under the Technical Support Model is short-term (three or fewer months) or ongoing, such as training classes that might be offered once a quarter and newsletters (although producing an individual issue of a newsletter is a short-term project, responsibility for a newsletter is ongoing). Groups operating under the Technical Support Model usually complete a high volume of projects.

These groups typically have position and, occasionally, referent power within their organizations. Although they usually do not participate in the design or customization of information systems used within the organization, they usually serve as the face of the IT/IS organization as these technical communicators help users navigate through systems.

In organizations operating under the Technical Support Model, the value of the technical communication effort is primarily assessed by word-of-mouth, the number of products and services published, and the number of people served.

The Technical Support Department that reports to Vicki supports the corporate Information Technology (IT) group. The IT department originally used outside contractors for its technical communication needs. But when told four years ago by the Vice President for Research and Development that she would have to lay off 10 percent of her staff, Vicki asked if she could retain them if she could find work and, knowing about the situation in IT, she immediately proposed that the Chief Information Officer contract with her team rather than outside companies. In that the workload of this fourth Product Information Department involves a wide variety of short-term projects, some of which occur on an ongoing basis and others occur only once or twice a year, if that frequently, it shares much in common with the Special Projects team that operates under the Agency model.

But the nature of those assignments and the skills needed sharply differ. This department has responsibility for all of the user guides, online help, references, and training for all applications supported by the IT group. This Product Information Department customizes documentation for commercial applications used in the company and creates original content for custom applications developed by the IT staff. Although the IT staff is large, its workload exceeds capacity so the IT staff cannot promise to review all of the documentation produced by the fourth Product Information Department. The technical communicators must take full responsibility for the technical accuracy of their content.

Similarly, because the fourth Product Information Department works on contract to the IT group—and that work might need to be outsourced to independent companies again in the future—these technical writers must use standard, off-the-shelf authoring tools that require little or no additional training. As a result, this Product Information Department does not use the content management system used by the rest of Vicki’s staff.

This fourth Product Information Department has a long-term (five-year) contract with the IT group, but the IT group wrote the contract so that they have the option each October to cancel the contract with three months’ notice. The long-term contract provides some job security for the department, but not so much that the staff feels comfortable. Furthermore, because the commercial software developed by MegaCorporation is significantly more complex than the custom applications and commercial software used by the IT group, technical writers working in this Product Information Department have faced barriers transferring to one of the other three Product Information departments.

In addition, because outside contractors continue to compete for the work, competitive pressures limit what Vicki can charge for this service. But her group does generate a profit, which provides a financial cushion if the IT Department cancels the contract and the group needs to seek out new customers, as the department manager is currently recommending.

Model 6: Contractor Model

This model describes organizations in which technical communicators either maintain large libraries of existing technical content, or prepare new technical communication products that primarily require production work—and little else—before they are ready for publication. Sometimes, these groups work internally but, just as frequently, they work as external contractors. On most projects operating under the Contractor Model, technical communicators serve as a “scribe” (that is, they record the proceedings without making substantive contributions) or oversee production. Groups operating under the Contractor Model offer few if any original contributions to the content; rather, they ensure its ongoing completeness and accuracy. Projects conducted under the Contractor Model also are usually ongoing, yet not full-time jobs, so organizations usually hire someone to handle the work part-time for an indefinite period of time (as described by Glick-Smith 1999 and like the Editing and Production group described in Kove & Drexler 1998). The typical practice of hiring contractors to perform this work provides the name for this model.

In the Technical Information group that Vicki leads, the Maintenance Department operates under the Contractor model. So does the agency that supplies 13 contractors to Vicki’s group.

Organizations operating under the Contractor Model are funded in one of two ways: for time and materials (that is, time worked plus reimbursement of exceptional business expenses) or apportionment (internally; external organizations would receive a project payment, usually paid in installments after completing agreed-upon milestones). In either funding scheme, organizations paying for the service seek to minimize costs by controlling hourly rates or limiting the total number of hours that technical communicators work.

In some instances, the technical information published by organizations working under the Contractor Model is intended for compliance with a governmental, corporate, or industry rule or standard. In other instances, technical information published by organizations working under this model supports customers who have not upgraded to newer and more strategic products. Although this ongoing support is required, the content that is published is not viewed as strategic within organizations.

Groups operating under the Contractor Model typically work in the manufacture of heavy equipment and military and space technology as well as the development of mainframe computer systems. These products and services have long life cycles (some lasting decades) and have much documentation requiring ongoing maintenance. Specific types of content produced include:

• Minor revisions to existing documentation (in which technical content is updated without substantive changes to its presentation)
• Documentation of product specifications devised by subject matter experts
• Programming documentation, especially that which is intended to be used internally to the organization or by highly expert users
• Production services for documentation written and assured by others (copyediting, transfer to a publishing system such as FrameMaker or CMS, and publishing oversight)

Organizations operating under the Contractor Model typically report to an operations manager, publications manager, or head of a contracting agency.

A technical communication group operating under the Contractor Model emphasizes these skills:

• Production
• Copyediting: Identifying and correcting typographical and stylistic errors (within the framework of an agreed-upon style guide and dictionary) and marking a draft for production
• Understanding of the technology that’s the topic of the communication products being developed

Most significantly, a technical communication group operating under the Contractor Model emphasizes the importance of in-depth knowledge of the structure of the library of content so that all of the affected content can be revised when needed. Because this in-depth knowledge of the library structure is needed, many organizations often hire back their retired workers on contract to perform this work.

Projects funded under the Contractor Model have two time frames. For funding purposes, they are long-term projects, because they require ongoing work. For actual project management, projects are short-term or ongoing. That is, the technical communication group usually begins work as the product update effort nears completion, and clients need revisions quickly

Groups operating under the Contractor Model have position power. The value of the technical communication products produced under the Contractor Model is primarily assessed in terms of word-of-mouth, speed (the quicker the turn around, the more effective the service is perceived), and cost (the lower the cost, the higher the perceived benefit of information design and development) (Carliner, 2012; Carliner, Qayyum, & Sanchez Lozano, 2012).

The Maintenance Department that reports to Vicki and the contractors who work with them maintain all of the legacy documentation (the user guides, references, and other technical content about discontinued and older software that the company still markets to satisfy the needs of long-time customers but in which it invests limited effort). Most of the work involves making specific changes to words or paragraphs within content; most maintenance rarely involves adding full topics much less entire sections. Technical writers who work on maintenance projects need a strong familiarity with the content they maintain so they can quickly and easily find all passages requiring changes. Because the company wants to minimize maintenance costs, Subject Matter Experts do not closely review revisions and technical writers working must have sufficient technical knowledge of the software that they can validate their content. Technical writers are also responsible for producing final copy and publishing it online. (Very little “maintenance” content is printed.)

Partly because legacy products are no longer strategic to the company so budgets for maintenance are minimal, and partly because revisions respond to unanticipated problems rather than planned updates to the applications, the manager of the Maintenance Department seems especially focused on controlling costs. Similarly, because the projects maintained no longer have strategic value for MegaCorporation, most of Vicki’s staff perceives of maintenance assignments as “dead-end.” In fact, many of the contractors working on these projects are retired members of Vicki’s staff.

Table 1 summarizes the key characteristics of this, and the five other common business models for technical communication groups.

What Are the Most Common Business Models for Technical Communicators?

To read the literature on technical communication, especially the literature on usability and information design, one might get the impression that information designers and developers operate under the Design Model (such as Albers 2002, Ames 2001, and Dykstra 2001). But case studies (such as Hovde, 2010 and Kain, 2006) and surveys of actual management practice (such as Carliner 2004; Carliner, Qayyum, & Sanchez Lozano, 2012) suggest that, in reality, most information design and development groups operate under the Development, Technical Support, and Contracting Models.

Many technical communication groups actually operate under mixed models. That is, some parts of the group operate under one model while other parts of the group operate under another. The example used to illustrate the six business models is based on an actual case of a director who, after reflecting on the differing natures of the departments in her group, concluded that “I essentially manage many different businesses.”

Table 1: Summary of the Key Characteristics of the Dominant Business Models for Technical Communication Groups

Model	Types of projects	How the group receives funding	Role of information	Typically reports to	Skills	Time frame for projects	Type of power	Measures of success
Venture Capital Model	Content published for sale	Per project	Strategic	Venture Capitalists	Financial management Business leadership Project management Information architecture Interface, information, and experience design Technical communication skills Customer service	Medium- to long-term (12 to 30 months)	Leadership Referent Financial	Return on investment
Design Model	Websites (designing the architecture and overseeing the implementation) User interfaces Designed-in information (such as all of the on-screen content for an application and the keytop names on specialized keyboards) Information that’s external to the software, such as help, manuals, sales materials, and training	Per project	Software development executive	Software or product executive (and, in a few cases, CEO)	Business leadership Project management Information architecture Interface, information, and experience design Technical communication skills Customer service	Medium- to long-term (12 to 36 months)	Leadership Referent	Revenue generated Ability to respond to input from others inside and outside of the organization Results of surveys and usability tests
Agency Model	Marketing communication (white papers, marketing collateral (brochures), sales-promotion materials (flyers)) Employee communication (like employee handbooks) Other high profile content (short online demonstrations, materials for trade shows, video presentations, and interactive media presentations)	Fee for service (either time and materials or project basis)	Support or cosmetic	Communications manager	Project management Creative problem solving Relationship marketing Production Technical writing Instructional design Graphic design	Short-term (3 or fewer months)	Referent	Word-of-mouth Repeat customers
Development Shop Model	Supports a strategic effort Help, user’s guides, reference manuals, and similar product information (printed and online) Tutorials Project documentation Special projects, such as technical support websites, and materials for user group meetings	Apportionment	Support	Manager or director of product development (rather than the top executive in software development), or of technical support	Production skills Writing for print and online Inventory control Management	Short- to medium-term (2 to 18 months)	Position	Word-of-mouth Ability to manage projects Ability to “get” technical content
Technical Support Model	Help Training materials (usually self-study) User guides Reference materials, especially for use by internal technical experts Newsletters for frequent users Lists of frequently asked questions Design specifications	Apportionment	Support	Manager or director of technical support Manager or director of IT/IS	Writing Instructional design Facilitation Production Marketing Customer service	Short-term (3 or fewer months) Ongoing	Referent	Word-of-mouth Number of products and services published Number of people served
Contractor Model	Products and services have long life cycles (often lasting for decades) and have documentation requiring ongoing maintenance Minor revisions to existing documentation Product specifications Programming documentation Production services	Time and materials Apportionment	Compliance	Operations manager, publications manager, or head of a contracting agency	Production Copyediting Understanding of the technology that’s the topic of the communication products being developed In-depth knowledge of the structure of the library in which the content being revised is published	For funding purposes, long-term. For actual project management, short-term or ongoing	Position	Word-of-mouth Speed Cost

Applications Of Business Models to the Theory and Practice of Technical Communication

Practicing professionals in the field might wonder how they can apply business models in their work. As this is not a prescriptive theory—that is, a series of recommended actions intended to achieve a particular outcome—it comes with no recipe for technical communicators to follow to change their positions within their organizations.

Rather, the theory of business models is a descriptive one, which provides insights into the situations in which technical communicators find themselves working. At the least, the new perspectives provided by this description might help technical communicators better understand why their organizations operate in the ways they do. At the most, technical communicators might see opportunities in the description that are unique to their work environments and that they can exploit for their benefits.

More specifically, as a descriptive theory, business models provide an alternative view of the management and operations of technical communication groups, and provide an alternate means of classifying technical communication groups on the nature of their funding, rather than to whom they report, their size, or the industry in which they work. More fundamentally, this alternative description of technical communication groups provides a theoretical explanation for the differences among groups, explaining not only the different type of projects on which technical communicators work vary among groups, but also explaining why different skills are valued in different situations and, more significantly, why some technical communication groups seem to have more influence than others. This section explores each of these and related implications, as well as limitations of the business models.

Implication 1: Different Models Suggest Differences in Assignments among Technical Communication Groups

The first implication of business models is that they suggest the types of projects on which technical communicators work—and the ones from which they will be excluded. Although business needs determine whether an organization needs minor maintenance to existing content, new user interfaces and related information, or something in-between, business models suggest what might drive an organization to choose one over the other.

For example, if an organization wants to control costs and they have typically hired technical communicators under the Development Shop Model, then they are not likely to consider technical communicators the next time a new user experience is designed. Consider the three Product Information departments reporting to Vicki. They received all of their funding at the beginning of a project; Vicki could neither change the timing of the funding nor its scope.

Implication 2: Different Models Place Differing Value on Particular Skills

As a result of the differences in projects among business models, different types of skills are needed in organizations operating under different types of business models. This is the second implication of business models.

Several studies using different methodologies have attempted to identify a common set of competencies needed by technical communicators (Hart & Conklin, 2006; Lanier 2009; Rainey, Turner, & Dayton, 2005; STC Certification Committee, 2011), often for the purpose of designing an academic curriculum in technical communication. By nature, these studies have emphasized the similarity of work across organizations.

Practicing technical communicators often object to these studies because, in their personal experiences, they see more variation than similarity. For example, practicing technical communicators notice that some organizations place a greater emphasis on production skills, others place a greater emphasis on subject matter expertise, and others emphasize user interface design skills as demonstrated in the examples of departments in Vicki’s group.

Business models provide a theoretical explanation for the variation, and a basis for further exploration of those differences.

Implication 3: Departments Operating Under Different Models Benefit from Different Placements within Organizational Structures

As the skills needed vary, placement of technical communication groups within an organizational structure also varies. This is the third implication of business models. Placement of technical communication groups within an organizational structure generates strong interest among technical communicators (Wishbow, 1999), many seeking an “ideal” placement: Marketing? Product Development? Operations? Something else?

Business models have the potential to refocus of such conversations from the “ideal” placement to placement best suited to the business model under which the technical communication group operates. Appropriate placement of a group operating under the Design Model differs from a group operating under the Technical Support Model.

Implication 4: Different Business Models Place Differing Levels of Value on Technical Communication Products and Services

Given the different nature of work underlying each of them, business models also suggest the type of value that organizations might place on technical communicators products and services, the fourth implication of business models. Although this issue has received more empirical focus than some of the others, and methodologies have been developed and replicated (Carliner, Qayyum, & Sanchez Lozano, 2012; Mead, 1998), that authors continue to lament the limited value that organizations place on technical communication (Hovde, 2010; Spilka, 2000) suggests that technical communicators still lack a theoretical basis for describing how organizations place a value their products or services.

Business models fill that theoretical gap. Consider the differing levels of influence of the departments reporting to Vicki. The Press and User Experience Departments have extensive influence, and seem to have extensive control over their own destinies. In contrast, the Agency, fourth Product Information, and Maintenance Departments have the least influence and control over their destinies. These departments also have limited control over their work and face greater threats of losing their jobs to outsourcing. These situations reflect the business models under which these three departments work.

Implication 5: Different Business Models Provide Technical Communication Groups with Differing Levels of Control over Their Destinies

This difference in control over destinies suggests the fifth—and perhaps most significant—implication of business models. Some researchers who observe technical communicators in their work settings express concern about their “second-class status” (Hovde, 2010) and that “technical communicators are often undervalued and perceived as grammarians only” (Spilka, 2000, p. 219). Even Hovde’s empirical evidence suggests that the status of technical communicators actually varies among organizations.

Business models provide an explanation of why. The source and nature of power (referent in some models, position in others) partially explains differences in status among technical communicators working in different organizations, as does the different nature of skills needed on projects. For example, models like the Venture Capital and Design Models, let technical communicators demonstrate leadership, others, like the Development and Contractor Models, don’t.

Limitations of This Theory

Although the concept of business models suggests explanations for several key concerns of practicing technical communicators, it has limits. First, it is a theoretical construct and, as such, essentializes the many complex environments in which technical communicators work into six broad categories. The six business models help technical communicators see broad differences among groups but these models might oversimplify the actual working environments of technical communication groups. As noted earlier, some technical communication groups might exhibit characteristics of two or more models at any given time.

A second limitation is that the descriptions of work performed by different types of technical communication groups, the skills these groups need, as well as their placement and influence within organizations, are propositions that represent one interpretation of empirical data. Other interpretations may exist.

That, in turn, suggests the third limitation of the concept of business models. Not only have the relationships within specific models not been empirically validated, the relationships among the specific models have not been validated. In practical terms, that means that the concept of business models only explains what technical communication groups might experience under a given business model, it does not suggest how technical communication groups try to might change the model under which they operate and the types of challenges that might arise should they choose to do so.

These limitations suggest, in turn, two paths of future research. One would attempt to validate these models. These models could be validated qualitatively by observing the inner workings of several technical communication groups and determining the extent to which these models describe their operations. The models could also be validated quantitatively, through an instrument that contains constructs for each of the characteristics and links scores on these indexes with specific business models. Assuming the research validates business models, the second path of research would explore the challenges that technical communication groups experience when moving from one model to another. Such research could ultimately result in models to describe the transitions of technical communication groups.

References

Afuah, A., & Tucci, C. (2000). Internet business models & strategies: Text and cases. New York, NY: McGraw-Hill Higher Education.

Albers, M. (2002). Design considerations for complex problem-solving. Proceedings of the 49th Society for Technical Communication Annual Conference. Arlington, VA: STC.

American Advertising Museum. (1992). Text label for permanent exhibition. Portland, OR.

Ames, A. (2001). Advanced toolkit for experienced technical communicators: Whose UI is it, anyway? Skills and resources for moving beyond traditional documentation deliverables. Proceedings of the 48th Society for Technical Communication Annual Conference. Arlington, VA: STC.

Bails, J. (2009). Workout. Carnegie Mellon Today, 6(3). Retrieved from http://www.carnegiemellontoday.com/index.asp?vid=21.

Berkenkotter, C., & Huckin, T. N. (1995). Genre knowledge in disciplinary Communication: Cognition, culture, power. Mahwah, NJ: Lawrence Erlbaum.

Boiko, B. (2009). Keynote, Intelligent Content 2009. Palm Springs, CA: January 29-30, 2009.

Carliner, S. (2003). Physical, cognitive, and affective: A three-part framework for information design. In M. Albers & B. Mazur (Eds.), Content and complexity: Information design in technical communication (pp. 39-58). Mahwah, NJ: Lawrence Erlbaum.

Carliner, S. (2004). What do we manage? A survey of the management portfolios of large technical communication departments. Technical Communication, 51, 45-67.

Carliner, S. (2012). Comparing metrics: A qualitative study of the measures used to assess corporate communication, technical communication and training staffs. Manuscript submitted for publication.

Carliner, S., Qayyum, A., & Sanchez Lozano, J.C. (2012). What measures of productivity and effectiveness do technical communication managers track and report Manuscript submitted for publication.

Carr, D. (2009, August 2). 10 years ago, an omen no one saw. The New York Times. Retrieved from http://www.nytimes.com/2009/08/03/business/media/03carr.html

Chesbrough, H., & Rosenblum, R. S. (2002). The role of the business model in capturing value from innovation: Evidence from Xerox Corporation’s technology spinoff companies. Industrial and Corporate Change, 11(3), 529-555. Retrieved from http://www.hbs.edu/research/facpubs/workingpapers/papers2/0001/01-002.pdf.

Clifford, S. (2009, December 15). Magazines get ready for tablets. The New York Times. Retrieved from http://www.nytimes.com/2009/12/16/business/media/16adco.html?_r=1&em=&pagewanted=all

Cooper, A. (1999). The inmates are running the asylum. Indianapolis, IN: Sam’s.

Dykstra, P. (2001). From tech pubs to information management. Proceedings of the 48th Society for Technical Communication Annual Conference. Arlington, VA: STC.

Flower, L., & Hayes, J. R. (1981). A cognitive process theory of writing. College Composition and Communication, 32, 365-387.

Fredrickson, L. (1992). Quality in technical communication: A definition for the 1990s. Technical Communication, 39, 394-399.

Glick-Smith, J. L. (1999). Entrepreneurship: Your next career. Intercom, 46(7).

Hackos, J. T. (2007). Information development: Managing your documentation projects, portfolio, and people. New York, NY: John Wiley.

Hackos, J. T. (1994). Managing your documentation projects. New York, NY: John Wiley.

Hamilton, R. (2009). Intelligent content: Day 2 [Web log post]. Retrieved from Managing Writers blog website: http://rlhamilton.wordpress.com/2009/02/

Hart, H., & Conklin, J. (2006). Toward a meaningful model for technical communication. Technical Communication, 53, 395–415.

Harvey, M. (2008). Don’t let your work become a commodity. Intercom, 55(1),19-21.

Hellman, T. (1994). Financial structure and control in venture capital (Unpublished doctoral dissertation). Stanford University, Palo Alto, CA. Retrieved from http://strategy.sauder.ubc.ca/hellmann/pdfs/Dissertation.pdf

Houlihan, D. (2009). Technical communications as a profit center. Boston, MA: Aberdeen Group.

Hovde, M. R. (2010). Creating procedural discourse and knowledge for software users: Beyond translation and transmission. Journal of Business and Technical Communication, 24, 164-205.

Hughes, M. (2003). Usability and knowledge sharing. Upper Saddle River, NJ: Prentice-Hall.

Kain, D. J. (2006). Constructing genre: A threefold typology. Technical Communication Quarterly, 14, 375-409.

Keller, K. L. (1993). Conceptualizing, measuring, and managing customer-based brand equity. Journal of Marketing, 57(1), 1-22.

Kline, J. A. (n.d.). Positioning TC as a management function: Ideas to add value to your organization. Retrieved from http://www.docstoc.com/docs/18204359/Positioning-Technical-Communication-as-a-Management-Function

Kove, J., & Drexler, D. (1998). Breaking up is hard to do: Decentralizing a doc group. Proceedings of the 45th Society for Technical Communication Annual Conference. Arlington, VA: STC.

Lanier, C. R. (2009). Analysis of the skills called for by technical communication employers in recruitment postings. Technical Communication, 56, 51-61.

Linder, J., & Cantrell, S. (2000). Changing business models: Surveying the landscape (Working Paper). Accenture Institute for Strategic Change.

Maguire, M. (2008, August). The Nonprofit Business Model: Empirical Evidence from the Magazine Industry. Paper presented at the annual meeting of the Association for Education in Journalism and Mass Communication, Marriott Downtown, Chicago, IL. Retrieved from http://www.allacademic.com//meta/p_mla_apa_research_citation/2/7/2/5/5/pages272550/p272550-1.php

Mead, J. (1998). Measuring the value added by technical documentation: A review of research and practice. Technical Communication, 45, 353-379.

Perez-Pena, R., & Arango, T. (2009, December 2007). Adding fees and fences on media sites. The New York Times. Retrieved from http://www.nytimes.com/2009/12/28/business/media/28paywall.html?hpw=&pagewanted=all

Pfleeger, S. L., & McGowan, C. (1997). Software metrics in the process maturity framework. In P. Oman & S. L. Pfleeger (Eds.), Applying software metrics (pp. 125-140). Los Alamitos, CA: IEEE Computer Society Press.

Power, M. (2009). A designer’s log: Case studies in instructional design. Athabasca, AB: Athabasca University Press.

Rainey, K. T., Turner, R. K., & Dayton, D. (2005). Do curricula correspond to managerial expectations? Core competencies for technical communicators. Technical Communication, 52, 395–415.

Redish, J., & Ramey, J. (1995). Adding value as a professional technical communicator. Technical Communication, 42, 26-39.

Rich, F. (2009, May 9). The American press on suicide watch. The New York Times. Retrieved from http://www.nytimes.com/2009/05/10/opinion/10rich.html?ref=opinion&pagewanted=all

Robinson, D., & Robinson, J. (1989). Training for impact. San Francisco, CA: Jossey Bass.

Schriver, K. (1997). Dynamics of document design. Creating texts for readers. New York, NY: John Wiley.

See, E. (1995). Moving toward an entrepreneurial model: Providing technical information services within a large corporation. Technical Communication, 42, 421-425.

Society for Technical Communication. (2002). Membership survey. Arlington, VA: STC.

Spilka, R. (2000). The issue of quality in professional documentation: How can academia make more of a difference? Technical Communication Quarterly, 9, 207-220.

Spinuzzi, C. (2003). Tracing genres through organizations: A sociocultural approach to information design. Cambridge, MA: MIT Press.

Spool, J. (2008). Why understanding business models is important to interaction design. Retrieved from User Interface Engineering: http://www.uie.com/brainsparks/2008/09/25/why-understanding-business-models-is-important-to-interaction-designers/

STC Certification Commission. (2011). Candidate instructions for STC certification: Alpha version. Arlington, VA: STC Certification Commission.

Storey, S., & Hartman, P. (2000). Starting and maintaining a documentation department: Concepts, principles and techniques. Proceedings of the 47th Society for Technical Communication Annual Conference. Arlington, VA: STC.

Subramony, M. (2006). Why organizations select some human resource management practices and reject others: An exploration of rationales. Human Resource Management, 45, 195-210.

Swales, J. M. (1990). Genre analysis: English in academic and research settings. New York, NY: Cambridge University Press.

Villachica, S. W., Marker, A., & Taylor, K. (2010). But what do they really expect? Employer perceptions of the skills of entry-level instructional designers. Performance Improvement Quarterly, 2(4), 33-51.

Weill, P., Malone, T. W., D’Urso, V. T., Herman, G., & Woerner, S. (2005). Do some business models perform better than others? A study of the 1000 largest US firms (Unpublished paper). Retrieved from http://ccs.mit.edu/papers/pdf/wp226.pdf

Weill, P., & Vitale, M. R. (2001). Place to space: Migrating to eBusiness models. Boston, MA: Harvard Business School Press.

Wishbow, N. (1999). Home sweet home? Where do technical communication departments belong? Journal of Computer Documentation, 23(1), 28-34.

About the Author

Saul Carliner is Director of the Education Doctoral Program and an associate professor in the Department of Education at Concordia University. A two-time recipient of the Best of Show Award in the Frank R. Smith Outstanding Article competition, he also serves as editor-in-chief of the IEEE Transactions on Professional Communication and a board member of the STC Certification Commission and the Canadian Society for Training and Development. Contact: saulcarliner@hotmail.com.

Manuscript received 26 February 2010; revised 31 July 2011; accepted 15 November 2011.

---

Appendix: Applying the Models

Instructions: To consider the applications of the six business models in practice, try the following activity:

• Read each situation.
• For each, determine which of the six models applies. (Hint: for simplicity, each model applies once and only
  once in this exercise.)
• Compare your responses with those in the “answers.”

Situations:

1. Your software development organization is preparing release 3 of its main software application. Your group developed the help and documentation that accompanied the first release. As the market planners and system architects complete the list of features for the release, the software development organization invites you to a kick-off meeting to begin development and seek your ideas for improving the user assistance. Because it’s early in the release, the software development team welcomes your ideas (though that’s not any guarantee they’ll do anything about them). What they expect, however, is that you’ll update the help, produce some new “show-me help” videos, and provide other user assistance that they deem necessary for this new release.
2. You have an idea for a book about solar power. You receive money to develop the general book from an investor. After you complete development, you print the book and sell individual copies to the public. You published 1,500 and need to sell 793 to recover all of your up-front expenses. You split the profit on the remaining copies 50-50 with the investor. By the end of the first year, you have sold 1188 copies.
3. Your company produces a military system, which was first deployed a decade ago. These days, your company updates the military system twice annually to keep up with changes in technology, the political landscape, and staffing. Each time the system is updated, so is the documentation. On the one hand, the task is not a particularly complex one because it merely involves technical updates (usability improvements at this point are few because the documentation is old and the user base is stable). The work requires an in-depth knowledge of the content and library structure so that all of the affected content can be changed.
4. You have been asked by the hardware engineers in your organization to prepare a display, white paper, flyer, and “a cute give-away” for a trade show that they’re attending in six weeks. The engineers have already drafted copy for the white paper and flyer, and have definite ideas about the booth. But they need editorial assistance in “whipping those papers into shape,” graphics assistance with the booth, white paper and flyer so they all become “standouts;” and need your creative ideas about the give-away. None of these projects were in any budget for the year, but now that the engineers have deemed them necessary, budget is not a problem. Schedule is. All you need to prepare is a proposal, and it’s likely the work will be yours (if you can find someone to handle the tight schedule, that is).
5. You work in a software development organization for an office supplies chain that is developing an app for e-commerce. Although your company owns brick-and-mortar stores, the app provides an alternate means of selling products to the public. Your technical communication group will lead the development of this app in the company. Your group will identify all of the needs, develop objectives, plan the designs and choose the technologies, oversee development of the content as well as the programming, conduct usability and functional tests of the app, oversee its launch, and ensure timely and effective maintenance after the launch.
6. You are one of two technical communicators working for the Help Desk of your Information Systems (IS) group. Others in the IS group manage and staff the Help Desk, or produce and support internal software. You two technical communicators try to help users develop their self-sufficiency, which should reduce future calls to the Help Desk. So you two produce newsletters and specialized user’s guides (the ones telling the “real” story that the manufacturer’s guides never tell). You teach 1- and 2-hour mini-seminars on specific topics. You occasionally produce online tutorials. You maintain the list of Frequently Asked Questions. And you organize the three-times-a-year open houses for the department.

Answers: 1-Development Shop. 2-Venture Capital. 3-Contractor. 4-Agency. 5-Design. 6-Technical Support.