Certification--
I have rejected Technical Communication certification for a long time, and I have recently changed my mind. The field of technical communication has had a "We don't get any respect" chip on its shoulder for a long time. I think we have failed to communicate our value in many cases because we ourselves have not understood that value. To our credit, we have evolved from "We produce well-written, correctly punctuated documentation" to "We support user task-based information requirements." In other words, we did a good job of moving from documenting products to supporting what users do with those products (please, I'm using the term product very broadly). What we haven't done so well is understand and articulate how a better-informed, better-performing user benefits our employers.

We hear a lot that we want STC to "tell our compelling story" and I have participated in board discussions about what level of management STC should target with articles about how technical communicators add value. To me, this is like asking our mother to come to school with us and tell the other kids they have to play nice with us (well, not as humiliating, but about as effective). The only ones who can tell our compelling story is us (yes, yes, I know it should have been we, but that sounded too, well, like who we were twenty years ago).

So what does this have to do with certification?

• Certification programs, when done well, focus on employer value. Certification will help us communicate to ourselves what our value propositions are--in terms of value added for employers. Once we understand that value, we become better able to communicate and demonstrate that to our employers.
• Certification can increase jobs within a profession, as employers understand better what value those jobs add.
• Certification can create revenue potential for STC.

So if I get elected as 2VP for STC, I will have 4 active years to work on this. And by the end of that 4 years, my goal would be to have a fully defined body of knowledge in place and a certification program launched that demonstrated multiple levels of competencies within that body.

I have a new column out in UXmatters.com: Hockey Sticks and User Assistance: Writing in Times of Resource Constraints. I blogged on it earlier, but this is a more thought-out (and better edited) version than what you saw in the blog.

I've also updated my web page to include my "platform" for my STC 2VP campaign. Take the STC Campaign-2008 link. In short, my focus as an officer would be to

• Maintain a balanced budget that funds the programs that add the most value for members
• Ensure that our publications and conferences provide the content that helps members do their jobs
• Create a collaboration where members, vendors, employers, and academic communities help technical communicators keep up with the ever-changing demands for tools and technology knowledge
• Support a certification program through STC that helps our sponsors trust and understand our value and that creates sustainable careers for technical communicators

I'll blog more on why I have decided to get on the certification bandwagon after staying off it all these years.

A rose by any other name might have more syllables--
Two blogs in one day! But my last blog was 14 hours and another Board of Directors meeting day, so that's got to be 3 dog days at least.

I annoyed some folks today by referring to what we do as technical writing and by referring to myself as a technical writer. Then I totally blew it by referring to the people who consume what I produce as readers. Seriously, I could tell that I was a major disappoint to them, so it made me pause and think. I have noticed lately that I have been referring to myself that way, not necessarily consciously, but purposely enough to notice that I was doing it. Now that I know I'm disappointing and alarming some folks by doing it, I've decided to reflect and try to understand why I have reverted to these somewhat retro terms.

I think there are a couple of things going on. For one, I'm a little embarrassed by the sometimes pretentious sounding titles we use. My current job title is user assistance architect. I just feel less pretentious telling folks I'm a technical writer. I'm not particularly embarrassed by its more blue collar appeal.

But mainly, I think I am rebelling somewhat against the idea that people didn't respect the job we did because we were called technical writers, and somehow changing it to technical communicators will get us the respect we deserve. It just seems to take our eye off the real ball: When we truly add value and articulate it in real terms, people notice. It has nothing to do with what we call ourselves.

For example, I am aware that businesses need a lot of advanced products and services to support their analysis of data that goes well beyond the need for calculators. But it doesn't bother me that the company I work for that provides all of those advanced needs is called International Business Machine. Nor am I concerned when using an ATM that it was made by a company called National Cash Register. I know their names are somewhat steeped in the technology of their origins, not in their technology or business practices of today. Granted, their names have morphed into acronyms, but they serve as examples (along with the NAACP) that if your actions and results clearly communicate your value, out-of-date names don't seem to be so problematic.

So in the close circle of associates who know my body of work and who see me in my professional environment, I'm going to keep calling myself a technical writer; it's clear, and "writer" is only 2 syllables whereas "communicator" is 5. Plus it's a designation my dog can understand--I think "communicator" throws her. And in my case, it's what I do: I write about technical stuff. I further suspect it's what a LOT of us do.

But I also realize the benefit a name change can have in supporting a changing vision, so I will use technical communication in my public communications--if for no other reason so it quits being an irritant to my professional colleagues.

I'm also going to keep pushing that we focus on defining how we can add real value and quit worrying so much about what we call ourselves.

I Visited the Sausage Factory (and did't throw up)--
Otto von Bismark said, "Laws are like sausages, it is better not to see them being made. " I was wondering if seeing how STC really runs from the inside would be a similar experience. I'm serving as an interim director for the Society for Technical Communication (STC) and I am attending my first board meeting in Arlington, VA. Since I am also running for 2ndVP, this is my first reality check to see what I could possibly be getting myself into. I was pleasantly relieved to see that the process and the environment are pretty sane. (I'm not saying I expected them to be anything else, I'm just saying...)

I am very impressed with the caliber of the STC members serving on the board. I know we're a smart group of communicators, but I did not expect the breadth of business acumen and management skills. I was also impressed with the consultants who reported to the board on several areas of analysis the board had commissioned. One had been done by a CPA who specializes in associations, one by a publications consultant--once again who specializes in association and non-profit organizations--and one by an economist who had done a comparative study of the role of a formal body of knowledge and certification across four benchmark organizations. We also heard some impressive reports from member committees, especially one that had done a similar study of our publications from a more internal perspective. That study dove-tailed nicely with the one done by the consultant.

My impression is that we have a skilled set of professionals in the STC office, a mature set of governance principles, and some exciting challenges ahead of us. The two primary objectives that seem to be emerging are to create a stronger business model that mitigates fiscal risk and to move aggressively to defining our body of knowledge--a hallmark criterion for being a profession. The good part of that scenario is that "fix a broken organization" is not on the list.

So, if elected to executive leadership, I see a clear path emerging before me:

• Continue to improve STC operations that will provide greater fiscal security. (Not that we are in trouble in that regard; it's just that we received some excellent advice about how we could improve.)
• Implement recommendations to improve the effectiveness of our publications
• Aggressively support the Body of Knowledge project

I know there has been some turmoil over the past few years, and I have certainly seen threads of discontent running through some of the forums and blogs. As a profession, we have some great challenges as we see our roles changing, and I think STC is as relevant and necessary as it has ever been for technical communicators. I think the professional and volunteer leadership is as ethical and expert a group as you could ever hope to assemble to meet these challenges.

So I'm going on record: If you are looking for a candidate of discontent (the throw the bastards out platform)--Don't vote for me. I'm pretty happy with what I saw.

And if you've felt alienated or discontented, let's give it a new try. Don't just look to STC to solve our problems, become active and make yourselves part of the solution again.

The Writer with 3 Brains!!! --
Gallia est omnis divisa in partes tres. Anything worthy of discussion can be divided into three parts. As a technical communicator who works a lot in collaborative work groups and who serves on several professional committees, I get to see (and participate in) my fair share of technical communicator fights. I'm beginning to understand that the core of many of these conflicts is that technical communicators have 3 parts to their brains, and most of us have a dominant section (one having a disproportionate influence over the other two) or in some cases a subordinant one (two sections in balance and the third just along for the ride). The analogy is very close to right-brain/left-brain scenarios in that the more we can understand what part of our brain dominates us and what parts seem to dominate others, the better we can understand conflicts (within ourselves and among others) and assemble teams that collectively work with "whole-brain" efficiency.

The Parts
To more easily differentiate this metaphor from the right-brain/left-brain model, I'll divide the writer's brain into rear-brain, middle-brain, and front-brain. Each third respectively represents product focus, process focus, and content focus. (By the way, this is strictly metaphorical and is not based in any way on real brain activity--something I have little experience with.)

Product focus (product in the sense of the deliverable we the writers produce) concerns itself with the mechanics of the document and the language. When we are designing templates, editing for consistency, and making sentences obey laws of grammar, we are engaged in rear-brain thinking. I chose the rear of the brain as the analogy because that's where the medulla oblongata is located. It goes its whole day saying things like, "I'm not sure what you are doing right now, but breathing in and out would be a good thing."

Process focus concerns itself with how communication happens. When we architect what channels we will use for specific tasks and users, plan review cycles, write documentation plans, we are using our middle brain.

Content focus concerns itself with what we are writing about. I choose the front of the brain for the analogy because that is where our personality--who we are-- lives, and the content defines who our document is. As in any metaphor, riding that horse too long is sure to put the ship on the rocks and shut down the show. (First hint of the blog: If you wanted to comment on the mixing of metaphors rather than laugh at it, you might have way too much rear-brain action going on.)

An Example
I think I have an underdeveloped rear brain, which any consistent reader of this blog should have realized by now, and a dominant middle brain. I love information design and architecture, I'm largely indifferent to what I'm writing about, and I'm a terrible editor because I don't value things like formats and language rules unless they are in the immediate context of understandability. When a homeless person tells me, "I ain't got no money," I don't correct his grammar because I understand perfectly well what he is telling me.

There is nothing wrong with having a brain imbalance like this but I need to do a couple of things:

• Realize that when I get in conflicts that the underlying struggle might deal more with focus, i.e., product, process, or content, rather than with logic and rationale. In short, I need to be nicer to and argue less with rear-brainers.
• When putting teams together, I need to try to surround my middle-brain dominance with front-brainers and rear-brainers. In short, I need to make sure I'm on a team with someone who will actually figure out how the product we're documenting works. And I need a good medulla oblongata there as well, someone who takes care of the necessary mechanics.

Sweeping, Unsupported Generalizations
Hey, what's the good of having a blog if you can't just shoot your mouth off and have some fun with it? Here are some traits (some legitimate, some tongue-in-cheek) that will help you spot brain sector dominance.

Rear Brainers (Good and Bad--you figure out which is which)

• Like to design templates
• Worry about presentation issues, e.g., how wide this margin needs to be, how much white space should go above a heading 2, etc.
• Make good editors
• Can suck the life out of meaningful discussions by correcting someone's grammar in the middle of it
• Can bury documentation in mediocrity by insisting that all sections be consistent with the weakest element

Middle Brainers (Good and Bad)

• Help boost a department's process maturity rating
• Create efficiencies
• Like to analyze users and their information needs
• Lose STC competitions a lot
• Say "Whatever" to editors

Front Brainers (Good and Bad)

• Make documents meaningful and useful
• Do a lot of the heavy lifting on a team project
• Insist on sharing every nuance and implication of a technical feature (often ad nauseum)
• Have trouble with deadlines because there is always more to know and say

Conclusion
So where are you on this list? Hopefully and probably everywhere. The point is that we should be more aware of these facets of our thinking and behavior and know when they are helpful and when they are not. Where weak, we should seek to bring the missing factor into the team by recruiting members who are strong in those areas. And when we do, and when we inevitably fight with them, remember we are really externalizing our internal struggles. In other words, I don't fight with my editors because they are too rear-brained; my fight is the result than I am underpowered in that sector. Go ahead and fight, just make sure you fight fair and allow yourself to be influenced by the other.

And don't try to tone down so much if you think you have a dominant sector; rather, work on strengthening your weaker ones.