... in the world of Technical Communication

Technical Writers are not unique in their struggle to prove they “add value” to an organization. Currently, I’m working for a large, global client in their Enterprise Architecture division. While this client’s main business is not software development, because of the scope of their business they have invested significant resources to support the IT infrastructure and software they need to efficiently conduct their business efforts.

My current team’s challenge within Enterprise Architecture is helping the rest of the global organization understand what they do and why they do it. (Sound familiar?) Today, I was reading through some documentation about Enterprise Architecture based on research Gartner conducted. The particular document that caught my attention was one that was trying to provide a definition for Enterprise Architects.

The definition they crafted was well done – logical and comprehensive albeit a little clumsy simply because of the length (but at times you simply can’t avoid that). As I completed the paragraph, I thought they’d covered it all. Then they proceeded to explain that they needed to clarify a few points because of feedback from some of their customers and analysts.

As I read through their clarifications, I kept returning to the first point they stated: Their definition looks at an Enterprise Architect as a verb (i.e., someone who does something) rather than a noun (i.e., someone who produces things). I thought this distinction was significant, both to Enterprise Architects as well as to Technical Communicators.

It’s long been known that Technical Writers are most often viewed as “expenses” rather than “revenue generators.” While, in most cases, this is true, this view by the organization overlooks all the value that (good) Technical Writers bring to the table. Based on the Gartner article, I also have to wonder if some of this image is perpetuated by the fact that as writers, we are very focused on deliverables – concrete documents that prove we’ve been doing the work we say we’ve been doing. But what if there is more to it than that?

The Gartner article states (in the context of Enterprise Archicture):

“Our definition of enterprise architecture has focused on the ‘verb’ – because we feel it is important to emphasize the fact that enterprise architecture is a process. That is important because we find that often, when people focus on the outputs (‘the noun’) rather than the process, they tend to be more concerned about producing a predefined set of deliverables than they are about meeting the strategic imperatives of the enterprise. This single-minded focus on deliverables is a mistake because it can lead to mountains of ‘artifacts’ (requirements, models, principles, guidelines, standards) that are not necessarily connected to the strategic imperatives of the enterprise and are therefore not leveraged across the organization.”

Hmmm, that sounds an awfully lot like what we often do as Technical Communicators. Let’s look at this a little closer.

Technical communication is a process, something we engage in whether or not we produce anything. Think about all the time you spend talking (and listening) to people within your organization. We communicate technically when we work with users, editors, developers, HR or any individual within an organization. In that context, we are engaging in a process – we are communicating technical and non-technical information to an audience. Yet, when it comes time to relay to our boss what we “do” we often forget about these essential, daily actions.

We get bogged down in the numbers – completed documents/projects, new document initiatives, the total number of documents available to your organization. When passed up the chain, these numbers are just that, numbers. There is no direct correlation to the business. Thus, it’s easy for those removed from the process to discount what we do (produce documents) and eliminate that position so that funds can be reallocated to a department that easily shows direct impacts to bottom line business (such as sales). So what do we do?

I think we look at our positions at Technical Communicators more like Gartner looks at Enterprise Architects. Our job is not to produce but to facilitate. We are facilitating technical communication through documents, presentations, formal and informal conversations, company-wide standards, etc. We do more than just write – we assist the business with communication that supports the overall enterprise goals and objectives.

When we look at our jobs that way, it becomes much easier to align our daily activities with strategic corporate initiatives. We did not write a document simply because we were asked (or told) to. We crafted that communication to provide the sales team with an additional tool for their new sales strategy. We created that user manual, help text or tutorial to provide users with a reference tool which, in turn, cuts down on help desk related calls. We standardized how documentation is managed to help internal employees save time when searching for the reference they need.

By viewing ourselves and our role as active, verb-like participants, we not only help justify our place in an organization, but we also help make ourselves indispensible. So the next time you get bogged down in deadlines and document metrics, stop and ask yourself: “Are you a noun or a verb?”

Source: Gartner Clarified the Definition of the Term 'Enterprise Architecture'; Publication Date: 12 August 2008; ID #G0016559