A techwriter dies and goes to heaven...

and she finds herself at the pearly gates before St. Peter. He looks over her record and decides she is worthy to enter heaven.

"We've upgraded our services recently," he tells her, "so that you now have access to a more personalized heaven experience. Since you are a technical writer, I'll show you several versions of heaven behind some of those doors over there that have been expressly designed to enhance the technical communicator's heaven experience."

"Wow," the techwriter replies with excitement.

"The only problem," St. Peter tells her, "is I just got a text message from the boss and I have to handle it. I'll be back in a few minutes and then I'll give you a tour of your heavenly options."

With that, St. Peter steps away, leaving the techwriter standing in front of three doors. Her curiosity gets the better of her and she opens the first door. There she sees a work station with a bazillion-pixel, high def screen, screaming CPU with graphical coprocessors, loaded with all of the latest authoring tools and a high-speed connection to the UWW (Universal Wide Web). She tries a Google search and instead of getting two-million hits she gets just five, and they are the perfect five.

"This is way cool," she thinks to herself.

She decides to see what's behind the second door. There she finds a cosmic Starbucks. Instead of walls and windows, the table are open to the entire universe and you can almost touch the planets and the stars. Instead of paper cups, the coffee is served in deep blue china mugs. She sees a person putting sugar into her latte (in heaven sugar has no calories) when a tiny paper clip walks across the table and knocks on the mug with a sound of tiny knuckles on glass--tink tink tink!

The paper clip speaks, "I see you're trying to sweeten your coffee, can I ..."

At that point the person fixing her coffee picks up the paper clip, takes a rubber band, and shoots the paper clip out into the vast emptiness of space.

"How cool is that," says the techwriter.

St. Peter hasn't returned yet, so she looks behind the third door. There she sees a technical communicator in a meeting room with developers and she is discussing a user interface being projected onto a screen at the front of the room.

"For one thing," she says to the developers, "you've used 'data base' as two words in the title but as one word in the actual screen. Our style guide says database should be one word."

There is a general round of approvals and one of the developers says, "That's why we need technical communicators on the team."

The technical communicator at the front of the room continues, "And if the user doesn't put the right date format in the date field, you pop up a rather cryptic error message. I think you should just put in some client-side scripting that accepts the user's format and converts it to the format the database requires."

Once again, a general round of approvals and someones says, "Of course, it takes a technical communicator to see it from the user's side. We were too focused on the back-end requirements."

And then the technical communicator says, "I have a report from a usability test we did with real users doing authentic tasks with this UI. I can make the results available to you."

Once again, enthusiasm abounds around the table and someone says, "This is why we need technical communicators on the dev team, they keep us focused on the user, and they have real data to back it up."

At this point, the techwriter hears St. Peter returning and she hurries back to the gate.

"Well," St. Peter says, "let's show you some options for your personalized heaven experience."

"Oh, St. Peter," she says, "I can save you some time. I found my technical communicator heaven; it's behind the third door."

St. Peter looks disappointed. "Oh no," he says, "there's been a misunderstanding. That's not technical communicator heaven; that's the door to developer's hell.

The two most common comma mistakes I see good writers make

As hard as it will be for many of my colleagues to believe, I actually know a couple of grammar rules and even advocate that people follow them.

I just finished a couple of weeks of peer editing and saw good writers making similar mistakes, the same mistakes I see good writers make a lot. The problem, I think, is that our brains know the rules but our fingers ignore them under the pressure of deadlines or when the muse is inspiring us with good content. But for what it is worth, here are the two comma errors I see most often (so if you are guilty of either or both of them, you are in good company).

Punctuating compound predicates as if they were compound sentences

A compound sentence has two complete clauses joined by a conjunction. A comma comes before the conjunction. Example: John wrote the user guide, and Mary edited the installation guide. Two subjects each with their own verb.

A compound predicate has only one subject but two verbs. No comma is used. Example: John wrote the user guide and edited the installation guide. If you absolutely long for a comma in the second example, you merely have to add a subject as in: John wrote the user guide, and he edited the installation guide.

Good writers usually make this mistake when the predicate elements are long, as in: John wrote the user guide that went with the latest version of the TurboPro Archiver, and edited the installation guide that went with the X-Level Wiki Mapper for Linux.

Long, but still a compound predicate and no comma.

Separating a two-item list with a comma

A two-item list does not take a comma. You would never write: You can choose option A, or option B. But as in the first error, good writers confuse themselves when choices get wordy: You can assign users to a category based on the permissions you have granted them in Section 10.4, or based on the profiles you establish in Section 14.6.

Long, but still a two-item list and no comma.

What is getting in the way in both examples is long sentences and the mythical comma rule of "use a comma when the reader needs to take a breath."

No such rule. No NEED for such a rule. None of us has written a technical document so compelling that the reader forgot to breathe. In my own case it's as if I breathe without even thinking about it. My lungs suddenly get hungry for air and wooosh; it just happens. I don't think I've ever heard of a situation where a reader was found blue and unconscious with those around him saying, "Oh my god! If only the technical writer had told him to breathe."

At any rate, be mindful that our fingers and this mythical rule are out to put spurious commas into the otherwise well-punctuated prose of even the most seasoned veterans among us. Keep a watchful eye out.

I won :-)

Get dressed, we're going to a party

On April 22 the Atlanta STC chapter is having its annual awards banquet. Holly Harkness has gone all out to make it a stupendous evening (by that I mean the food will be good, we're going to Maggiano's).

So here's my question: If you are not getting an award, why go to this event? Here are my thoughts:

• If you only go to church once a year, it's usually on Easter Sunday. It lets you remind yourself what religion you belong to, and you get to see everybody all looking nice. If you haven't been going to STC meetings, this is a good one to go to for the same reasons.
• An awards banquet is about professional excellence. Hey, that's why you joined a professional society in the first place. This could be the most important meeting you attend. (And if you're not a member, this is a great way to get introduced.)
• The winning entries are on display. This is the best way to survey what the current standards of "best practices" are.
• You'll be networking with the thought and practice leaders in the area.

Remember when being a tech writer was fun? Join me at the awards banquet and let's have fun again.

Reply versus Reply All

My e-mail inbox is cluttered by something other than SPAM. I am on a number of committees and list servers where I must wade through large amounts of chatter that does not add value, but takes up my time and effort to get rid of. Last week I accidentally deleted an important meeting invitation because I inadvertently deleted it along with this category of junk mail.

Here's what I'm talking about. I got an e-mail reminding me that there is a board meeting this Friday that goes out to all of the board members. That's good. The e-mail asks attendees to verify if they are going to have lunch so that the organizer knows how much food to order. Now starts the litany of emails from individuals saying "I'll have lunch." I get these because the responders click "Reply All" instead of "Reply." (This is just one example of a phenomenon I experience several times a week if not daily.)

STOP IT!

"Reply All" sends your answer to everyone on the original email. Use "Reply All" when your answer applies to everyone, or you want to open up your response to the public scrutiny of the group you are participating in. Who am I to give feedback on who should be eating lunch?

"Reply" sends your answer just to the person who sent you the email. In the example above, only the sender needs to know if you will show up hungry.

And list servers have a sneakier version of the same problem. "Reply" sends the answer to the list server list (EVERYBODY), not the person who wrote the post. That is because the e-mail did not really come to you from the individual; it came from the list server.

I'm sorry for the cranky post.

New Column

I have a new column out in UXmatters today called Placing Value on User Assistance. It's a topic I have blogged on before, but the column has a nice shiny picture as my colleague Mark Wallis would say. Speaking of Mark and pictures, right after WritersUA, Mark let me be his gear monkey while he took nature shots around and up Mt. Hood outside of Portland. Awesome! We went from mossy rain forests to 25 feet of snow in less than an hour.

WritersUA was great. The presentations were their usual high caliber, the vendors just chock full of new features, and the networking as valuable and enjoyable as ever.

Great Currents Conference

I went to the Atlanta STC regional conference, Currents, this Saturday. As always, it was a great professional motivator and a chance to chat with some of our leading technical communicators. And Jean-Luc's final slide was right, I will never be able to look at a road sign the same way ever again. Yesterday on my way to the airport, I saw one of Jean-Luc's favorites:

State Law
STOP
Yield to pedestrian in crosswalk

Jean-Luc's point is that it is strange that we need to be told to do this, as if we would have hit them otherwise, and that we must be told it's the law (as opposed to a guideline, I guess.) Jean-Luc forgets that we are the culture that created the video game Death Race 2000 where you get points for hitting pedestrians.

The reason I was going to the airport is that I am in Portland, Oregon, this week for the WritersUA conference. First Currents and now WritersUA! I'll try to post on the conference this week.

One more thing, on the Portland light rail, nobody checks to see if you bought a ticket. It's the honor system. Kind of a nice contrast to "No running over pedestrians or else we'll give you a ticket."

Instructional Text on the UI

Embedded assistance makes us reevaluate some tried and true principles of information design because our instructions occur within an action-packed medium--an application's user interface. If you think you have trouble holding a student's attention in the classroom, try teaching in a video-arcade. In many ways, embedded assistance has the same challenge.

Having said that, I'm going to shoot you over to a column I wrote a year ago for UXmatters called Instructional Text in the User Interface: Some Counterintuitive Implications of User Behaviors .

News

• Check out Martha Stevens new blog on user assistance. Martha's voice and insights will be a good addition to the blogosphere.
• Currents (Atlanta STC regional conference) starts in a few days. Shout out to my buddy, Miranda Bennett, who will be doing an interesting presentation on collaborative walkthroughs.
• And with the start of daylight savings time, I'm back on my routine of going fishing every Wednesday afternoon after work. Actually, I sit in my kayak on Stone Mountain lake, drink two beers, and smoke a cigar while pretending to fish. I have come to the very serious realization that life balance is important; do you have something you make time for every week that is just for you? (Tip: Scheduling something for mid-week is a great way to break up the work week.)
• Voting for STC officers starts next week. If you are an STC member, vote early; if you're voting for me, vote often.

MOO POPs

I want to discuss MOO POPs early in this series of blogs on embedded assistance (EA) because the concept drives straight to the heart of EA: When and where do we need it?

MOO POP stands for "Moment of Opportunity" and "Point of Pain." A moment of opportunity refers to a state in the user interface when we can intervene and move the user to increase his or her adoption of the product. I wrote an article for the Cutter IT Journal last year about progressive user adoption that talks about the ability of embedded assistance to increase user adoption of advanced features based on detecting user readiness for that advanced feature. For example, a useful feature in Microsoft Word is its ability to automate header content using heading tags in the document, such as making the current Heading 2 the header entry. When would you point that out to the user? If someone is in the act of defining a header, that could be the appropriate moment of opportunity. Imagine a link on the header dialog box that said "Tell me how to automate my headers" and which launched a popup that explained how to do that.

A point of pain is where we anticipate that the user might run into trouble. For example, if we provide a field for entering the name of a firewall rule the user is creating, and the developer points out that the database cannot accept spaces in the name, we can reasonably anticipate that some users will screw up. A simple statement next to the field that says merely "No spaces" will save innumerable instances of error messages popping up. In general, the following situations are good candidates to be points of pain:

• When choices or actions are grayed out (Hey! why can't I do this?)
• When we ask users to make decisions (Did you want DES, 3DES, or AES encryption?--say what!)
• When business or validation rules will lead to likely error conditions

So one of the first lessons in doing embedded assistance is that you do not have to be consistent, and by that I mean you don't have to treat all fields equally. The field that asks the user to type her first name does not need embedded assistance; the field that asks her to create a new password probably does (as in what are the rules for a valid password).

The guiding principle should be "Is there a moment of opportunity or point of pain that justifies taking up room on the user interface?"

In my next blog, I will talk about how to maximize effectiveness and minimize the intrusiveness of the EA entries on the user interface.

Embedded Assistance

I'm working these days on some very exciting projects involving embedded assistance. Embedded assistance (EA) is user assistance that is incorporated directly into the user interface, specifically, assistance that does not require the user to go into a Help file or document. Although most people think of embedded Help panes that exist along the right or left side of the application screen when you say embedded assistance, that is just one aspect of EA--and quite frankly, one of the less important elements. Embedded assistance incorporates any text or communication within the user interface that informs or instructs the user:

• Field labels
• Inline instructional text
• Error or information messages
• Button labels
• On-screen examples
• Hover text
• Tool tips

And beyond this obvious list of element where words are involved, I also include other design considerations such as grouping and sequencing of fields on the UI.

I'd like to give a shout-out to Fred Sampson, a colleague of mine within IBM, for the leadership he has shown in taking me down this path. In the next series of blogs, I will be relating research and guidelines Fred has helped assemble along with tips and how to's from my own experiences helping my division move in this direction.

Why embedded assistance?

Today's blog focuses on why user assistance writers should shift their focus from traditional Help and concentrate more on embedded assistance.

1. Users don't go to Help.
2. Embedded assistance keeps users in their task flow.
3. OK, some users eventually go to Help, but then it isn't helpful.

Users don't go to Help

In most corporate cultures there is somewhat of a dichotomy between working and learning. By that I mean we think of the two as being different activities. We say things like "I won't be at work next week because I'm going to the WritersUA conference." Or when an inhouse training session comes to an end, someone invariably says, "Time to get back to work."

Users see going into Help as being an interruption to work. I used to complain about users who were "too lazy to read the manual" until I started doing usability testing. I then realized that the users were working very hard to get the task done, and they were not going to Help for that very reason, they were focused on the task and that is where they felt they should stay.

Staying in the task flow

The best place to put user assistance is in the UI where and when the need occurs. I like to talk about MOO POPs--no, not milk-based Popsicles, moments of opportunity and points of pain. Understanding where the MOO POPs are in your application is a critical aspect of designing good EA. I will blog on that later.

Why Help is anything but

When I watch users doing a task and then watch when they eventually go into Help, more times than not the Help is not helpful. It's not the writer's fault. See my UXmatters column Stepped Procedures: The Sacred Cow Blocking the Road for an explanation of why there is often a mismatch between the user's question and Help's answers.

Upcoming blogs

Tune in for the next few blogs as I go deeper into the following:

• MOO POPs
• Progressive disclosure (an essential technique for EA)
• How to sell the developers on letting us into the UI

February 29th: Bonus Day!

Every four years something remarkable happens; we are given an extra day. Today is that day; do something with it. Here are some options.

• You probably have the latest Intercom or Technical Communication sitting on your desk. Find a good article in each and read it.
• Your inbox has 476 emails in it. Clean them out.
• Download trial software and play with it.
• Organize the rest of your year.
• Go around the office being extra nice or cheery.

You get the idea. Today is a free day, a time-out from the 365 day grind. Make it special and in doing so make yourself special.

Happy bonus day!

Currents Is Almost Here--
In times of tight budgets (and why are we ALWAYS in times of tight budgets) the Atlanta regional conference Currents is a great professional development bargain for those in the neighborhood. So put March 14th (workshop day) and 15th (sessions day) on your calendar.

The quality of the presentations is world class:

• One of the speakers, Dr. David Yates from Auburn, has an article in the just published February issue of Technical Communication.
• At least four university programs are represented: Mercer, Auburn, Georgia State, and my alma mater SPSU (also the venue of this year's event)
• Speakers from major corporations will share their insights: IBM, Mirant, ComponetOne
• I can see that at least two of the presentations (mine and Carol Barnum's) are part of the 55th conference in Philadelphia.
• STC leadership will be there: Mark Clifford, STC 1st VP (upcoming president in June)-- and local boy 2ndVP candidate will be there kissing babies :-)
• International keynoter: Jean-luc Dumont--just saying his name is worth the price of admission

And the networking is always great. So get your head out of the read-me you're working on, or that configuration guide, and rub shoulders with fellow professionals and talk about your craft. Celebrate your professionalism!

For full details go to http://www.stcatlanta.org/currents.htm

ROI--
Those wishing to go beyond Kirkpatrick's 4 levels that I discussed in my previous blog, can talk about Return on Investment (ROI). In short, does the dollar value of the benefit exceed the cost, and if so, how does it compare to other investments a company could be making? Cutting to the chase, what do companies get for their investment in technical communications (measured in financial terms)?

First, the math: ROI = $Results/$Investment.

You face three challenges when you try to do an ROI justification (or claim an ROI victory):

1. Isolating the effect that technical communication had from what everybody else did. For example, did the Help desk calls go down because the Help was better or because the product's design improved?
2. Putting a dollar value on the benefits. In the case of improved efficiency, this is easy enough: (time saved per transaction) x (number of transactions) x (labor cost). Putting a dollar value on increased customer satisfaction scores gets a little foggier.
3. How does the return get harvested?

Challenges 1 and 2 get a lot of attention in the ROI literature so I'm going to skip them. I think #3 is the elephant in the room that nobody wants to talk about.

The R in ROI is "return" and can occur in one of two ways: Checks coming in get bigger, or checks going out get smaller.

I see lots of ROI examples and arguments around scenarios where better documentation reduces the search time of the user. I know that Information Mapping's web page used to have a calculator program that would help you arrive at the dollar amount for what you could save your company. Let's say you do such a calculation and can show a return of $175,000 a year for an initial training and document conversion cost of $100,000. That's a good ROI. But what do you do when the sponsor asks for her $175,000? After all, she did her bit and forked over the $100,000. Where does it come from?

"Uh, people did more work."

Great, did we charge more for the extra work, is my $175,000 in income? Can you point me to it?

"Uh, well, they were more efficient and did the same work in less time."

Great, did my payroll go down $175,000? Was headcount reduced as a result of this innovation?

And this is the problem with many ROI scenarios. They look great until you try to lay your hands on the money. So what's my suggestion? Don't go there unless you can actually produce the increased savings or income in real ways that can be pointed to. If DITA reduces translation costs, go for it. If you say you're going to make content more reusable, be prepared to see headcount cutbacks in future budgets. Hey, you were the one that said you would be able to do more with less.

Bottom line: Don't get into the ROI game because it makes you sound more business-like. Use it only if you can cough up the bucks when your investor asks, "Where is my return?"

A Model for Assessing Value--
I've been thinking and talking a lot lately about our value as technical communicators. I can see that my thinking has been influenced by my background in instructional design, specificially by Kirkpatrick's model of evaluation. In his model, he states that instruction can be assessed at four levels:
Level 1: Reactions
Level 2: Learning
Level 3: Transfer
Level 4: Results

I think we can easily apply this same model to how we evaluate our communication products as well as our contribution to our sponsors.

To summarize the four levels in the context in which Kirkpatrick proposed them, I put them in the context of a training course on how to correctly operate a drill press. Let's assume the training had been triggered by excessive scrap rates coming out of the machine shop.

1. Reactions. How did the students react to the training itself? This is generally assessed through a course evaluation sheet, e.g., course met my expectations, instructor was knowledegable, yadda, yadda, yadda.
2. Learning. Did the students learn anything? This is generally assessed through testing or lab observations. Students could be obseved by the instructor who certifies them using a checklist of targeted drill press competencies.
3. Transfer. Did the student go back to the job and apply the new knowledge or skills correctly and effectively? Employees coming out of the training could be assessed by the shop supervisor who observes if the they are applying the right techniques.
4. Results. Did the training solve the business problem that triggered it? Did the scrap rate go down?

By the way, Phillips adds a fifth level, ROI, which would compare the cost of the training to the dollar value of the reduced scrap and compare it to other investments that could have been made.I'll blog on that one later.

So let's see how Kirkpatrick's model could be applied to technical communication.

Level 1: Reactions--We see this in reader response cards and in usability tests where participants are asked to rate various aspects of a product or document. Lots of the research done on fonts or layout stop at this level of evaluation, e.g., which document looks more professional?

Level 2: Learning--To me this translates to: If the user read the document, did he or she understand it and did it apply to the task at hand. For example, did the Quick Start card work in the lab when we specifically asked users to use it?

Level 3: Transfer--Oooooh, the toughie. Did users improve their performance in real life based on the documentation? For example, did real patients comply better with their medication protocol when given redesigned instructions?

Level 4: Results--Did we achieve the business goal the document was meant to achieve? For example, did Support Desk calls go down, did medical claims decrease, did user registrations increase on a redesigned web page, did percentage of transactions completed go up, etc.

I think we need to emphasize levels 3 and 4 more. I might be wrong, but I haven't come across a research study on fonts that tested if users completed tasks faster or made fewer errors depending on which font face the Help was written in. (So why do we fight so passionately about it?) So I would like to see research in our field increase its emphasis on user performance. (Level 3)

I would also like to see more discussion about the how better informed, better performing users make positive impacts on an organization's business performance. (Level 4)

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.