Technical Writers as Sales Reps? 

Interface Software's Award-winning Docs Boost Brand, Revenues, and Customer Satisfaction

By Gordon Graham, SoftwareCEO

This is an abridged version of an article that appeared on SoftwareCEO.com; click here to read the full version. Copyright (c) 2005 SoftwareCEO Inc. Reprinted with permission."

CRM vendor Interface Software seems to have done everything right. The company has grown so fast it's made Deloitte & Touche's Technology "Fast 50 for Chicago" and five years in a row, with a cumulative growth rate of 357 percent. It also hit Deloitte's Technology Fast 500 and the Inc. 500 list several times since 2000. "In an industry dominated by stories of CRM failure and user dissatisfaction, we are proud to be recognized as a vendor that towers over the competition in customer satisfaction," says Interface CEO Nathan Fineberg.

Defining an Award-winning Documentation Team

The quest for customer satisfaction has soaked deep into the fabric of the company. It certainly defines their award-winning technical writing team.

When we spoke with Matt Thompson, director of documentation and training with Interface Software, we uncovered the following 14 best practices for documentation at his firm — plus seven bonus tips on how to hire and motivate good technical writers.

Best Practice in Documentation #1: Create a healthy workplace.

Ask most technical writers about their workplaces and you'll likely hear the same complaints:

• The developers don't follow any specs, and never tell me what they're up to.
• They get to slip their schedules by months, but the minute they're done, I'm supposed to have the docs ready, like by magic.
• They never let me near any live customers.
• I report to somebody who has no clue what I do. I'd switch jobs, but everywhere I've worked is just as bad.

For his part, Thompson is happy he doesn't face these perennial headaches at Interface. "It's pretty close to Utopia for writers here," he says.

Best Practice in Documentation #2: Understand the value of good documentation.

Documentation teams often struggle to prove their ROI in the absence of any established metrics for measuring it. Enhanced usability can count as ROI because any improvements lead to more satisfied customers and help bring in new customers, he adds.

Another approach is to "identify the costs associated with not employing their services." Fortunately for Thompson, he's never had to justify his existence at Interface.

Early on, our executives identified that having high-quality documentation made a big impact on customer satisfaction," says Thompson. "They could see how it increases usage, gives more successful implementations, and creates better references and happier customers, which then drive more sales."

Best Practice in Documentation #3: Use documentation to gain an edge.

Clever software firms turn the money they sink into documentation into a selling point. In any competitive shootout, good docs are bound to help. "It was a competitive advantage to show that we had significant documentation and our competitors didn't, especially when we were first starting," Thompson says. "If it was appropriate for a particular sales call, our sales reps would bring the documentation with them, and it showed very well."

Best Practice in Documentation #4: Have a reasonable ratio of writers to developers.

Many software firms employ 20 or 30 developers for every tech writer — especially if the founder is a technical guy who likes to hire people like himself. But this makes it next to impossible for their documentation to stay current with their software.

When Thompson arrived at Interface Software in 1997, he was the second writer at the growing firm. Today he's a full-time manager, with 25 developers for his three writers. That reasonable ratio of 8:1 shows management cares about documentation.

Best Practice in Documentation #5: Place technical writers somewhere sensible in your org chart.

Technical writers sometimes get shuffled from one department to the next with each corporate reorganization. Many managers neglect the documentation team like an unwanted stepchild.

At Interface Software, technical writing is close to two related teams in the org chart: training and customer support. As director of documentation and training, Thompson reports to the VP of customer and partner services.

What's the fit between documentation and training? "It's all about how to most effectively present the information to meet our customer needs. A lot of what makes good training makes good documentation. It's just a different medium," says Thompson. "From the beginning, we've had documentation within customer support, as opposed to being part of development or some other team. "We're sitting next to the people talking to our customers every day. That gets us closer to our customers, so we can really understand what they need."

Best Practice in Documentation #6: Keep technical writers in the loop on development plans.

Although their whole job is about communication, technical writers are sometimes the last to hear about future development plans or last-minute changes to a release. Not so at Interface. To start, their developers work from solid design documents and release plans. And they keep the writers informed every step of the way.

"We're involved from the beginning in design reviews," says Thompson. "The docs team is on the developer's e-mail list. We go to all developer meetings. "We're talking on a week-by-week basis about what we've done and what we're going to do next. So, we're seen as members of the development team."

That close interaction takes the rough edges off development ideas and gets the documentation done faster. And it's always been that way at Interface. "Tech writers are good advocates for the user, always thinking about the user's point of view," Thompson says. "Early on, we had that kind of representation in making design decisions or choosing the wording that appears on the screen. This definitely benefits the usability and acceptance of the product."

Best Practice in Documentation #7: Encourage technical writers to meet customers.

Technical writers do tend to be the user's advocate, arguing for clarity and logic in everything from error messages to how features are implemented interactions. But that's hard to do when you never talk to any customers.

"We take every opportunity we can uncover to get close to our customers and understand what they need," Thompson says. For instance, when partners and customers are in-house for training courses, any employee of the company can sign up to have lunch with them. And his writers do. "It's another point where you can talk to customers, find out what they need, and put faces to people you talk to on the phone. The customers love it, and so do we."

Best Practice in Documentation #8: Use customer advisory boards to get feedback on documentation.

Interface also has customer advisory boards driven by product management. And the technical writers are encouraged to take part, Thompson says. "We have current customers brought in, and I get on the agenda so we can ask who uses the documentation, the help, or the support website. And then we ask things like: 'How is it being used? Does it meet your needs? How can we improve it?'"

Best Practice in Documentation #9: Make the right tradeoffs.

Like any manager working with finite resources, Thompson sometimes has to make tradeoffs. This is when the perfect is the enemy of the good. "In a utopian world for tech writers, you would have as much time as you wanted to get things phrased just the way you want. But we have to get our docs done at the same time as the software. We have business needs for releasing new versions of software, and we're not going to hold that up. So, we try to make good business decisions about how to spend our resources and prioritize our projects."

Best Practice in Documentation #10: Pick the right medium for each deliverable.

One challenge most CRM implementations face is getting people to use the system. This is critical for Interface, whose primary end users are executive-level professionals such as lawyers, investment bankers, accountants, and venture capitalists.

These professionals' busy assistants maintain the CRM databases and generate reports. And their IT people configure and tweak the system as needed. To support all these different users, Interface created an awesome suite of documentation: 3,000 pages of print, all that again as PDFs, and 3,200 topics in various forms of online help. Not to mention added material on their websites, in Wizards, and as toolkits for champions and trainers. "We provide all different kinds of tools to help our customers market the software internally," says Thompson.

Best Practice in Documentation #11: Provide print for those who need it.

Most software firms now provide PDFs or online help only. Naturally, this saves big time on printing and shipping. "We haven't eliminated printing. We don't look at it at a cost decision. If information is going to be used in multiple ways, we'll put it in multiple formats," says Thompson. That's why they provide a printed library of 3,000 pages to every customer. And if they want extra sets, Interface sells them, at their cost.

Best Practice in Documentation #12: Give your writers the right tools for the job.

Microsoft Word is fine for routine office documents, like letters and memos. But it quickly runs out of gas when you try to do intense formatting on a 400-page manual.

Interface Software followed this well-worn path. "We started out using Word, and we ran into all the usual limitations that Word has with large documents. Now we work primarily with Adobe FrameMaker," says Thompson.

Best Practice in Documentation #13: Try out conditional text.

One of the most powerful features offered by FrameMaker is conditional text: passages formatted so they appear or disappear depending on what switches you flip when you print or generate a PDF.

"We use a lot of conditional text," says Thompson. "While we're writing a particular topic, we think about the different places where it will show up and the different media it will be in. So, we write unique content for the web version, the printed version, and the help version."

Best Practice in Documentation #14: Explore single sourcing.

"Single sourcing" is a documentation approach in which a writer stores everything in one document, and then from that same document, creates deliverables tweaked for different mediums.

This approach is attracting lots of fans among publication managers. "Single-sourcing allows you to create more deliverables with fewer resources," says Thompson. "And it's another way to look bigger than you are. We wouldn't be able to support our enormous help systems and 3,000 pages of documentation if we didn't use single-sourcing. Basically, we set up different templates so we can create PDFs, web pages, online help, and Word documents all from the same document.”

Bonus Tips: How to hire and motivate technical writers

If you've ever hired or managed a writer, you know it can be a daunting challenge. Finding someone with the right combination of language skills, technical understanding, and customer orientation can be tough. Beyond all the best practices outlined above, here are seven bonus tips on how to find and motivate good technical writers.

Bonus Tip #1: Hire writers with the right stuff.

What does Thompson look for in a technical writer? The answer may surprise you: It's not just wordsmithing "Obviously they need to write well, but that's not really what I focus on," he says. "I want somebody who has a customer focus and really good investigative skills."

To help detect these qualities during interviews, Thompson asks applicants to tell him about some past projects. "A lot is just their attitude. We don't want people who want everything to be handed to them. We don't want people to just translate technical documents. We want people who are willing to roll up their sleeves and be independent, try out the software, and put themselves in the customer's shoes."

Bonus Tip #2: Hire writers who ask smart questions.

Being in the customer's shoes involves asking questions to clarify interactions that may not be clear. "As a technical writer, you have to know what questions to ask developers," Thompson says. "If you don't know what questions to ask, you're not going to get the right information."

"We've built up a tremendous amount of credibility with our development team. That's because we do our due diligence before we talk to them, so that we don't ask them stupid questions."

Bonus Tip #3: Don't get hung up on tools.

Despite the power of today's publishing software, experienced publication managers warn not to get too hung up on tools. You don't need to be a power user of FrameMaker to follow the company style sheet. Software tools can be learned quickly. And one power user in the team can usually solve everyone else's problems.

Many interviewers focus way too much attention on the candidate's software experience — perhaps because these are the easy questions to ask. Don't neglect to probe how well they can solve problems, handle on-the-fly research, or perform under pressure. Those factors are more likely to determine their success than in-depth knowledge of any software tools.

Bonus Tip #4: Provide lots of feedback.

Effective technical writing is a learned skill. Beginners can learn a lot from more experienced writers who take time to coach them. Thompson schedules regular coaching sessions with each of his writers, from once to three times a week, depending on the individual. "These sessions provide frequent opportunities to mentor, adjust priorities, and reinforce our core values. In addition to these, we have formal quarterly manager reviews and yearly peer reviews," he says.

Bonus Tip #5: Insist on timely reviews of drafts.

Many product managers and developers don't regard the review of draft manuals as part of their job. So, they get a draft from the docs people, then let them gather dust in the corner. Or, they give them a cursory once-over to circle the odd word they think might be misspelled. And they get away with it, because their managers don't think it's important either.

This is not the way to motivate your writers and take care of your customers. Interface doesn't have this problem. "Our culture of customer satisfaction helps us get internal reviews done by development and product management," Thompson says. "Because everyone has bought into how it's important, they're willing to spend the time to make sure that our docs are accurate." And they give reviewers explicit directions, asking them to focus on three areas: technical accuracy, product positioning, and appropriateness of the recommendations.

Bonus Tip #6: Enter publication competitions for feedback.

Interface's 3,000-page library recently won a prestigious award for Distinguished Technical Communication from the Chicago chapter of the STC, and went on to win a Merit award in the international competition.

Understandably, Thompson is proud of these awards. But he also values the judges' comments. "I found the comments we received were well thought-out and gave us some good feedback. The suggestions the judges made were for the most part valid. It was a useful exercise." Valuable feedback and maybe an award for your documentation: who wouldn't want that?

Bonus Tip #7: Give your technical writers a chance to do more.

"It would be great if executives were thinking about the skills that technical communicators bring to the party, other than writing books," says current STC president Andrea L. Ames, who in her day job works at IBM.

"Someone really looking at information in a strategic way can help gain customer loyalty. Customers appreciate getting information that's easy to use, consistent, and really aimed towards helping them do their jobs. And enabling a company to communicate this way is a really interesting skill that a lot of executives don't see," she says.

"They may see that as a marketing communication role. But the added dimension a technical communicator brings is that they actually know how the product works. They've been the first 'victim' of the product, and they make a much better user advocate than a marcom person who is really advocating for the company they work for. So, remember that technical communicators can help at that very strategic level."

Your technical writers are, we suspect, dying to make a more significant contribution to your company. Many have chock-full of ideas on how to do it.

And if you get out of their way and let them, they will.

Gordon Graham is Editor, SoftwareCEO.com, the world's largest online community of software executives. If you want to contribute to this column, please contact the column editor, Ramesh Aiyyangar.

STC India | Home | Contact Us

Copyright © 2005 India Chapter STC. All rights reserved.