The myth that technical communication is a soft skill

I’ve said many times — and I still continue to preach this — that technical communication is likely the least respected of technical professions. There are very few things that piss me off more than any technical manager or developer who says, “we’re all done with the code. We have ten minutes left. Let’s write the documentation.”

If this is your attitude, you are effectively taking a crap on my profession.

This is what drives me to defend what I do, write ‘blog articles like this, and speak at events like SQL Saturday and PASS Data Summit. This is something I am extremely passionate about, and I consider this a war against attitudes that technical communication is a soft skill.

However, before I start screaming from my soapbox, let me back up a little bit. My first question to myself was, what exactly are soft skills? Sure, people will say it’s the ability to get along with other people and to communicate effectively (more on that latter part in a moment). I did a Google search and came across this Indeed article on what they say are “soft” and “hard” skills.

Let me expand on communication as being a soft skill. It’s true that the ability to communicate is definitely a skill that should be honed and polished by nearly any working professional; indeed, nearly all my presentations are geared toward professional development and soft skills. And the ability to communicate technical concepts is a skill that, I believe, every professional should develop.

But here’s where the trouble starts. Too many people — I daresay, nearly everyone who is not in the profession — lump “the ability to communicate effectively” — a soft skill — together with “technical communication” — which is a profession and a hard skill. There is a major difference between the two. And I think this is what gets us into trouble. That communication is often listed as both a soft and hard skill gets people confused. You never see “the ability to write effective code snippets” or “ad hoc engineering” listed as soft skills, and nobody ever confuses software development or engineering as being soft skills. But communication is a basic soft skill, and this is where the trouble for us professional technical communicators begins.

For starters, a well-developed technical communication project makes use of a life cycle, and — I’ve said this before — it is no different from SDLC. The processes are identical. There is planning involved. If you work in an Agile environment, you should even create tickets for the projects. I once spoke at a user group meeting where I was asked, how do you plan a documentation project? My answer: treat it the same way you would a software project (hence why I always say, “treat documentation like software”). A well-organized documentation project involves planning, building, testing, adjusting, and versioning — just like software.

Technical communication also requires certain skill sets. Anyone can communicate technical concepts. But it takes a professional communicator to organize those concepts in a way that can be used by audiences. Some of the skill sets required include, but are not limited to, design, writing skills, graphic design, information architecture, UX/UI, and a solid command of the language of your choice. These are skills that are required by professional communicators, but not necessarily by non-communications professionals who are looking to improve their soft skills.

If you don’t think technical communication is a profession, explain to me why an entire professional organization, academic degree programs, and professional positions exist for it.

Some of us sing Happy Birthday, or sing along to the radio, and some of us do a pretty good job of it — but that doesn’t make us professional singers. Likewise, many of us communicate well, but that doesn’t make us all professional communicators. While there may be some overlap, there is a big difference between effective communication as a soft skill and technical communication as a profession. Professional communicators, like other technical professionals, need certain resources in order to perform their jobs effectively. And if you refuse to recognize the level of effort and professionalism that goes into it, you are effectively disrespecting the profession.