Principles for a profession: technical communication

The Society for Technical Communication, an organization to which I’ve devoted a good bit of volunteer time, has always prided itself on being a professional society. STC has taken the lead in developing and promulgating those things that define a profession — for example, a code of ethics, a body of knowledge, and most recently a certification program.

Society for Technical Communication: logoYet a recent conversation on LinkedIn started with the question, Is technical communication a profession or a discipline? Many of the responses tilted toward saying it’s not a profession.

Hmmm….Could that explain why STC had such a hard time building its body of knowledge? Maybe. But I’m not convinced.

Could that explain why, after decades of hand wringing in STC over whether to launch a certification program, demand for the program has fallen far short of expectations? I doubt it. (I think that technical writers, who aren’t particularly well compensated, simply balk at paying the relatively modest fee when it doesn’t seem to have much bearing on whether they land a job. But that’s a topic for another day.)

At around the same time as the LinkedIn conversation — but independently of it — Mark Baker published an article on his Every Page is Page One blog comparing jobs to bricks and mortar. A brick job, he explained, has a predefined shape that doesn’t change from project to project. Technical communication, however, is a mortar job: it changes shape to fit the circumstances of each project. Mortar jobs offer flexibility in terms of how the job is done and in terms of what qualifications the practitioner needs to have.

By way of illustration Mark noted that when a company engages the services of an accountant, it knows that the accountant will work in a certain way — and if necessary it adjusts its expectations to match. But when a company hires a technical writer, the writer adjusts to the company’s expectations.

That’s true up to a point. But, as Mark readily admitted in response to my comment, technical writers still operate — or should operate — under a set of principles that don’t change from project to project.

Here’s our opportunity. If we’re professionals, let’s codify that set of principles. A few to get us started:

  • We serve the audience: we know who they are, and we provide the information they need to meet their objectives.
  • We provide value — tangible, ROI value — to the people who employ us, and we can articulate that value.
  • We understand the overarching purpose of communication (which Mark deftly defines as “to change behavior”) and we work within the context of an overall communication strategy.

What principles or best practices would you add?

8 thoughts on “Principles for a profession: technical communication

  1. Michelle Corbin (@michellecorbin)

    Here’s my principle: We provide high quality information, free from issues of accuracy and clarity.

    We obviously work to define what quality means for a company or client, and then adhere to standard practices and processes to ensure that the information demonstrates those characteristics of quality.

  2. Larry Kunz Post author

    Thanks, Michelle. I like that one.

    When you mention “standard practices and processes” I infer that you see our work as being at least a little bit of brick, not just mortar. Am I correct?

  3. techwriterkai

    A couple of years ago, Scott Abel’s slogan was “We (tech comm’ers) are in the business of manipulating people.” I’m not sure why he abandoned it, because I think it’s patently true – albeit in a way that’s painfully out of sync with how we many of us think of ourselves. Which might well be the reason he quit saying it. Maybe too many tech comm’ers didn’t want to be members of a club whose slogan makes them squirm… 🙂

    Along the same lines, I sometimes think that it’s not so much the tech comm profession that cannot be defined as a brick job, but rather many tech comm’ers who would want to belong to a mortar discipline rather than a brick profession. I think Mark Baker’s analysis has more bearing on the crowd than on the profession.

    On the other hand, I know a company which over the last couple of years has hired or advertised several tech comm jobs – and they knew quite precisely what they were looking for: Someone who knows about topic-based authoring, structured writing and documentation standards, such as DITA or DocBook. Someone with experience with a Help Authoring Tool, such as MadCap Flare, Author-it or RoboHelp. Someone who can design and write topics, then get them reviewed and edited. There are all kinds of neighboring disciplines, ranging from localization via accessibility to content strategy, and there all nice to have. But the company was quite set on the core skills of a tech writer.

    As for the STC, I think part of the troubles may be a mismatch of members’ expectations and the organization’s ability to deliver. Facing constraints of time and money, It’s always difficult to join a sustained, voluntary effort to advance a community.

    1. Larry Kunz Post author

      Thanks, Kai. You raise a lot of great points. The idea that many of us want to work in a mortar discipline, but the people who hire us are looking for brick professionals, really rings true. Many tech commers bristle against job ads that emphasize tools over what we consider to be the things that matter. Can we — should we — try to convince our employers to see things the way we see them? I’d love to sit down and discuss these things with you sometime, preferably over beer.

      1. techwriterkai

        Not to pre-empt a friendly chat over a beer, but since that doesn’t seem to be happening any time soon, here’s my answer: I think the best way to win them over to our mortar way of working is to transcend the brick limitations of tools and surprise them by arguing in terms of the value we can bring to the organization – or their department.

        Unfortunately, it’s not as simple as “doing content strategy” and showing we can turn content into a corporate asset and provide value to the company as a whole. Sometimes, our direct managers don’t want us to do more than wield tools and ship docs. But most managers will have a content problem that requires more than slaving over a HAT day after day.

      2. Mark Baker

        This, it seems to me, is precisely where we need to put more emphasis on content engineering and less on content tools. The reason for job ads that focus on DITA, DocBook, Flare, AuthorIt, RoboHelp etc is that we don’t engineer the content creation process. What we do is buy publishing tools designed to be used as craft tools. Because publishing is a complex process, these tools are complex to use, and therefore require mastery before productivity is achieved.

        If we engineered the content creation process to eliminate these complexities and to allow authors to concentrate on user needs and content quality, then we would not need to worry about proficiency in these tools. Until we do this, though, many organizations are going to focus on tool proficiency and page-rate productivity, not because these things are more important but because they are easier to measure.

        A business culture that is focused on metrics and measurement is a good thing in itself, but it is terribly easy to fall into the trap of valuing the things that can be more precisely measured over the things that are harder to quantify. It is far easier to count minutes saved per writer page than minutes saved per reader page, even though the latter is a far more important metric.

        Indeed, I would suggest that an important consideration in engineering the content creation process is to get the easy-to-measure-but-secondary publishing and tool skills out of the authoring process so that we are all less distracted by them and can focus on the metrics that matter. The standard we should be working towards is an authoring process that requires no production domain knowledge of the author at all.

    2. Mark Baker

      The difference between “the purpose of all communication is to change behavior” and “We (tech comm’ers) are in the business of manipulating people.” is that people want to have their behavior changed. They pay large sums of money to have their behavior changed. They know how they behave now, and how they would like to behave, and they pay people — shrinks, authors, doctors, priests, etc. — to help them make the change. People who squirm at the idea of changing people’s behavior are missing the point that people want their behavior to change. They don’t want to be manipulated against their will or without their knowledge or consent, but they do want the behavior to change.

      This does not mean that writers never try to change people’s behavior in ways that the people involved did not want it to change, or that the change that people want is always a laudable one. But the purpose of all communication is still to change behavior. Whether you use it for good or for evil is a matter for your own conscience. But if what you write fails to produce a behavioral change in anyone, that is just failure to communicate.


Tell me what you think

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s