Recently, my business grew to the point where I have a couple of subcontractors working on client projects at any given time. This has been an illuminating experience for me —and I’m sure for some of the contractors — as I connect client to contractor, trying to make the fit as neatly interlocked as puzzle pieces. There is always that sigh of relief when I’ve made a good match and both the client and the contractor agree that they enjoy working together on a project.
The task is certainly easier when all the factors are known: a client needs a Help system, and I know a contractor or two who can structure Help files in their sleep and make the software do things we didn’t think possible; or a client needs some usability work done, and I remember someone who would be super at just that type of project. The match gets trickier in situations where I must use a new contractor, or the client wants industry-specific knowledge as well as core technical communication skills. I look over portfolio pieces and talk through the client requirements, hoping that I’ll be able to tell if the contractor has what the client wants and what I want: core competencies of our craft.
Most times I get it right, but the odd time I end up with a contractor who can make a piece of software sing but has no clue how to structure the content. I remember that another local business owner used to make every applicant — it didn’t matter how experienced or how good your reputation — take a writing test; she explained that it weeded out those with poor base skills. This makes me wonder: What are core competencies in today’s technical communication world? Have the core competencies changed from, say, ten years ago? How can we ensure that we get and retain our core competencies while building out our specialties?
The core competencies in today’s marketplace begin with the same basic skills (learned) and abilities (innate) that technical communicators (TC) have used for many years, but the definitions of those core competencies have changed with the times. From a business owner’s perspective, then, here are the competencies that I consider critical.
Excellent writing and editing abilities. This competency is a deal-breaker. If a TC has all the other competencies but cannot write, then there is a competence deficiency. To paraphrase the saying that perfection is achieved when nothing can be taken away, writing excellence is achieved when nothing can be taken away, when the writing is complete, correct, clear, and concise — the 4Cs of good writing.
Structuring information. In the context of core competencies for TCs, writing means far more than proficiency with spelling and grammar, more than the 4Cs of good writing. Much of this begins with ability, but it must certainly be supplemented with skills gained by learning the theory of the craft. Competency means being able to write to genre, whether that genre be hardware guide, user guide, reference guide, Help system, software development kit, policies and procedures, training materials, or a user interface. You must know the forms of writing appropriate to each genre and be able to create content accordingly.
Conducting thorough research. Competent TCs know how to get the information they need from subject matter experts, end users, and other project stakeholders. This requires a contextual understanding of the business paradigm in which the product or service exists, and the ability to grasp new paradigms. To communicate the feature, benefit, or function of a product to an audience, you must be able to investigate and then parse, not simply regurgitate in a new form, the information gathered through interviews or background documents. Some might say this is an ability — either you have the talent or you don’t — but I believe that this is a skill that can be acquired through learning and experience.
Grasp complex material quickly. Successful TCs have the ability to learn through trial and error, under sometimes chaotic circumstances, and without the benefit of training. (After all, it’s TCs who create the training materials.) TCs who become competent in this area are those who can sit down in front of undocumented piece of hardware, software, or process, fearlessly tackle it until they understand it, and then can explain it in the context of the industry of use. I once discarded the resume of a candidate who listed training on email as professional development; someone who can’t figure out simple email software probably wouldn’t survive a typical technical communication project.
Skill with industry tools. Owning carpentry tools does not make a good carpenter, but without knowing how to use the tools properly, one cannot become a good carpenter. To put theoretical knowledge to use, TCs must have mastered the appropriate tools, know which tools into use in various situations, and use them with above-average skill. Rusty skills on outdated tools do not contribute to core competency.
One of my favourite university professors taught: Your world is limited by your vocabulary. The richness of your vocabulary is an indicator of the breadth and depth of concepts you can articulate. This principle certainly applies to the competencies of technical communication professionals. The competence of a decade past is not the competence of today. To remain competent, we can’t be complacent, let our skills lapse, ignore trends. We need to keep our professional vocabulary — our concepts — current.
This list of competencies is by no means the definitive word on the topic. I don’t mean it to be. However, none of us can go wrong by working toward these competencies and committing to continuous improvement of them.
