What I've Learned About Technical Writing
What I read: Technical Writing: Need of the Hour? by Aditya Pingle. Published June 24, 2021.
During my varied professional path, I’ve worn many hats in a few different fields. One of those fields has been computers and software technology. That experience eventually spawned a long career in technical writing which is nowadays sometimes referred to as information development or technical communications, among other names, to indicate the field has extended beyond the written word to include graphics, illustrations, and video content.
In addition, technical writers have increasingly been tasked with the creation of other information deliverables such as classroom-based curriculum, e-learning modules, video-based training, marketing collateral, and blog and social media content.
This is a topic on which I consider myself a bit of an expert. Visit my LinkedIn page and you’ll see I’ve had a rather robust career in software, and technical writing specifically. My experience spans everything from being a fledgling individual contributor to managing a diverse global team.
For those who might be reading this who have absolutely no background in this field, this is what technical writing is in a nutshell.
Technical writing is related to a process of knowledge transfer and it is technology-specific. If you go by the definition on Wikipedia:
“A technical writer is a professional whose task is to provide the knowledge transfer between two or more entities through the best possible way and medium.”
Anytime someone creates a technical information vehicle, whether it’s the written word, video content, a marketing brochure, or whatever delivers information or learning to the consumer, it’s a form of technical communication. Software is not the only field in which technical writing is integral. Hardware, consumer electronics, aircraft, and medical devices are other market sectors in which technical writing plays a key role.
I’ll let the article speak for itself about pursuing technical writing or its many variations as a career in the modern workplace.
With statistics showing a clear upward demand for technical writers, it is the right time to think of this as a mainstream occupation.
Apart from highlighting that technical writing appears to be generating job opportunities currently, this post is my attempt to concisely offer some of my observations and I hope wisdom on how to best traverse this field and produce the best deliverables possible within the confines of a large organization or corporation’s structure. There is much I could say here, but I will attempt to keep it brief and to the point.
Here in no particular order are some things I’ve learned about my field of technical communications. Perhaps it will help others entering the field or those already in it who will likely nod their heads in sympathetic agreement with much of what I say here.
Keep it simple.
I know this is hackneyed advice. We’ve all heard it before. But perhaps that’s because it’s such a good way to look at much of life, including technical communications. Keep content simple and direct. Fewer words are probably better than more words. Unless you’re trying to stoke marketing emotions in the consumer, keep flowery language or complex prose structures out of the work. Simplicity doesn’t just apply to the content. Keep authoring tools, information structures, development and publishing processes, and style guides and content creation guidelines as concise and simple as possible. If a process currently takes eight steps and you can reduce it to six, reduce it to six. Every bit of complexity taken out of the entire start to finish process of creating technical content will improve both an employee’s working life and the end result.
Ask the user.
This might seem like an obvious thing to do, but you’d be surprised how often content is developed under the assumption that it’s already known what the consumer of that information wants rather than just asking them directly. Customer surveys are great, but nothing replaces being able to talk to a customer in real time and ask during a conversation what information they need, in what format, and via what delivery mechanism. For example, continuing to create mountains of classroom-based training materials, when an overwhelming number of your customers instead want learning delivered through e-learning modules or video, makes no sense. Never assume what a customer wanted a few years ago to be what they want today. We move with the times or suffer the pain of irrelevance and lost customers.
Video is king.
While there is still no adequate replacement for detailed technical documentation often needed by those who need a deep dive into the guts of software, hardware, or any other technology, increasingly video is the format through which more people get their information. Younger people continue to overtake the marketplace as consumers, and they have grown up on video. Reading text is considered at best a backup if more detail is needed after a user views a short video on the topic.
When hiring focus on basic skills.
Too often someone is hired because certain line items on their resume are a supposed match for the job’s listed duties. I find that a dangerous assumption. Hire for skills but just as much for the ability to self-educate. Resumes are padded and presented in their best light. Extensive experience in an area doesn’t always mean they’re good at it. So, I recommend focusing on these things when hiring technical writing talent.
Test them. I know this might insult the more experienced among your job candidates, but test every single one of them. Create a simple, easy to administer test that challenges every candidate equally to demonstrate that they indeed know the basics of what they say they know. Make the test short, extremely general, and not tied to a specific authoring or creation tool. Make sure to carefully examine the crafting of the writing. I find most skills are easily trainable, but few organizations have the time or resources to train someone to be a good writer. They need to arrive at your doorstep already able to produce solid writing. One can tell immediately if a candidate has at least the basic technical writing skills you’re looking for upon review of a good test’s outcome.
Ignore education. I know. You and others have expended so much time and money on an education. That’s great. But I honestly have yet to see a causal correlation between a technical writer’s education background and their current ability to do the work. One of the best technical writers I’ve managed had a high school diploma and was brand new to the field. One of the worst technical writers I’ve managed had a Ph.D. in a related field and more than a decade already working in the technical communications field.
Figure out if someone is a good self-learner. The ability to self-educate and learn by ferreting out information from varied sources, with little direction needed, cobbling them together into a meaningful and applicable learning experience, means far more to me than what educational background someone might have had in the past. The past is the past. Technology and the world move on. Without the ability to self-educate a technical writer will never succeed long term.
Yes, personality matters, but a diverse set of personalities is better than everyone being cookie-cutter versions of the same type of person. Sometimes quiet people get the most work done. Sometimes the person who nudges the conversation with an argued counterpoint will result in finding better ways to do things. Let me add that a team developed with diversity and inclusion in mind will ultimately result in better teamwork and group thinking that stretches everyone to be better.
Ease up on metrics.
I know. To downplay the usefulness of metrics is heresy to some, but I’ve seen so many instances over the decades of entire teams scrambling to create metrics only to later see them irrelevant and useless. This sentiment also applies to detailed scoping of projects (determining time and resources necessary to create a certain deliverable). An experienced manager or individual contributor already intimately familiar with their deliverables can generally eyeball a project and arrive at an incredibly accurate estimate of how long it will take to complete and with what staff and financial resources are necessary than if they had undertaken an extensive metric-driven planning exercise. When there are huge numbers of moving parts and people involved, metrics-based planning makes sense. But when it’s a relatively simple project with only one or a few technical writers involved, ballpark estimates tend to work just as well as detailed metrics and it saves everyone a lot of painstaking and time-consuming grief.
Keep tools as simple as possible.
I know I mentioned this briefly above, but I’m separating out tools because it’s so important. Authoring tools, publishing technologies, video editing applications, and other tools that a technical writer uses to create and publish their content are always changing and improving. It’s tempting to keep upgrading to the latest hot tool, but sometimes that just adds to the complexity of the overall process while not necessarily producing better output. If you’re a small company producing simple book-style sets of documentation in PDF format, maybe just stick with a simple word processing application. If you’re a bigger organization and need a large group of people standardized on style, format, and publishing processes, maybe an XML authoring tool is a good idea. Even then, stick with as close to standard DocBook DITA as you can. The more customizations to your tools and structures, the more things can be problematic in the future when someone can’t support those customizations. The same simplicity mantra applies to things like video editing tools. If you are doing extremely simple videos, use an extremely simple (and less expensive) editing application. Same applies to graphics creation. Also, there is an advantage to using tools that are ubiquitous in the industry. Using lesser known tools can mean longer onboarding training times and higher risks of less support in the future. The simpler the tools, the easier they are to learn and use and the less likely your organization will paint yourself into a corner with setups that no longer serve your needs or end up breaking.
Create generalists on your team.
There can be a tendency to silo people into specific deliverable creation roles. This person writes. This person creates marketing videos. This person develops e-learning. And so on. Sometimes that can work, but more often than not cross-training people and empowering them to create a variety of deliverables gives your team members work variety, improves their industry skill set which is a powerful retention tool, and buttresses you from the possible loss of a key content creator who specialized in one thing and now you have no one with the skills to step in quickly. I have learned firsthand that most technical writers can rather quickly learn to develop quality materials such as training and videos. Give them a chance and they’ll usually rise to the occasion.
Editing staff is a rare luxury.
Most organizations and companies I’m aware of have few or no editing staff. Some full-time editors are employed and that’s great when it happens, but even then, it’s difficult for one or two editors to give proper attention to the entirety of what’s being delivered. So, the ability to edit yourself and others is a good skill to have. Develop peer editing processes on teams that have one technical writer or content creator editing and reviewing another’s work. Another set of eyes on writing, graphics, or video content can mean the difference between publishing an impressively clean product or one laden with typos, errors, or sloppy presentation. (Someone is probably going to catch a typo or grammar problem in this post that could have been prevented by an editor other than myself.)
I can think of other things I’ve learned along the way, but this post is already long. Technical writing can be a great career and the work can be stimulating, rewarding, and lucrative. Hopefully what I’ve said here proves useful to those entering the field or already working in it.
You can use this link to access all my writings and social media and ways to support my work.