Ever want to know what being a seasoned technical communicator is like? Spend an hour with Neil Perlin, and you will be amazed and inspired! My interview with Neil on the field of technical communications was quite refreshing. I felt that I learned more from interviewing him than I could have in a classroom for an entire semester. Neil provides training and development for online content, help documentation, and mobile technology. More importantly, he can provide a lifetime of experience in technical communications to those who ask. We spent more than an hour, and throughout the interview he shared his insight, experience, knowledge, and thoughts on the future of the technical communications.
Neil has been in the field for over thirty years and has seen it evolve from word processing and print manuals to online help to the dawn of the mobile revolution. He has written numerous articles for Intercom and other publications; you can check out some of his published work at the EServer TC Library online. What may be difficult to gauge is the number of topics he can talk about, because he has seen it and done all. How can we use what we learn from him?
The Recent History of Technical Communications
Neil explains that, “originally content was just content and no one really had to pay attention to where it would end up”. But during the last ten years, there has been an important shift toward written content that can be repurposed for a variety of media. He notes that people have been creating technical communications content for years using different tools and versions and producing documents for a variety of formats and devices. The continuing issue he sees is that people do this without a plan for reusing the content in the future—for purposes not yet imagined. “People have gotten accustomed to working without a plan for their content,” he says, “even while technology changes and transforms how people use that same content.”
Argument for Creating a Plan
Neil believes that technical communicators and businesses must plan for different markets and outputs. He argues that we need to assume “new things are coming along that have not been seen or even invented…but we know they are coming. We can no longer let ourselves be surprised when the unexpected happens, as the field was in 1997 when online help suddenly became based on HTML, which caused all kinds of upheavals. We’ve known since then that change is coming so we should no longer be surprised when it does.” While this type of thinking is different, and it can be unnerving for a business to try to anticipate products that may be just coming off the drawing board, Neil says, “We can’t work blindly without developing an awareness of what’s coming at us.”
Companies that produce content without a solid business plan in place can inadvertently put themselves into a corner with no way out without incurring costly fixes. It hurts the bottom line for companies to have quality content that expires or cannot be reused. Companies call on consultants like Neil when they need assistance fixing their content, their standards, and their tools. “To fix such problems and not repeat them in the future, [companies] need to come up with and follow a content strategy.”
Don’t Think Outside the Box
For a long time, we have been told that think outside the box was the way to creatively brainstorm something unique. Neil suggests the opposite, think inside the box. What he means is the need to consider all our development constraints such as resources, costs, and technical issues. Thinking inside the box is much like thinking outside the box; however, being bound by some conditions may force us to think in innovative new ways.
The Technical Communications Content Strategy Imperative
Neil adamantly believes that technical communicators must think for themselves when it comes to figuring out how to maintain their material and workflows. They are responsible for devising a technical communications content strategy that meets their specific needs rather than some generic, one-size-fits-all plan.
Neil emphasizes two points when discussing how technical communicators need to stop thinking about content as HTML, Word files, or tweets. First, he suggests that we start thinking of it as “content” coming from various sources and processed in different ways in order to think more flexibly about it in order to re-use it where possible – the idea of single sourcing. Second, he recommends utilizing consistent terminology across the board—having one term that refers to similar items. Some of his “favorite” horror stories come from cases of inconsistent terminology that raised havoc in real-life situations.
He says that the overall goal of a content strategy must be business-related – increasing revenues, reducing costs, or branding. If it doesn’t, technical communicators need to rethink their approaches, perhaps by changing the documentation process altogether – adopting social media, for example.
No Excuses for Not Planning
Neil points out that businesses need to create a plan for their content. He has helped many companies avoid problems because they did not set up a content management and development plan. “It may have been okay twenty years ago because we did not know any better. But in this day of information technology,” Neil stresses, “we can no longer wing it.”
Content planning goes well beyond the content level. Choosing the right software for the project is equally important. Building a large document using Word is generally not as efficient as FrameMaker, for example. But it may be, and it’s important to know why – to pick our authoring tools for solid business reasons. For example, in the ’90s, Neil would receive phone calls from companies that had adopted some authoring tool with no clear business rationale for doing so. He recalls a company that adopted RoboHelp simply because the client’s daughter recommended it after hearing about it in a college computer science class. Another client tried to buy an authoring tool called “RoboCop;” it took the IT department several weeks to figure out what they were really looking for.
Great Technical Communications Outcomes
Beyond the horror stories, though, Neil has a satisfying collection of success stories about assisting companies with their documentation by training and consulting and encouraging their technical communications teams.
In one example, Neil worked for a company that used Word but wanted to develop a presence online. He trained two “very sharp guys,” who created a prototype and moved from Word into RoboHelp in four days. “They may fumble, but they are off to a running start.” He had a similar experience where the client he was working for did not know how to use Flare or Word correctly. In this case, he trained twelve employees to create and maintain a demo for their management team, giving them the confidence to move their documentation into Flare. Overall, Neil says, it was a big success because it gave them the confidence to move into a completely new area and added to their credibility with management.
Neil uses documentation horror stories to show his clients what not to do. His theory is that there’s nothing wrong with making mistakes as part of a learning process. Just don’t make too many and don’t make the same mistake twice. He explains their mistakes and the mechanics of what they’re doing, and the underlying concepts so that they can make their own judgments. He always likes to challenge people to think on their own and to challenge him; when things get to that point, he says that his job is done.
Is Technical Communications Fun?
Neil says he really enjoys his work as a technical communicator. Speaking engagements at conferences are a form of marketing but they’re also just fun. His tenure has given him a treasure trove of valuable knowledge that he is willing to share. Indeed, as we spoke, it became clear that he is passionate about the work he does. Neil thinks the best way to thank his mentors is to be a mentor for new professionals coming along.
He concluded our conversation with one final and motivating thought: “I have been doing this for almost 33 years. After all these years, [technical communications is] still fun and challenging… I wouldn’t change it.”
Twitter: @NeilEric
Website: http://hyperword.com
