Organizational Positioning

Charles Dowdell, The Raymond Corporation

Bill Hackos, Comtech Services, Inc.


On December 17, Charles Dowdell posed some questions on the Comtech Listserv: Does anyone have any success stories of where Tech Pubs resides organizationally? What makes the most sense organizationally? We present a summary of responses below.

Charles Dowdell and Bill Hackos would like to thank all of the participants who offered their comments about corporate organization involving technical publications departments. We have put together a tabular summary of comments, and a graphic displaying the frequency of corporate situations. We have also put together an edited version of all the comments editing out names and companies to preserve the privacy of the respondents.

We have not found a solution that fits all organizations. Many of the comments mentioned that the optimal placement of a Tech Pubs group depends on details about the environment within the corporation as well as its business model and product spectrum. We have been impressed that most of the respondents felt that their situation was favorable if not always ideal.

Our suggestion is that you, as a manager of a Tech Pubs group, are the best capable of making a decision about where your group belongs. While it is certainly of interest to know what everyone else is doing, your decision or your management’s decision will depend more on the situation within your company than an of external standard.

Same ability as R&D to hold up the product release. Engineering or marketing don’t contribute to the documentation reviews. It is easier to report high up in Product Management than in R&D. Being in Product Management enables Tech Pubs to be involved in a project from its inception.

Tabular Summary—Advantages and Disadvantages

Organization Other Name Advantages Disadvantages
Support Technical Support, Customer Service The goals for Tech Pubs and Support are the same: meeting customer needs for support of application software.Support can provide Tech Pubs with feedback. Support does not have the intimate knowledge of the product that engineers do.
R&D Engineering, Software Engineering, Hardware Engineering, Development Work with same customer requirements, budget, and schedule.Tech Pubs more visible to SMEs.  High up in R&D works best. With corporate move to XML, Tech Pubs is fully aligned with R&D teams processes.

Tech Pubs can help to define and evolve product specification.

Only works if Tech Pubs is not in competition to R&D in funding. R&D may not be customer focused.
Marketing If organization is focused on marketing info, Marketing may be a good fit.


Rarely good – Differing focus and skill sets.
Cross Functional User Assistance, Knowledge Services,     “mini-IT” Level equal to development or support.Same ability as R&D to hold up the product release. Engineering or marketing don’t contribute to the documentation reviews.
Product Management New Product Introduction (NPI) It is easier to report high up in Product Management than in R&D.Being in Product Management enables Tech Pubs to be involved in a project from its inception.


Where are the respondents residing now?



Comments from the Listserv respondents

I’ve seen tech pubs work well in two organizational units:

    • Operations/Support > keeps tech pubs close to the customer
    • R&D > keeps tech pubs close to the product development process

Either can work well. Being positioned within Marketing is rarely good in my opinion – different focus and skill sets.


Having been in a Tech Pubs group that existed in engineering, customer support, R&D and marketing at various points in history, I can tell you that they all have their drawbacks. Personally, I’ve always felt that Tech Pubs should be organized as a cross-functional service group, similar to accounting or IT, under a Chief Knowledge Officer (or executive with similar responsibility) as it sources multiple departments to develop content.


We report to engineering. We have been bounced around a few times over the years, reporting to different groups, but engineering seems like the best fit for us. Our product documentation is delivered to the customer along with engineering’s hardware and software products, so we work to the same customer requirements, budget, and end schedule. Also, reporting to engineering helps keep Tech Pubs more visible to the SMEs, who are primarily engineers. A second choice would be moving into education and training or usability, if either of those exist.


My experience with large, high-tech companies is that a centralized organization reporting HIGH UP in either R&D or Product Management works best; HR, marketing, or services are less desirable. However, the organizational location is not the only important factor. Reporting low in an organization without support, or reporting to a group that does not share common goals with Tech Pubs group makes for a more difficult challenge.

My own experience is product management works best because its easier to report higher in the organization, they see the whole product and product life cycle, have a more balanced funding perspective, and often see (if can be convinced) that documentation as an integral part of the product. R&D can also work, but only if documentation is not in competition for the same funding dollars. If funding is scarce and you are part of R&D, they will likely get the money and you won’t. If reporting high in the R&D organization, management may more easily see the value of documentation and help ensure you get your appropriate funding amount. The worst org position is one of “overhead” like HR, marketing, or services. Overhead is something to cut, and services constantly works to drive down cost and increase service revenue, neither of which fits the documentation model very well.

At the end of the day, the organization position needs to be one that provides appropriate levels of funding, appreciates the value of documentation, and cares about customer satisfaction. No matter where you end up, you will need to spend a lot of time promoting the value proposition of documentation.


Similar to others who’ve responded, our Technical Communications team has been in Mktg, Eng, RnD, and other (such as a “mini-IT”). In my experience, the best org alignment depends on factors in the larger environment.

      • If your tech writers are focused on one part of the business and the associated content, then alignment to that org makes sense. For example, if you are focused on marketing info, then alignment to mktg may be the right place.
      • If your team serves multiple functional teams (mktg, eng, RnD, manufacturing, other) then an IT type model makes the most sense.

Also, in the Desktop Publishing era, with distributed content management, localization, and publishing systems, tech comm teams tend to be organizationally “all over the place”.

As the industry continues toward the Database Publishing era, with XML/DITA content and new authoring tools, centralized Content Mgmt Systems, and the higher demand for localization, and more rigorous guidelines for web publishing, we all should strive for more centralization in an IT type model, to ensure optimum efficiency.


We fit fairly well within the product management organization since they manage the features and functionality of our products. This enables us to be involved from inception.


We have four large and two smaller information development teams in different Groups within the company, and they don’t all have the same reporting structure. But three of the four large teams now report into R&D functions following the reorg (I’m not sure where the two smaller ones ended up reporting). Of course, they have dotted-line responsibility to the product marketing functions, since all customer-facing information deliverables flow through the ID teams. The fourth remains reporting solid-line to a product marketing while having dotted-line relationships to their R&D functions.

One of the things that makes the ID function make sense within an R&D organization is our corporate move to XML content creation and delivery processes. In order to best leverage XML information reuse, the ID teams must be much more integral to the product definition, design and delivery processes, and thus it is critical that they’re fully aligned with the R&D teams’ processes.

I think you and I talked about this sort of thing over breakfast or lunch at the BP conference in Atlanta, which was before our reorg. The key think we’ve been focusing on is “get the data right as early in the process as possible”, because only then will you be able to build on-demand information deliverables with a high level of quality. That means getting the ID teams right in the middle of the R&D processes from day one.


I have managed tech pubs groups in various organizations, including Engineering, Marketing, and (currently) NPI Program Management.

The most productive and rewarding time for me was when my group, Information Development, was on equal footing with Hardware and Software Engineering, as opposed to a support group for Engineering or Marketing. The company essentially viewed hardware, software, and information as the three key components of every product we sold. This meant that I could (and did) hold up product releases if Engineering and Marketing didn’t step up and do their part when it came to providing source material or timely reviews. Quality was exceptional as a result, and customers went out of their way to let us know how much they liked the documentation. This did a lot for morale in all departments.

That organizational structure may be rare, though. I only experienced it twice in my career, and in the second instance it didn’t work well, because the company never actually bought into the idea that customer documentation was a critical component of the product. So if Engineering and Marketing didn’t feel they had time to contribute, they just didn’t.

When all is said and done, valuing documentation, I think, is the great equalizer. If your company understands how important documentation is to the customer experience, I believe you can be successful in any organizational structure.


This is a very pertinent question for our group. For many years the Technical Publications department was associated with the Product Development department, which seemed like a natural fit, since most of our technical documentation is driven by the software release cycle. However, there is the drawback that Product Development is not customer-focused but project-focused. Product Development writes business plans to support developers in writing the software, not customers in using it, so a great deal of “translation” from developer-orientation to user-orientation is required. There is a large logical disconnect between the two groups, who often find themselves working at cross purposes.

Our Technical Publications department was recently moved under Support. This makes more sense from several perspectives:

      1. The goals of Technical Publications and Support are the same: meeting customer needs for support of our application software.
      2. Support can provide Technical Publications with feedback on the most frequent support calls so that we can address user problem areas earlier in our documentation, which in theory will reduce support calls over time.
      3. Both Support and Technical Publications are service organizations: one provides telephone service, the other documentation services, so the group philosophies are more aligned.


I tend to agree with JoAnn Hackos (as I recall from one of her books), that a “centralized” service-like organization (ala IT) is a requirement for achieving a “mature” technical publications organization. That said, where does this “centralized” organization fit within a Company’s organizational structure? It is critical for technical writers (information developers, information architects, editors, etc. et al) to be intimately engaged with product engineering. This ensures that they are “upstream” in the product specification arena. With their technical communication skills, they can even be instrumental in helping to define and evolve product specifications (long before the need of “documentation” emerges). That said, I think it is also critical for technical writers to be closely tied to the Support organization, specifically because of Support’s intimacy with actual users of the product. (I don’t remember who said, but I agree with the tenet that Support representatives and tech writers do the same thing: they help customers get their work done with the tools; they just do it in different ways).

I think the “suite spot” is a centralized organization, reporting into the Customer Support Division, but with fundamentally entrenched development practices in concert with the Engineering groups.


When I worked at XXX, the tech writers were part of a separate organization (User Assistance) that was assigned to a product. We were our own org and worked with the software developers. About a year before I left XXX, we formed teams comprised of the product manager, usability, design, the developer, the writer and the editor. When we started working on a new feature or component, we were all in it together, from the very beginning. I found this to be a great way to work and allowed me as a writer to start writing at the beginning of a project instead of the end.

Where I am now, I am part of the Engineering team and work closely with product management and support. For me, both models work well. I can’t see being part of technical support because they are not developing the product and don’t have the “intimate” knowledge of it as the engineers do.


I’ve been in the large enterprise tech pubs business for over 35 years, and have experienced reporting relationships that included R&D, Support, Marketing, HR, Standards, Product Management, and probably a half-dozen others that I’ve blocked out of my consciousness. Each had pros and cons; none of them was the proverbial magic bullet.

I agree with most of the other observations that have been offered on the list, but have personally come to a different conclusion over the years. Where ‘Pubs’ reports has less to do with its success or effectiveness than the social, political, and leadership skills of the Pubs management team. Pubs operations cross organizational and disciplinary boundaries, and it’s very unusual for anyone outside the direct Pubs line of management to have a clue what it takes to support complex hardware and software with effective, usable documentation. The only thing they typically do ‘know’ is that it costs too much.

In most organizations, cost is the only hard (believable) metric that is visible to the non-participant managers; or at least the only one they understand. The benefit side of the cost/benefit equation is largely invisible, or virtually impossible to ‘prove.’ Success is therefore dictated largely by how well the leadership team, and especially the top dog, are able to educate, evangelize, schmooze, cajole, convince, coerce, or otherwise convert their unknowing peers and superiors in all of the areas that Pubs touches. Where pubs reports only helps in one functional area, but for the most part, you will still be on your own to build healthy relationships with all of the other players.

Charisma and social skills open doors, and with persistence often lead to good results. But results come a lot quicker, and more consistently if you can build a solid business case for putting more focus on Tech Pubs, and maybe even increasing Tech Pubs resources. The good news is that it’s getting easier to do this. If your company is caught up in the globalization frenzy, many of you may now be able to arm your fearless leaders with hard data on the benefits side of the equation. As your company grows it’s business globally, the cost of translating Tech Pubs’ documents to multiple languages will get bigger and bigger, with correspondingly increased visibility and attention.

This increased visibility can be a threat or an opportunity, depending on how your leadership chooses to act. Forward-looking Pubs leaders have done their homework, and found that by focusing on the quality, consistency, readability, and translatability of the English source content up front (one time), their company can realize 15% to 25% (or more) savings in translation cost at the back end (many times). The cost of the first translation of a large technical document may be enough of a shock to get Executive-level attention in your company. If not, the translation to a second language at the same or higher price may raise an eyebrow or two. Sooner or later, the cost of translation will become a topic of concern at the executive level. Being at the table with a plan to minimize translation costs from the beginning couldn’t hurt your cause.

Simply put, time, effort, and $$ invested in Information Development quality improvements upstream, return as much as 25% savings in downstream translation costs, per language! You can project that eventually, translation costs will surpass the Information development budget, and the sooner the focus shifts to Information Development, the more the company will save in translations. Be ready to show them the math.

Hmmmm … maybe Pubs should report to the CFO.


XXX has been the outsourced service provider for a large telecom OEM for over 7 years. Our team is 130 – 160 depending on projects. During that time we have bounced from being part of a larger group inside that organization under the name of knowledge Services, to reporting directly under the New Product Introduction Team which was funded by R&D and Product Management and then back to Knowledge Services.

From a visibility, funding, direct access to information, and inclusion in design engineering calls, by far the best relationship existed when we were part of NPI. Our mandate is to have our information products available 8 weeks before the General Availability of the larger products and less on the smaller projects. The direct contact with the NPI teams enabled them to see the affect of product tweaks at the last minute, churn in specs, and delay in information dissemination. Also because we are a supplier rather than internal…real costs of all the above could be tracked to cause and efficiency improvements could be implemented.

Direct involvement with Marketing, Training, (unless you have already discovered that training belongs with tech pubs anyway), Product Management and R&D, and Customer Service is critical. Time has to be spent at the beginning of each product lifecycle ensuring that the input and needs of all groups are captured. Multiple source input creating single source output that can be used and updated quickly in multiple mediums is the most effective means of decreasing cost while creating even more accurate and consistent information products across all facets of your organization.