Deborah Shapiro
Biosense Webster (Israel), Ltd.

I am the lone writer for a medical device company. My job title, “Technical Communications Specialist,” is a reflection of the many different tasks I handle—almost everything that communicates and goes outside of our offices is run through me. Our company is a research and development center (based in Israel) for an international company. As a result, the high-tech, innovation-centered, multi-cultural, and multi-lingual atmosphere in our organization provides numerous challenges.

Thus, I was greatly encouraged when our company unexpectedly arranged for me to attend the 2004 Best Practices Conference and participate in the Innovators Forum that followed. I had been wondering how to capitalize on the innovative atmosphere in our company to improve our writing and documentation practices. The motivation? We had grown from 50 to over 100 employees, most of this growth in the past two years. As a research and development center, tight schedules meant that certain documents did not always receive the attention needed, a fact highlighted by a recent audit that required improved writing of certain documents. Therefore, I believed the time was ripe to transfer my academic learning into reality and look at how to be an innovator for positive change with regard to writing and documentation in our company.

In preparation for the forum, I spent time assessing our company’s documentation awareness. Based on JoAnn Hackos’s Information Process Maturity Model in her book,Managing Your Documentation Projects, I estimated we were a Level 2 organization in process maturity. With this in mind, I approached the Forum wondering, “Where do I start?”

At the initiation of the Innovators Forum, two items stood out to me:
The emphasis on having long-term goals with small wins along the way (The Heart of Change)
The fact that a corporate culture is next to impossible to change (Forum discussion with Bill Hackos, Comtech Services, Inc.)

I read about small wins and corporate cultures. These issues were discussed in all their permutations at the Forum and in the subsequent monthly conference calls. With all the ups and downs of trying to impact documentation practices in our rapidly growing organization, I have only recently realized that the small wins may be far more important than big wins in the long run—and that the small wins may have a greater impact on corporate culture than we realize.

Getting started
The first step was to find a “champion”—someone to support my quest for change. While my immediate supervisor was encouraging, her role was primarily supportive. I needed buy-in from someone with the organizational “power” to demand change in documentation and writing practices.

This person was our Regulatory Director (RD). His support actually began before I attended the Forum. We worked on a presentation that he gave to our management board. Citing the threatened audit and rework as justifications, this presentation stressed the need for improved writing skills among our engineers and developers. We received initial approval to pursue various avenues—one of which required all new employees to take an initial training course, given by me, on the basic writing tools available to them. The management board also gave an initial go-ahead to look into a writing course for targeted employees.

One step forward
In the past, I had trained employees on using documentation tools available to them, but training was not mandatory. With training now mandatory for new employees, I revisited the tone of my presentation. I changed my approach from “There are your resources, here is who to contact, now you are on your own”, to a friendlier tone that introduced me as the company’s technical communicator and how my job was aimed at making their jobs easier. From there, I not only described the available resources, but gave instructions relating the resources to their particular work specialty. Finally, I closed by encouraging them to contact me, stop by my office, and schedule time if they felt I could be of more assistance.

I was amazed to see how this change in approach worked. Almost immediately, the newer employees began coming to me with their writing problems and questions. While most of the questions were tools-based, some people with heavy documentation tasks began to ask for aid in writing—a sentence here, a paragraph there, and a few major production documents. Others stopped by to ask a quick question on grammar or how to write an email.

Perhaps the most important thing that I did not realize until later was that people were gaining a new understanding and appreciation for how good technical communication practices could help them.

Two steps backward
More challenging was developing a writing course for employees. Initially, the RD and I wanted to use some in-house materials from an office in the US. However, when we revisited the idea, there was the question of practicality. Would material designed for a US audience meet the needs of engineers in Israel? I thought not. There would be too many assumptions regarding the mechanics of writing that would be new knowledge for non-native English speakers.

The RD asked me to locate an appropriate course in Israel, target the people who needed the course, and review and assess the current documentation. Here I failed for two reasons. First, my responsibilities for product documentation did not allow for the extra time this task required. Second, and more serious, were my own attitude and discouragement. Another director in the company had approached me regarding problems on the production floor. After a long discussion, he too felt a writing course was merited. However, when I approached the person in charge of arranging training, she advised that no one had expressed the need for writing-related training; the schedule and budget for the year (2004) had already been set. Although I understood this, I was still discouraged. How was I to give a course if people said it was needed but no one was following through?

I had not yet learned that I needed to take a stronger initiative in approaching people and to see that lack of time or “forgetfulness” might be a problem—and not just for me.

Two steps forward
A few months later, one of our algorithm developers (AD) approached me: “We need to give a course in writing to our employees—can you do it?” I was stunned. I had given up on the idea. No, I couldn’t give such a course, but I did know someone who could. “Make an appointment with them,” said AD. “We’ll discuss the funding later.”

Additionally, AD gave strong input on how to make the writing resources we developed more useful. He also wanted me to target people who needed a writing course but offered to help by pointing people/documents my way as necessary.

I asked the RD if I could go ahead and make an appointment. He said, “Why not? I thought you had moved on this a long time ago.”

So I brought in one of the best in Israel (Leah Guren) for a meeting with AD, another regulatory person, the head of HR, another technical communicator who was a contractor helping on processes and procedures (IH), and me. Everyone was excited about the writing course, and the HR person promised to ask for the budget at the next management board meeting.

Not a step backwards…
Imagine my disappointment when I was advised that the request was turned down. The training budget for 2005 was already maxed out—maybe next year. I listened to the maybe—and saw only black. When AD heard this, he discussed it with his own boss. The conclusion—yes, this course is important and, one way or another, it will happen. AD mentioned this to me, but I was still seeing black. “What have I achieved?” I griped, “At the end of the day, there is no course. The only thing I’ve gained is people like you depending on me more… .”

“Don’t underestimate the small wins,” BT responded. “Revolutions were always begun by the people at the bottom. Try to look at things differently.”

Redefining the problem
With different projects now in full swing, employees who underwent my training suddenly realized I could help with their engineering documents. But now my time was fully budgeted for end-user documentation. Our contractor was booked for other R&D documents relating to patents, processes, and procedures. The need had been realized—but we could not provide the service.

Not long afterwards, the product manager (PM) for one of the projects came to me and said, “I need your help, I don’t care how, but I have to have it.”

I thought about how we really needed other technical writers doing what they do best, so the engineers could do what they did best. “Will you accept another freelancer, if I can find someone good?” My answer—an enthusiastic yes—if I could supervise them. A colleague from STC was free, and I brought him in. The PM was thrilled and the results great. Word got around and the message spread: we can still get it done, if Debbie or the contractor can’t do it, someone else will, and Debbie will see to it.

It was about then that I realized the real problem in our organization was not poor writing by some engineers (though it is a problem). Things had reached a point where I was consistently swamped with work. “Bring in the guy who helped on that other project,” some people said. “I can’t,” I responded. “It is too late in the documentation process to train someone new and still meet the deadlines, since I can’t train and work at the same time.”

The problem? My work in general was viewed as service—which was understandable, since far more than product documentation goes through me. However, product documentation was not viewed as a project, with inputs, outputs, and deliverables throughout the product-development cycle. Product managers had resourced my “services” but without a project-oriented approach towards related documentation. They invariably underestimated my involvement in the product-development project as a whole. Although I did not miss a delivery date, I worked over budget, which was always approved because product release was dependent on the documentation.

Actually, for some time I had wanted product documentation to be scheduled as a project. At one point, my supervisor suggested benchmarking how documentation was done in other medical device companies. Benchmarking was something that I wanted to do, but other work priorities did not allow me to do it; it remains a task I’d still like to follow up on and learn from.

Small wins lead to change: A service level agreement and more
About three years ago our company began a massive project to develop internal processes, procedures, and guidelines that covered the entire product-development process. This project resulted in organizational change. At that time, I wrote a guideline on how technical communication fit into the process, but the guidelines had not made it into the process.

Now, three years later I talked with the RD about the process and mentioned some problems encountered on a recent project. He responded by asking what I wanted. I replied, “To be involved from the beginning; actually, I need to be a part of the development process.” His answer? “Write it up and let’s talk. We are currently updating the product-development process, and now is the time to get you officially in the process at the right point.”

I was so glad I back up everything and delete almost nothing. Now, looking at what I’d written, I could see why my initial version had not entered the process. Rather than focusing only on documentation for products, I’d tried to tackle handling of documentation in the organization as a whole! Taking the original ideas and a recent report on lessons learned from a recent product release, I got back to writing.

Since I am (very) numerically challenged, my supervisor stepped in and calculated my hours for all projects over the past three years. Now we could see in hard numbers that I was spending at least 1000 hours on each project—apart from all the other documentation I handle!

With this information in hand, my supervisor gave pointers for developing a service level agreement (SLA) for product documentation. As we talked, she advised, “You know, the SLA is probably more important than anything else. If we get this accepted and the RD pushes for it, the way in which documentation is handled will have to change…and you will have succeeded in impacting the whole organization.”

A few days later I received even more good news. Our contractor has become a full-time, in-house employee. In a further talk with my supervisor, I learned that although they hoped that the contractor would help me, his role was still in question, and they were considering bringing in an outside technical communication agency to work with me.

Today the SLA is being reviewed by two of our project managers, after which the RD will give his feedback.

The lesson learned? Small wins do count—and we cannot underestimate them. This project has been a long chain of ups and downs; at times, I’ve let myself develop a negative attitude that was probably more defeating than anything in our organization. Yet, when I look over the past year, I see subtle changes that have led to bigger ones. In addition, this whole process has helped me to take a new look at my attitude, how I personally communicate, and my professional growth.

Our company may be a long way from being a Level 3 or Level 4 organization in information process maturity, but needs are being recognized, an SLA is on the way, my office is becoming a hub, and another communicator has been added to our staff. Will we ever have a true technical communication department? I think so—but not tomorrow. For now, I will be content with the small wins.


I would like to thank Helen Izek for her proof-reading and input for this article. I would especially like to thank my supervisor Anat Eshed-Glazer for her support of this project, and her honesty in challenging me when I let discouragement take over.


Hackos, JoAnn T. Managing Your Documentation Projects. New York: John Wiley & Sons, Inc., 1984.

Kotter, J.P. and Cohen, D.S. The Heart of Change. Boston: Harvard Business School Press, 2002.