By Neal Kaplan | Member
The field of technical writing has been disrupted. In my career as a technical writer, I’ve gone from writing everything from printed manuals and quick reference guides to creating video content for online help, wikis, and mobile devices. In the last few years, our profession has seen major changes in job roles and titles as technical communication practitioners align their efforts with business analysis, content strategy, user experience, and other fields that seem to pop up daily.
On the one hand, this shift is awesome because of the potential for our skills to contribute more and more to the success of our employers and our clients. On the other hand, for those of us who have worked in tech comm for years, this shift can feel more than a little scary. Yes, we do need to change, but we don’t need to be afraid. Through any shift in titles, reporting structures, technologies, or responsibilities, the fundamentals of what makes a good technical communicator have always been—and need to remain—the same. Here are some of the most important fundamentals:
- Collaboration
- Empathy
- Facilitation
- Writing ability
- Minimalist mindset
- Adaptability
- Responsibility
- Openness to feedback
Collaboration
When I started my first job and was asked to update a quick reference guide, I knew one thing: that I knew nothing. I didn’t know where to start. I didn’t know what information I needed to update, what I needed to add, what I needed to remove, or who might know these things. My manager could help with the who; I had to figure out the what. I had to learn that good technical content requires collaboration.
That project was perfect for a new writer: to figure out the what, I had to talk to a lot of whos. I worked with other tech writers to learn the documentation tools and find the source files. I talked to project managers about new features. And, of course, I talked to our developers to learn how those features worked.
Because this was a quick reference guide, it had to cover every feature in the product. There were UI references and keyboard shortcuts, command-line syntax diagrams and file requirements, troubleshooting tips and a glossary.
I needed information from almost everyone in the building. I had to learn how to schedule meetings and what people expected from me. I learned that my coworkers were busy people and that I needed to come prepared with goals for every meeting and lists of questions that would let me achieve them.
The more things change, the more we need to collaborate.
Empathy
We know that it’s critical that we empathize with our customers. They turn to the documentation (or videos) only when they have to. Something is blocking their progress. They need help now.
What about empathy for our subject matter experts? During that first quick reference project, I learned to say thank you and mean it. I learned that without the help of subject matter experts, we can’t do our jobs. As technical communicators, we need empathy for our customers and our coworkers.
Technical communicators work with more people in a company than nearly any other job type. We must to develop the social (or "soft") skills that, while difficult to measure, are of incredible value. During a typical week, I work with product management, engineering, technical operations, customer support, training, marketing, and even the sales team. Technical writers are a company’s primary content creators, and the information that we use to build that content comes from every department.
I’ve learned that the only way I would get a second meeting with a subject matter expert is to make my requests (and intentions) clear, respect their time, and show appreciation for their help.
Like many technical communicators, I can be an introvert. But it’s critical that we push ourselves and meet with our coworkers in person when we can, or via phone or Web conference when that’s not possible. I guarantee that you’ll get a lot more information that way, both in the initial meeting and in future meetings, now that you know each other as more than lines of text in email exchanges.
The more things change, the more we need to have empathy.
Facilitation
Our subject matter experts are wonderful, but they’re not omniscient. Sometimes they forget a few details, or maybe someone else changed something without notifying everyone. This should be our mantra: trust, but verify. We need to not only collaborate with our subject matter experts but also facilitate open communication throughout our organization.
I met with many people across the organization while researching that quick reference guide. Every so often, something that a developer told me wouldn’t quite match what I’d heard from a customer support agent or product manager. This led me to discover one of my favorite things about technical communication: that moment when you realize that two (or more) people need to talk to each other.
It’s never a case of pointing fingers or blaming anyone for deliberate wrongdoing. We aren’t tattletales or scolds, and it would cripple our ability to do work if our coworkers saw us that way. Instead, as communicators ourselves, we help foster communication among other teams.
It’s frustrating when internal communication breaks down. Technical communicators can be more than messengers. We can be ambassadors. In this new enterprise environment, we need to use our skills to help topple silos and break down barriers between departments. We can do this not just by comparing notes, but also by setting up open communication channels and encouraging our coworkers to talk to each other as often as they talk to us. Open communication across our companies allows us to do our jobs more efficiently, resulting in more complete, better quality technical documentation.
The more things change, the more we need to facilitate communication.
Writing Ability
Coming into technical writing straight out of college, I quickly learned that technical writing requires more than a familiarity with basic grammar. That’s the starting point, and it’s critical that we know our way around a sentence. But I had to learn to write in a style that matched our customers’ expectations, eliminated ambiguity, and kept our translation costs low.
My company had a style guide that discussed all of that in exhaustive detail. There were strict rules about word usage and tips on eliminating repetitive words and expressions that don’t add value to the documentation. I’ve collected several style guides over the years, and I’m glad to see that we’re transitioning away from writing overly serious, stilted content.
But the rules promoting clear language stick with you. I’m always looking out for ambiguous words that can be misinterpreted, especially by nonnative English speakers or translators. I’ve had a few fun conversations with non-tech-writer coworkers who wanted me to tell our customers to "depress a button." I had to explain that I wasn’t about to turn our customers into sadists!
Honing our writing skills allows us to turn complex technical concepts and instructions into clear, simple (but not simplistic) content. Using simplified language expands the number of customers who can understand our writing, and it makes it easier and less expensive for translators to do their jobs.
The more things change, the more value writing ability has for our businesses.
Minimalist Mindset
Minimalist documentation is clear, functional, and relevant to customer concerns—enough information and no more. It serves busy readers who want to answer questions and get on with their work.
On my first quick reference guide, at first I went too far, stripping away explanation and context, leaving the reader with only the most basic tips and interface labels. To become an effective technical communicator, I had to learn what minimalism really means. It took a lot of work and many edits to make sure that there was enough information to help readers without overwhelming them with unimportant details.
We must bring this minimalist mindset to technical documentation—and to customer support, marketing, product planning, business discovery documents, or any other communications deliverable we might create.
The more things change, the more important it is to cultivate a minimalist mindset.
Adaptability
Adaptability can cover a range of valuable skills. Technical communicators need to have a combination of curiosity, willingness to do research, and the ability to turn information into concise, readable content. Add to that the constant drive to poke at things, to find out how they work, and to improve them where we can. I think of this bundle of qualities as restless dissatisfaction. Restless dissatisfaction leads us toward action, but it’s the willingness and ability to adapt that turns our research into reality. It’s easy to research new options, but we must be willing to accept and implement new tools and processes.
We’re used to adapting to sudden changes on a small scale. Just think of all of the times someone has come to you with last-minute changes to a product. We learn to expect content changes and accept them with good humor.
That’s an example of a small-scale change (product features), but this adaptability serves us well on a larger scale as we face changing conditions. When I’m evaluating technical communication candidates, their skill with a particular tool is secondary to their willingness to learn new tools and processes. An expert who isn’t willing to adapt and change becomes much less useful if I decide to switch tools.
Most of us will be using different tools in five years, maybe sooner. I’ve used at least a half dozen documentation tools during my career. I’ve moved from unstructured desktop publishing to structured authoring tools to wikis to WYSYWIG editors. I’ve loved some tools, and I’ve fought with others. Sometimes I’ve loved and hated a single tool multiple times in the same week.
We must be willing to accept and adapt to changes to keep ourselves relevant in a world of rapidly changing skills. By being willing to change, we will also continue to research new and better ways of creating technical documentation and delivering it in ways that best serve our customers.
The more things change—by definition—the more we need to stay adaptable.
Openness to Feedback
One of the technical communicator’s most important core skills is the ability to welcome feedback, especially when our content is criticized. I’ll be the first to admit that this is difficult. When I was writing that first guide, even knowing that I was a newbie and had everything to learn, reviewers’ comments sent me through the five stages of grief:
Denial: "What? That section is fine!"
Anger: "How dare they insult me like that!"
Bargaining: "Fine, I’ll make some of the changes just to make them happy."
Depression: "So many comments. I’m a terrible writer."
Acceptance: "I guess those comments make sense. And that section really is confusing.…"
I’d like to say that I now accept all feedback with a smile. At least I have learned to move through those grief stages quickly. Although I still have an emotional attachment to what I write, I’ve learned to invest enough in my content to be motivated to make it awesome, and I’ve seen the value that good reviewers add.
The more things change, the more open we need to be to feedback.
Conclusion
These are the skills that I’ve learned during my career. Collaboration requires empathy and openness. We’re able to create clear, minimalist content only after we’ve honed our writing ability. Our adaptability lets us navigate and accept changes, both the changes that we pursue and the ones that we can’t always control.
These skills ensure that no matter what buzzwords find their way into our titles or what tools we’re asked to use, we continue to create valuable content for our companies. These are the core skills that I’ve learned in the 20 years since I wrote my first quick reference guide. I couldn’t have imagined the amount of change that would occur in our profession, but I’m grateful that the fundamental skills I learned then are the same skills I will be using for many years to come.
The more things change, the more all these things need to stay the same.
Neal Kaplan is the technical communications manager at Ayasdi, a data analysis and machine-learning startup. He is responsible for product documentation, customer support, and training content. Neal has 20 years of experience as a technical communicator and has created many types of documentation for companies ranging from startups to multinationals. He blogs at Customers and Content (http://customersandcontent.com). Neal lives in the San Francisco Bay Area with his wife and two daughters.
