Samantha Ferrier, Componize Software
Abstract: Transitioning to XML documentation is not easy, and Tracy Baker is in the middle of doing just that at F5 Networks. Her insight on the evolution of tech comm, DITA XML as a mindset, and the challenges of team management are all the more interesting when one considers the fact that she has been in the industry for almost twenty years. This is the synopsis of an interview with Baker at Componize Software.
June 12, 2012—Marseille, FRANCE—Tracy Baker, Senior Technical Communications Specialist at F5 Networks with twenty years of experience, recently crossed the Atlantic to visit the Componize Software offices in Provence. The trip was a raffle-drawing prize sponsored by Componize during the September 2011 CIDM Best Practices Conference in San Antonio, Texas. Baker’s visit came just following Componize’s release of a new collaborative user interface that simplifies the use of DITA in enterprise-scale projects. In addition, Componize is finishing up a revolutionary architecture, set to be released Fall 2012.
Baker toured Marseille, spent an afternoon in nearby Aix-en-Provence, and finished her visit to the South of France in Avignon. “I had the opportunity to come to Avignon when I was an undergrad but it just didn’t come together. It took me twenty-eight years but I finally made it!” she quipped. Since her beginning at AT&T Wireless almost twenty years ago and during her twelve years at F5 Networks, Baker has been witness to a number of major technological evolutions. Her technical writing samples include the engineering specifications for the first mobile short messaging services, known today as text messaging, as well as the revolutionary voicemail.
For Jean-Luc Borie, CEO of Componize, Baker’s visit was a great opportunity. “We felt lucky to speak with Tracy for a number of reasons. One, she has been in the business for almost twenty years, and she’s seen it evolve enormously. F5’s constant technological innovation and exponential growth keeps her documentation department hard at work. Tracy’s team is also in the process of migrating to DITA XML. There are few people that have that trifecta of knowledge, experience, and current challenges, and we were excited to get her insight on the challenges that team leaders and tech writers face on a daily basis,” he said.
Componize sat down with Baker to learn more about her.
Componize: How did you get started in technical writing?
Tracy Baker: When I got to graduate school, I didn’t know how to use a computer; I didn’t even know how to turn one on, which is ironic because that’s my world now. At the time, my sister had to help me write my resumé. One day at AT&T Wireless, my supervisor pulled me aside and asked me if I had ever thought about being a technical writer. I said, “a technical what?” She remarked that I was quite good at synthesizing technical information and making it understandable for other people; that’s the essence of what a technical writer does. I agreed, she doubled my salary, changed my title, and I’ve been calling myself a technical writer ever since. It was really serendipitous because I love what I do.
C: Can you tell us a bit more about what you do at F5?
TB: F5 is an application delivery network provider. We provide business hardware and software; it’s really fast-moving technology. When I started at F5 as a tech writer twelve years ago, they had two products and now we have sixteen. We’ve doubled our writers in the last two years. It’s really exponential growth. Four years ago, I took on the Senior Technical Communications Specialist role. We have a team of twenty writers; some of them have been tech writers for thirty years. They’ve gone from word processing to desktop publishing, and now I’m getting them to XML.
C: When did you realize that the move to XML was necessary?
TB: In 2006, it was really getting obvious to me that we were choking. We were not sustainable or scalable. The company kept growing; we were adding 20 engineers a week and no writers. It was difficult to keep up. There’s only so much one writer can cover without some tools to help. I saw that all of our products were variations on a theme: they all have a common base. Although they use a number of different technologies, they sit on the same platform. A lot of the information was the same but we just weren’t sharing it. And so I started saying we need to move to XML. I did my research, started my pitch, but it took two years to convince everyone. That was the hardest sale I’ve ever had.
C: Do you think that it would be easier to pitch XML today than 6 years ago?
TB: Absolutely—I think we’ve reached the tipping point. I think that Google changed our world as technical communicators. All of a sudden you could type in a series of random words and get a very close match to what you were looking for. That makes traditional informational organization obsolete: the back-of-the-book index and the table of contents go out the window. People want their little sound bite that corresponds with their one question that they have right then. We can no longer provide big fat manuals. As a tech writer today, knowing and understanding this stuff translates to job security. You at least need to know what DITA stands for.
C: So how did you start your implementation of XML at F5?
TB: When I changed jobs, the first thing I did was go to the one week DITA bootcamp with JoAnn Hackos. I highly recommend that to anyone who wants to learn how to do DITA. Had I not done that, I’m sure that we would still be floundering. It jumpstarted what I needed to know and gave me an up-close-and-personal view of what I was in for. When I came back from that, the first thing I did was to write an information model in topics. I knew that I couldn’t teach what I didn’t know, nor could I orchestrate what I didn’t know. So when our writers started to say that it was too hard, I said, “I did it, you’ll figure it out.” I can give them tips I learned along the way. I think it’s important for them to have a mentor.
C: What challenges have you faced in your company’s migration to DITA XML?
TB: It was just a huge change. Word processing and typewriters were around for a very long time, then we had desktop publishing, and now we have XML. In a desktop publishing world, it was very easy to retreat, do your work, and not interact with anyone. Working in topics isn’t like that; it’s constant collaboration: we have roles, editors, and exchange. Some of our writers have been doing technical writing for over thirty years; this stuff was at the tips of their fingers. Now, not only do they have to be up-to-date on the newest technological developments within F5, but they also have to use all new tools to write about them. It’s a lot to handle. The daily challenge is really changing people’s mindset and the way that they think about how they work. They’ve got what I call “book brain.”
C: Book brain, can you explain that?
TB: Well, in desktop publishing, you don’t write a word until you have the end in mind. But topics are the complete opposite. You do a lot of planning, and then you start writing the little bits with the confidence that once you have all the little bits created, you can build what you need at the end. That just confounds the writers; they don’t know what to do with that. They want to know what the end looks like so that they can write according to the end. That’s “book brain “The problem then is that the topics aren’t reusable because you’re crafting them with a specific goal in mind; I’m asking you to craft them to answer a question. Figure out the question, then write that information to the degree that it needs to be written. If you start answering more than one question, you have another topic. That boggles those with book brain because they can’t let go of that idea: I need to know what the end looks like. Some of our writers want to go back to their desktop publishing ways so badly, and topics just don’t allow for that. We’re a full-DITA shop. We’re not completely migrated from our Framemaker files; we’re probably at about 60 percent after three years and upwards of 25,000 topics.
C: What has the move to DITA done for you?
TB: As a product-producing group needing to publish, using Framemaker made it next to impossible to do incremental updates. Fixing a bug post-publish in Framemaker was a major pain, and it used to take a couple of weeks. In DITA, the author goes into the topics, makes the fix, I re-spin the output, and 24 hours later it’s on the web site. Just like that. The technical writing group had lost a lot of credibility because before we simply couldn’t keep up. But instead of the previous, “No, no, we can’t take anymore,” today it’s more like, “Well sure, what is it you’re looking for?” We’re starting to get our credibility back because we can meet these demands and that raises customer satisfaction variables within our company.
C: What do you see for the future of DITA XML?
TB: DITA XML is a fairly young development arena. In XML, some people are going to make it, some people aren’t. You go with someone who is proprietary, and what if they don’t make it? You’re in a world of hurt if you have to move your files. The standards are what will make DITA huge, and hopefully, will make it become an integral part of the tech writing community. When I go to conferences today, I hear that mining companies are sending their miners two miles under the earth with an iPad, that airline companies have replaced their 40-lb flight manuals with a pad or a tablet. That makes me happy because it means that change is imminent. If those old school companies can change, my cutting-edge technical company can change. And I know DITA will eventually sell itself.