Why I Stopped Reading “Dilbert”

These days I have to pick and choose what I read. I still read newspapers, but mostly through the web. I still read comic strips, though mostly through subscription emails. One strip I used to read, and even subscribed to, was Scott Adams’s “Dilbert.” But I’ve given it up, and I thought I would tell you why.

I discovered “Dilbert” a few years after it started. I read it each day with astonishment. Like many high-tech workers, I thought Adams must have worked in my company, so accurately did he capture the zeitgeist of the industry. Of course I identified with Dilbert and despised the imbecilic Pointy-Haired Boss (disclaimer: I have worked as a manager). Later I learned that Adams had worked not at my company but at Pacific Bell, where his strip irritated his bosses. Eventually he was laid off; I won’t assign causality, but I’m sure he’d agree it was the best thing that ever happened to him, because he could devote his attention to something he did better. I subscribed to his daily emailed strip. I bought his anthologies. I bought his audiobook The Dilbert Principle. I was a loyal reader.

A 1995 strip debuted Tina the Brittle Technical Writer, who demands respect but does nothing to earn it. The Tina character provoked a long discussion on TECHWR-L, which someone forwarded directly to Adams. He quietly subscribed to the list, lurked for a while, then wrote to listowner Eric Ray:

This was the most negative response I’ve ever gotten from a strip. And probably the most entertaining. Consequently, I plan to introduce a tech writer character in the next few months who is a composite of some of the more interesting personalities I picked up from the list.

God, I love my job.

Hmm…

When a cartoonist’s work becomes popular, people want to know about them. In the spotlight of publicity, some emerge as beloved figures (Charles Schulz); some remain enigmas (Bill Watterson); and some don’t do themselves any favors (Al Capp). In the fullness of time we began to learn about Scott Adams, and he was … disappointing. In March 2011, for example, he penned a notorious piece on men’s rights, which drew considerable ire, that included this passage:

The reality is that women are treated differently by society for exactly the same reason that children and the mentally handicapped are treated differently. It’s just easier this way for everyone. You don’t argue with a four-year old about why he shouldn’t eat candy for dinner. You don’t punch a mentally handicapped guy even if he punches you first. And you don’t argue when a women tells you she’s only making 80 cents to your dollar. It’s the path of least resistance. You save your energy for more important battles.

He deleted his post (which as you can see doesn’t work on the Internet) and claimed it was all a joke that we weren’t clever enough to see. But later he was caught defending his views on Internet message boards using an assumed identity (aka “sockpuppetry”), which some consider plagiarism.

Now, I’d like to think I don’t care about the personalities and political views of artists. If you avoid the work of Barbra Streisand and Sean Penn because they’re liberal, or John Wayne and Charlton Heston because they’re conservative, you’re missing out on some really good stuff. (The acid test is Wagner.) I hope there was no leakage of my opinion of Scott Adams, the person, into my opinion of Dilbert, his creation. But an odd thing happened. As my opinion of Adams was plummeting, Dilbert seemed, to my eyes anyway, to evolve from an oppressed worker through depression and defeatism, and then to lashing out verbally at everyone he encountered. Somewhere along the way I stopped finding him amusing. If Dilbert were a coworker, I could totally understand and sympathize with his frustrations. God knows he bore up to his situation better and longer than I would. But he snapped. A couple of years ago I started to think of Dilbert not as a long-suffering white-collar worker who commented wittily on his situation but as an asshole who brought on and deserved his mistreatment. If he were a coworker I wouldn’t want anything to do with him. It wasn’t just Dilbert; the whole office became like that. Their manager, while no less an imbecile, began actually to draw my sympathy. If Dilbert worked for me I would probably grow to despise him too. In a twisted way “Dilbert” began to resemble a comic strip about a dimwitted manager saddled with a despicable employee who led his coworkers in open revolt. Viewed through that prism, I stopped being entertained by the strip. And I have too much to do to waste my time on entertainment I don’t enjoy. So I unsubscribed.

Losing me as a paying customer and loyal reader makes no difference whatsoever to Scott Adams, who still has plenty of readers. He made a fortune doing exactly what he wanted, and I salute him for it and wish him continued success. But he won’t get any more of my money. I wonder: did Adams change? Did Dilbert? Or have I made the mistake of letting my feelings about a creative artist cloud my views about his creation?

I haven’t given up on the medium. I still subscribe to daily emails of the brilliant, evergreen “Doonesbury;” “Foxtrot,” which is smart and reliably good for a laugh; and “Calvin and Hobbes,” Bill Watterson’s masterpiece, which he ended 17 years ago but which I still find entertaining and insightful. (By the way, the cartoonists Dan and Tom Heyerman have drawn four individual strips imagining Calvin as a grown-up and father himself, called “Hobbes and Bacon.” You can check them out starting here.) I’ve just given up on “Dilbert.”

How about you? Do you still read and enjoy “Dilbert”? Is it unchanged and still witty? Is this a case of “lighten up, Francis”?

Herman Melville, technical writer

As I write this, the anniversary of the publication of Herman Melville’s Moby-Dick (as it was originally titled) is noted on Google. The novel is getting a celebrity Web reading. What timing! I recently finished listening to a complete audio recording. (Thanks, LibriVox.org!) The work is on the short list of consensus nominees for The Great American Novel, and I recommend giving this challenging masterpiece a listen (or a read).

There are many fine analyses of the novel, to which I cannot add. Melville’s first two books were actually memoirs of his travels in the Pacific, but the settings and events were so fantastical that readers and critics alike took them for fiction. Moby-Dick was also inspired by true-life events: the 1820 sinking of the whaler Essex by a sperm whale, and a legendary white whale called Mocha-Dick that allegedly survived over 100 encounters with whalers. Melville did extensive research on the subject, and this time, even though he was writing fiction, he wanted to establish verisimilitude. He intermixed fact and fiction in 135 often confusing chapters, plus etymology and epilogue, throwing together first-person narration, omniscience, stage directions and labeled dialogue, free-standing short stories on various subjects, and long technical treatises complete with footnotes. In the non-fiction, technical chapters, he presents detailed information with precision and clarity. In those chapters I think I recognize the kindred spirit of a technical writer.

First, Melville was a masterful writer who constructed vivid, impeccable sentences. He had actually served on a whaler, so he had experience on which he could draw. (It always helps to understand your subject matter!) To supplement his personal experience, he plainly made extensive study of the techniques, science, history, and literature of whaling, and in various chapters he passed on what he had learned. (Learning and then teaching are subconscious joys of technical writers.) In the book he goes into great technical detail about the construction of whaling vessels and chase boats, the anthropology of the characters, the biology and comparative anatomy of whales, the psychopathology of monomania, the sociology of religion, and even what he understands of the whale’s relationship with other species (anticipating Darwin by eight years). In these chapters Melville writes with authority and clarity. Chapters 74 (“The Sperm Whale’s Head—Contrasted View”) and 75 (“The Right Whale’s Head—Contrasted View”) are intermezzos after these two whales were taken in the fictional narrative, but might as well be part of a text on comparative marine anatomy, where they would serve as vividly written walkthroughs.

Indeed, part of the difficulty of Moby-Dick is its digressions, which interrupt the narrative flow and annoy the reader who just wants to get on with the chase. (In his screenplay for the 1956 movie, Ray Bradbury, who confessed he could never get through the book himself, ignored all those chapters.) But it’s all right to skip them. In technical-writing parlance, those chapters are modular, and can be read in any order or skipped at your convenience. The fictional narrative was the organizing structure through which the technical chapters were interspersed.

Not everything Melville wrote was accurate, of course. He, or at least Ishmael, rejected prevailing theory and incorrectly regarded the whale as a fish, not a mammal. He also listed the blue whale as apocryphal. But most of what he wrote is correct and accurate, and serves as a record of the lost practices and technology of whaling.

By the way, Melville was like a technical writer in one other respect: the first edition of his book was incomplete and needed updating. The version that appeared in England was rushed to press and lacked the epilogue, which explained (spoiler alert!) that Ishmael, the narrator, survived the encounter with Moby Dick. (The initial critical reviews harshly questioned who could be telling the tale if all hands perished.) As any technical writer will tell you, always inspect the golden master!

The Evidence of Things Seen and Unseen

Our first home was unfinished. (It was the only way we could afford one at the time.) We finished the second floor ourselves, and we learned how to build it along the way, so it wasn’t of the highest quality. The house itself wasn’t framed perfectly plumb or square to start with, but houses never are, and we had to square up the interior walls. We did pretty well, though a couple of times I toenailed walls out of position and had to bang them back into place, usually by adding one or two more sixteen-penny nails to get a majority-rule location. Given our limited funds, we used a few pieces of warped lumber rather than buy more, and there were plenty of rose marks where we overhammered, but those imperfections were covered by sheetrock. The sheetrock gapped slightly in a few places, and I misplaced or overdrove a few drywall screws, but I aways added more as necessary, and anyway all that fumbling was covered by a skim coat of plaster. There were a few ripples in the skim coat, but vigorous sanding smoothed most of them down and the remaining flaws we covered with the finish carpentry. (By then I was using a nailset.) And where there were small imperfections in the baseboards, I painted, or we wallpapered, so as to hide them. We sold the house when our family grew, and the new owner today is unaware of where I had to bang a wall true or shim a two-by-four or plaster over an empty screw hole unless he guts the upstairs. (Don’t worry, everything was done to code.) Each layer of work repaired, or hid, the imperfections of the previous steps.

I worked at Digital Equipment Corporation during its halcyon days, when it was the second largest publisher in New England. (IBM was first.) Digital submitted about a third of the entries for our local STC publications competition and won about a third of the awards. Our corporate style was solid and our work deserved the recognition. We also had a full team producing each book: managers, writers, editors, illustrators, production specialists. There was no way for a judge to distinguish between, say, an update that was produced by a good writer needing minimal editorial support and a new document that was produced by a less-than-competent writer who required extensive rewriting, heavy editing, and last-minute assistance. The final results might be equally good—and the competition judged results, not effort—but the effort and workmanship that went into different documents varied significantly. In a sense, an information product that a user finds effective can be “good” in that it was created with minimal effort and fuss, or “bad” in that it was created with much extra effort. That’s the basis of the distinction between product quality and process quality.

Whether you’re building a house or creating an information product, poor workmanship may be invisible to the end user, but it makes building and maintenance slower and less efficient. At one company, while revising a manual, I wondered why adding a few words to certain paragraphs was ruining the formatting. I found non-breaking spaces throughout the source files, and eventually realized they were in material that the previous writer had copied and pasted directly from Lotus Notes email messages. Aside from adding zero value, the writer had created a maintenance problem. At another company, a writer helping out on a large project contributed a dozen screenshots but named the files completely differently from the convention established for the first 300. It was possible to find those rogue files in the art directory, but it took much longer than it should have. A similar problem can occur when a team member doesn’t follow the filename conventions for a document assembled from 500 XML topics stored in a CMS system.

A file can be correctly named but its contents can be incorrectly formatted or tagged. For instance, if headings are mistagged using bold (a presentation format) instead of title (an information type), they will look the same when rendered but can’t be reused, and probably won’t correctly render, in another medium. At his presentations, the always entertaining Neil Perlin sometimes buries his face in his hands to convey the horror of one of his contracts, trying to convert into online help thousands of pages of Word source files, when he discovered that every heading and format was a restyled Normal paragraph. I’ve seen the same problem with files converted to XML format. I can understand how it happens in automated conversion, but it’s lousy if a new writer does it to existing material!

Having judged in publications competitions, I recognize superficial similarities to certification evaluation. In both cases, submissions are evaluated by multiple trained evaluators, working double blind against established criteria. But our certification evaluation has a significant advantage over publications competitions. We ask not just for work samples, but also for for work artifacts and commentaries. We go behind the finished product and examine the workmanship that went into the framing and plastering. We don’t go to the source-code level, but we definitely probe beneath the surface.

For example, we ask for samples of work; but we also ask what the applicant’s role in producing it was, what was planned, why the applicant made the design decisions, and why there are deviations from that design (if there are any). This kind of commentary-based assessment is common in the field of education, and there is called “true assessment.” By not just showing work but also discussing it, the applicant must demonstrate not just competency but conscious competency: this is what I did, and this is why I did it.

In fact, I’m enthusiastic about our criteria for certification, because they allow an applicant to demonstrate competence even in the absence of work samples that demonstrate the competency. Let me explain how. If Digital won any publications awards back in the day because judges liked our use of Chinese Red to indicate user input, it was a mistake, because color is not supposed to sway judging. Why Chinese Red? I don’t know; it was a corporate decision made before I started there. Today blue is much more fashionable. But why? If you ask writers, illustrators, or document designers today why they use blue highlights in their work, you will get a range of answers (one of which is my current answer):

  • The last writer used blue, and I’m just doing an update.
  • I was told to use blue.
  • The template uses blue.
  • Blue is our corporate logo color.
  • I don’t know why I use blue.
  • I think blue is pretty.
  • I think blue is restful.

To be clear, we don’t ask about highlight color as part of our certification. But given our method of evaluation, if we did, even an applicant whose work samples are all in black and white could discuss color design decisions. You can show us what you do, yes; but you can also show us what you can do.

Our evaluation methodology levels the playing field between applicants who work in large organizations and those who work in small groups, or who work alone. We are able to get beneath the surface and see the workmanship.

New Models for Technical Communication

I was very impressed by Ellis Pratt’s presentation at the 2012 STC Summit, “What Should Technical Communicators Do When Products ‘Just Work’?” (If you missed it, and you didn’t purchase Summit@aClick, he’s repeating it as an STC-sponsored webinar on July 10.) He identifies a product trend away from “big and scary and likely to break” to “it just works,” and discusses how that trend affects user information. His ideas sparked some of my own in two areas: on levels of information and on the idea of letting customers document products for you.

Levels of information

I have documented products with big and scary interfaces that were likely to break. (If you only knew how easily…) I agree that today’s products effectively hide their complexity. The programmable interfaces of early computers were hidden and eventually replaced by command-line interfaces, which in turn were hidden and ultimately replaced by graphical user interfaces. The touch interface hides even GUI complexity, and it will soon be more correct to say that touch interfaces don’t simply hide but replace GUIs. (Already, when my son shows me something on his laptop, I find myself trying to touch the screen, which annoys him. “Stop doing that! It’s not your iPad” he says. “Doing what?” I say, momentarily nonplussed.) Today’s products are more powerful than ever, yet their user interfaces are simpler. But the complexity still exists. Today we’re learning the difference between touching a tablet with one, two, three, or four fingers. (Can five be far behind?)

 

iPad touch interface
Even tablet touch interfaces have hidden complexities (image from CallingAllGeeks.org)

 

Looking at software products, there are obvious examples of products that are common and “just work.” Every browser has a search box, and most of them point to Google. Using Google has already become a verb (“I googled the answer”).

Browser search box pointing to Google
All browsers have search boxes, and most of them point to Google, but not one person in 100 knows all the Google search features

There’s no Google manual or Google online help. But do we need it? By now everyone knows how to perform an effective Web search using the Google engine, right? Not so. There are powerful search features hidden under the surface, including Boolean searches, searches with exclusions, searches limited to the body of Web pages, proximity searches, and a lot more. (What does adding a minus sign to a keyword do? How about a plus sign? Are you sure?) Not one person in ten knows more than the first of these features, and not one in 100 knows even what I listed here.

(An aside: Why bother paying a technical communicator to document ubiquitous products when everyone is posting tips and tricks to the Web? Let me turn the question around. Posting tips and tricks a few at a time is very inefficient. Why do users feel compelled to do it? Is it because they can’t find them from the vendors? And another thing: Google paid many talented software engineers to create those features that arguably few users know about. They apparently didn’t pay to have these features documented, but they paid to create them. And they’re hardly alone in this practice. If paying to document features nobody uses is a waste—and I agree that it is—how about paying to develop and test them?)

I think Pratt has definitely identified a product shift we as technical communicators must deal with: the simplification of user interfaces, at least for computer-related products. As I said, by now we’ve seen several generations of simplification. Nothing is ever really intuitive, but over time people generally learn how to use common product interfaces. Until the next big thing comes along, which we’ll have to explain, this is not where we should concentrate our energies.

But there are levels, or layers, of information. How to manipulate a product’s user interface is only the lowest level. Unless the interface is unique, we can strategically retreat from that level and still find plenty of ground to cover. The next level is how to work the product; that is, what tasks can be accomplished using the product. You could write a generic description of a web browser interface and use it verbatim for ten thousand products. But what information the user has to enter in the fields… ah, that’s the second level, and there every product is different. We still need to document that second level.

There’s also a third level, which is the description of local procedures specific to one set of users. We cannot even see that level when working for OEMs. For example, when I want to take a day off from work, I have to create a paid-time-off request in my company’s HR database. It’s an off-the-shelf Oracle application, but customized by my company, so the Oracle writers can’t tell me what code to enter.

The wisdom of crowds?

Google and other search engines represent both a threat and an opportunity for technical communicators. We are increasingly asked to provide online information amenable to search, even to the extent of abandoning indexes and tables of contents; or to outright post user information to the Web so search engines can find it. And, some actually say, why even bother? So many people are posting to forums and to YouTube with product information that we might as well let the magic of the marketplace document our products for us. (You can pick up your last check on the way out.)

It’s true that for certain classes of consumer products plentiful information is available online. There are some distinct advantages to third-party information. Use cases are best coming from actual use. You may not be allowed to describe problems with your product, but the crowd will find it. I daresay most of the product information on the Web is accurate, and, for well-regarded products, I daresay most of it is positive. But any company that relies on its customers to provide free documentation will get what it pays for, and by doing so it abandons control of the message. Even for consumer products that I know are federally regulated and carefully documented, such as lawn tractors, you can go on YouTube and see videos of misusage that would make their corporate lawyers’ heads explode. No company that sells a product that can injure or kill their customers can ignore legal liability and let the crowd teach each other how to use it. Can yours? It depends on whether you think something like this inspires caution or emulation. (If it were my company, you’d have me at “legal liability.”)

Go to the Apple support forums with a problem and search for  a solution. (Believe me, I have.) You will find lots of posts from people with the same problem, perplexed and angry and exchanging ideas that don’t work. A heroic few know what they’re talking about and struggle to answer the questions. With luck you can discern which ones are which. It doesn’t leave a favorable impression. And this is for the company that enjoys the highest customer satisfaction ratings in the industry! Your product will do worse. Remember, a dissatisfied customer will talk to more people than a satisfied one; the ratio I’ve seen is three to one.

Speaking as a consumer, then, I regard information posted to the Web as suspect, because it isn’t uniformly positive or even correct. This is equally a problem for information producers. If you don’t control the message, you might not like the result.

Finally, if I haven’t yet disabused you of the notion of crowdsourcing, if your product is regulated, not a consumer product, proprietary, military, or (in my case) the user community is small, you can’t even dream of crowdsourcing, because you just won’t have a crowd!

So, all in all, are you sure you want to leave your documentation to the crowd? I didn’t think so. If someone suggests it, I think these are all persuasive counterarguments.

STC Summit 2012: The certification perspective

Ever since last year, when we announced that the STC certification program was “open for business,” I have been thinking of this year’s Summit. My goal was to step up to the podium at the opening general session and announce the first Certified Professional Technical Communicators™. It motivated me through a year of committee meetings, establishing policies and procedures, contract negotiations, beta testing, budgeting, and evaluation.

On Sunday, May 20, the vision came true! But it was only through a year of hard work by everyone working for the Certification Commission (mostly as volunteers), and it only happened at the end of several days of intensive pre-work in Chicago before anyone but the STC staff was even on site.

The certification commissioners actually arrived on Wednesday, and we spent all day Thursday and Friday in working meetings. Kathryn Burton, who’s a certification commissioner in addition to her duties as STC Executive Director, was essentially in two places at once, participating in our meetings and preparing for the STC Board meetings; I don’t know how she did it, but she did. Liz Pohland, by day the editor of Intercom and in her spare time (hah!) our staff liaison, was also present and fully involved. While we were at it, we also evaluated some late entries.

On Saturday, when the STC Board first convened, I presented the Commission’s first-year results and financial statement to them. They asked some pointed questions about costs and projections, which is only appropriate.

On Sunday afternoon I rehearsed my presentation. I had to coordinate with Barbra Sanders and Steve Skojec of the staff to cross-check the up-to-date list of certificants against the list of Summit attendees, and ensure that everyone was working off the latest script. I went over everything: going up on stage, looking out at the audience, speaking clearly, gesturing, posing for the photographer, walking down the stairs without tripping.

Finally the moment arrived: the opening general session! I announced the names of the first CPTC™ recipients:

Speaking at the Opening General Session
For the second year in a row I was privileged to address the opening general session (photo courtesy STC)

Over the past year our volunteers have spent countless hours developing a solid, high-quality credentialing program that benefits you as a practitioner and elevates our profession as a whole. Today is an important day for the profession and for the Society. Today, we introduce the first practitioners who have taken this important step and made a difference in their careers by earning the Certified Professional Technical Communicator™ credential…

Now, let’s take a moment to recognize the first CPTC™ certificants. I’m happy to say that some of our certificants are with us this evening, and I’m delighted to invite them up to receive the first CPTC™ certifications!”

Stephen Daugherty
Stephen Daugherty, CPTC (photo courtesy STC)
Michael Opsteegh
Michael Opsteegh, CPTC (photo courtesy STC)
Cheryl Taylor
Cheryl Taylor, CPTC (photo courtesy STC)

For each of the eight charter recipients we displayed a slide with their name and photo. For the three who were actually in the audience, we put their certificates into plaques for the formal presentation. The first few people I named weren’t at the Summit. But Stephen Daugherty was, and he became the first person to receive a CPTC™ certificate, followed by Michael Opsteegh and Cheryl Taylor. We hadn’t had the chance to rehearse this part, but I think it went well.

(Rookie presenter mistake: I forgot to let Stephen and Cheryl hold their plaques for the photos. Michael, who evidently has a little more experience in these matters, grabbed it.) We also made up a supply of buttons for their conference badges, and I handed one to each of them along with their plaques.

I was deeply gratified by the audience’s warm reaction and support. From the look on their faces, I can tell that Stephen, Michael, and Cheryl felt the same way. Me? I get terribly self-conscious smiling for a photo, so you can’t tell from looking, but I was very happy for them, and very satisfied to know that five years of effort on my part, and literally a generati0n of work by a succession of STC volunteers, had come to fruition.

When I finished my prepared remarks I started to leave the stage. But I noticed the TelePrompTer scroll up “Steve ad lib,” which wasn’t in the rehearsal script… Then STC President Hillary Hart, who had been standing to one side during the presentation, unexpectedly called me back to the podium. When she started to describe the President’s Award, I realized she was talking about me.

President's Award announcement
Surprise! Hillary Hart had something for me as well (photo courtesy STC)

 

(Turns out Steve Skojec had prepared two sets of scripts, and two sets of slides, to keep me in the dark about the award while I was at the rehearsal. Sneaky! The staff went so far as to post a lookout at the door while they rehearsed the actual award presentation. And boy, did he let me know afterwards about the extra work they went through 8^)

Some people have asked me if I knew I was going to get the award in advance. I did not. I’ll tell you, though: while it may have my name on it, without the work of all the volunteers and staff associated with the Commission—some of whom I’ve mentioned here but more of whom I haven’t—my name would never have crossed Hillary’s mind.

 

 

 

 

After the keynote speaker finished the action moved to the welcome reception in the exhibit hall, where the Certification Commission had a booth. That first evening was a happy blur, but over the course of the next two days fellow commissioner Karen Baranich, my friend Taryn Light, I, and others logged quite a few hours at that booth.

Commission booth at the exhibit hall
Commissioner Karen Baranich and I staffing the Commission booth in the exhibit hall (photo courtesy STC)

Throughout the conference I saw people approaching Stephen, Michael, and Cheryl to congratulate them, which made them very happy. Me too!

Michael Opsteegh poses with his plaque
The recipients were delighted to show off their accomplishment at every opportunity during the Summit (photo courtesy STC)
Stuffed bear with "I'm certifiable!" pin
In large and small ways, we generated certification buzz

We were collectively sucessful at generating buzz about certification, in both large and small ways. Believe me, I noticed! Here’s a small example. Meanwhile, Debra Zhang, a Boston University graduate student and energetic marketing intern, was  steadily tweeting about certification-related events. A monitor outside the exhibit hall  ran TweetDeck during the conference, and it seemed that every time I walked by she had just posted something. (Two of her tweets, the ones with the CPTC™ logo,  appear in the upper right of the display below.) Even better, other people were tweeting us up as well.

Certification traffic on TweetDeck
Our crack marketing team kept up a steady flow of tweets

 

Not apropos of certification, but a personal highlight, was participating in the return, after a four-year hiatus, of the Music Jam on Monday night, which gave me another chance to perform with the Rough Drafts (founders Tommy Barker and Rich Maggiani, new member Viqui Dill, and guest Robert Hershenow). How seriously do I take my music? At lunch on Monday I went over the lyrics of “I Saw Her Standing There” to make sure I didn’t forget anything (as if…!). It was the same stage I’d been on, um, the night before, but for me it was just as much fun the second time!

The return of the Open Jam
Singing at the Music Jam with the Rough Drafts (shown: Tommy Barker and Viqui Dill) (photo courtesy STC)

I wasn’t done yet. The Certification Commission had three presentation slots during the conference: a ten-minute mini-session at STC Central in the exhibit hall; my Tuesday presentation (“What is Certification?“); and Vice-Chair Rob Hanna’s thorough presentation (“How Do I Get Certified?“) on Wednesday. We had also prepared a brief video, produced by Jared Rushanan, that condensed my presentation and ran at STC Central during the conference. I thought all our live presentations went very well, and am encouraged that the versions posted to SlideShare.net have since received more than 1,500 views between them!

At the pre-Banquet reception
Nearly off the clock…! With some Boston friends at the reception before the Honors Banquet (L to R): Helen Stavely, Steve, Ellen Lidington, Rick Lippincott (New England Chapter president), and Taryn Light

At the Honors Banquet on Tuesday night, I met Andrew Malcolm, a former STC secretary and past head of the STC Certification Task Force from 1982 to 1986. Andy was one of the many who kept the certification flame alive, and he was gracious in congratulating us on reaching the end of a road that he had moved us so far along.

Andrew Malcolm
Speaking with Andy Malcolm, head of the STC Certification Task Force in the 1980s (photo courtesy STC)

Finally, this is how well things went: during the banquet W. C. Weise introduced me to Judith Hale, president of the International Society for Performance Improvement (ISPI). She congratulated us on our certification program, and as we were chatting I remembered where I’d heard her name:

Steve with Judith Hale, ISPI president
Speaking with Judith Hale, president of ISPI (photo courtesy STC)

 

“Didn’t you write a book on certification?” Yes, she said, she had.

“Wasn’t it titled Performance-Based Certification?” Why yes, it was.

“That’s the book we used to plan our certification program!”

I mean, how often do you think to say the exact right thing?