Money Maker or Stable Supporter?  The Path Ahead for Today’s Documentation Team

After fighting every inch of the way, technical writers have carved a niche for themselves in the Software Development Life Cycle today. The generally prevalent scenario today is that documentation plays a crucial role as the support team for the principal revenue generators, i.e. the software development team.  

The next logical objective for a documentation team would be to undergo a metamorphosis from being a support team to being a mainstream profit- making group, contributing to the organization’s bottom line.

In short, can technical writers today aspire to play a starring role or should they be content playing a crucial supporting role?

Voices:

Anupama Gummaraju

Pawan Nayar

H.N.Venkatesh

Vineet Upendra

Anupama Articulates...

Technical communicators are definitely a profit making group, though proving it is a bit of a challenge.

First off, how do we define support? Is it a function that is a cost to the company or a function that can be billed to the customer? If the latter is true, as is the case today in many Indian and multi-national companies, technical communicators are already adding to the organization’s bottom line.

Technical communicators also add value to the organization’s bottom line. This value addition is sometimes measured but mostly not measured, and hence not visible. For example, redesigning an intranet’s usability and content saved a client half a million dollars in 6 months; this is measured value. If the client comes back to your organization to get more such benefits, your profit margins naturally add up right there. When we start measuring the value we are already adding, we will see that we are already a profit making group.

We also need to measure the value add not just in terms of revenue earned (which exists anyway), but in terms of the user experience we provide. Lack of a good user experience equals a dissatisfied end user and a dissatisfied client. No amount of revenue that you earn from a client can replace the sense of failure you feel if your products fail to service. This is where technical communicators will play a starring role – not measured just by the money but also by the value that we add to the products we work with. Numerous case studies by Intel, FedEx, and other global companies have proved that this value translates to time and effort saved, and reduced support calls leading to more profits.

A starring role in a niche area is what we will eventually play. Initially, the mainstream profits may not be in the form of dollars adding to the organization’s margins. The mainstream profit will be a user experience, right from an easy interface for the product, easy usage, increased productivity, less user problems, less support calls, and more satisfaction with the products, resulting in measured value.

In this journey to achieve user and client satisfaction, bagging “pure documentation” projects from the organization’s existing clients is but the next step. When these pure documentation projects run into millions of dollars, is when we will actually make a mark as a profit-making group.

(Anupama Gummaraju works as a Principal Technical Communicator with Infosys Technologies Ltd., Bangalore)

Pawan Points Out...

The belief that documentation is a support role in a software firm is pretty discomforting. It stems from the assumption that an average documentation team only documents capabilities, limitations, installation guidelines, and procedural details of any software.

If your employer is a mature, evolved, trend-setter, then he probably realizes that documentation as a task is a subset of a larger, more complex task called communication. If you are not fortunate to have such an employer, then it is an opportunity for you to make your employer a trendsetter by creating an ideal Technical Publication department that makes the whole product team conceive and create differently.

As a member of the Technical Publications team, you can help define quality within the code by being the first user of the product. You can identify non-intuitive operations, and provide timely feedback to the development team. You can create quality error messages, define the content and flow of wizards, organize the dumps in log files, and streamline the usage of styles and conventions within the software. Remember, you need to do all this while you create and maintain routine documentation that is shipped with product!

With a little technical expertise, you can perform unit tests that will let product verification folks to test cross-flows and look beyond testing modules. If you have a programming bent of mind, you can step up and help in automation.

I have often found that technical communicators are the humor catalysts in the product team who bring divergent opinions of programmers, testers, and support engineers to an effective conclusion. Larger projects can be divided into smaller modules and you can do limited program management of those modules. For relatively low-tech software, an experienced technical writer makes the ideal architect or product engineer. Of course, it takes time but it is well within the realms of possibility. An ideal tangential example of this is a certain gentleman who is a successful model and sometimes plays quality cricket. This gentleman goes by the name of Sachin Tendulkar!

Technical writers can also contribute by turning into customer/user advocates and identifying patterns within the thousands of user calls and using them to create bug requests. For the areas that have high call volumes, writers can create training programs or multimedia demonstrations that explain the subtle points of the software. With a little passion, writers can monitor support forums, write white papers, or complex datasheets.

The world has enough space for growth, be it for corporations, departments, or individuals. An ability to add value and refine the present, sustaining results at reduced costs will surely reap rewards. Ultimately, anybody who bonds with the bottom-line causes money-making!

(Pawan Nayar works as a Technical Publications Consultant with Cadence Design Systems, Noida.)

Venkatesh Ventures...

“A product or service that is valuable to a company is one that is needed to provide a profit or reduce costs. An important service is one that is critical in the delivery of a product. The service a technical writer provides can be valuable to the company and enhance its bottom line. In many cases, documentation can be important to the sales of the company's products.

Users or customers may find technical documents useful and important. This means that the writing is valuable to them.”

- Ron Kurtus, Valuable Services

The role of a technical writer today is habitually equated with other support functions. This is due to a mistaken perception that technical writing is just another back-end task. However, today the technical writer’s role is all pervading in the software development lifecycle. It begins with preparing marketing proposals and carries on till installation sign-off.

Companies today specify stringent requirements while hiring a technical writer. The requirements include – technical graduation, excellent communication skills, knowledge of various tools, domain expertise, and so on. This is a pointer to the fact that software documentation is perceived to be a critical function. The skills, competence, and responsibility of a technical writer are on par with other members in product development or software services. Thus, when technical writing is so crucial for the success of a project, it is nobody’s case that the technical writer is a passive contributor and is confined to a mere support role.

The technical writer caters to the requirements of different types of end-users; technical and non-technical, internal and external. This necessitates accurate target profiling and audience research. In addition to documentation, technical writers are also called upon to perform functions such as bug reporting, software testing, and so on. Thus the multifarious responsibilities of a technical writer far exceed the role of typical support staff.

A lead can be converted into a customer based on well-written documentation.  The technical writer is a billable resource and makes significant contribution in revenue generation. When the qualifications, competence, experience, and commitment of a technical writer play a significant role in the success of a product or service, there is no justification in labeling a technical writer as just another support staff.

(H. N. Venkatesh is a Technical Writer working with i2 Technologies., Bangalore)

Vineet Verbalizes…

How often have technical writers come across someone from the software development team who proudly say, “We’re earning everyone’s bread and butter.”?  Chances are, quite often. And what do technical writers have to say in return? Well, it depends on the kind of organization the writer belongs to. If the organization has writers on its payroll who do nothing more than type out whatever input the developers give them, the writers will have nothing in their repartee armory.  

So, where do writers go from here – do they continue to be supporters to the development group, or do they actually begin to contribute to the organization’s bottom line? More importantly is it possible for writers to actually make money for their companies? Yes, it absolutely is!

A team of writers, whose primary responsibility is to provide documentation support to the development can also train people on documentation processes, and on how to create better technical documents.

“Gawd! Won’t that eliminate the very raison d'être of writers?”

No, it won’t. Writers are not supposed to be fire fighting beyond a certain time scale. Training developers to write better technical documents will help the development team to churn out documentation that’ll require lesser cycles of reviews and approvals, thus saving time and money for the organization. (To borrow a cliché, time is money. Factor in manpower costs, stationery costs, et al, and there’s quite some money involved.)

Writers can also map documentation processes and eliminate bottlenecks therein. You can hunt out bureaucratic twists and turns in the software development process. You would be surprised to discover how much time is being spent in departments playing excellent volley shots with documents. Suggest how the documentation process can be melded with the overall quality system, and how documentation, information development, and information mapping can be integrated with the organization’s working. Then, go ahead and help the quality team do it. Is there an end to the good work that a team like this can do in an organization? Of course not. Improvement is continuous, and has to be sustained.

So, what is the writing team doing here? They’re getting up, going beyond writing, and actually becoming proselytizers for technical documentation. The problem that writers face on an everyday basis is that no one knows who or what writers are and what they do in an organization. It’s up to the writers to get up and do something about it. Take chances, grab opportunities, and make that transition from being a support group to a profit centre. The caveat? Just doing good work will not help – they also need to tom-tom their achievements. That’s the way the cookie crumbles, like it or not.

(Vineet Upendra is Technical Writer Analyst working with Dell, Bangalore.)

If you want to participate in any future debates, please contact the column editor, Avinash Akshay.

STC India | Home | Contact Us

Copyright © 2004 India Chapter STC. All rights reserved.