I'd Rather Be Writing » goals

Technical Communication Metrics: What Should You Track?

Tom Johnson — Fri, 02 Mar 2012 15:00:41 +0000

In 2004, when I returned from a teaching stint in Egypt and began working as a copywriter for a health company in Clearwater, Florida, my manager insisted that I track something related to my writing. We decided that I would track word count, because this was the easiest thing to track.

Each week, I graphed the number of words I published, and during a weekly meeting, I held up my graph. If the number decreased for the week, I formatted the arrow red. If it increased, I formatted the arrow black.

My graphs regularly alternated between black and red arrows, and I found the whole exercise somewhat amusing and ridiculous. But I went along with it, because everyone was tracking something. We all had to create these little charts that we held up in weekly status report meetings.

Despite my cavalier attitude toward this word count tracking, I can tell you that I wrote more words than my manager could process by far. After working there several months, I had built up such a mountain of content — press releases, radio pitches, product descriptions, newsletter articles, pamphlets, e-mail campaigns — that my output was undeniable in size. I do think that holding up the silly little graphs each week had some impact on my determination to write.

Lately I have been trying to figure out the right metrics for my role as a technical writer. A lot has been written about metrics and technical communication. Many technical writers have struggled to define meaningful metrics, either because of a requirement imposed by managers or otherwise. One of the most common goals with metrics is to connect writing activities to financial figures, since this allows technical writers to establish value in a quantitative way that speaks to senior leaders.

A few possible metrics

Despite the need for these metrics, coming up with a sound way to measure the value of technical writing is a problem that remains elusive as ever. The following are several possible ways to measure the value of technical writing:

Support costs. No group has more metrics associated with it than help desks. They meticulously track the number of calls coming in, the product the call is about, and the estimated cost of each call. If a software application receives 3,000 calls a month, and each support call costs $25, the software costs the company about $75,000 a month in support costs.

How documentation affects support costs can be tricky to estimate because a lot of factors come into play:

Support calls spike when a product is initially released.
Support calls drop over time as users become more familiar with the application.
Not all support calls are resolvable through help material.
It’s hard to determine the influence of help material without a similar application that has no help material.

Helpfulness ratings. Another technique might be to embed a “Was this topic helpful?” question in your documentation. Then count the number of people who indicated that the topics helped them. You could measure your own success based on the number of yes responses versus no responses. If you equated each “yes” response with the cost of a support call, you could make a case that documentation is saving the company that amount in support costs.

For example, if 100 people indicated that topics were helpful, and half of those people might have called the support center without the help ($25 a call), that means documentation contributed about $2,500.

Unfortunately, people are always more willing to engage in feedback when it’s negative rather than positive. We love to complain more than praise, so I’m not sure how accurate this method would be.

Page hits. Page hits to help material aren’t a direct indicator of success, but what if you’re publishing web articles that double as marketing collateral? If you take the tips and how-to’s from the help, you can publish these on your corporate blog. Hits to these articles can be quantified and converted into a financial figure.

For example, let’s say you publish an article that receives 10,000 hits. Google might charge 25 cents a hit in a pay-per-click campaign to generate an equal number of hits, so the financial worth of that article you published is at least $2,500, plus the effort to write the article. If you publish 50 articles like this a year, you’re contributing a value of about $125,000.

Word count. You can also estimate the value of your contribution by measuring your word output, and then multiply this output by a cost number. For example, let’s say that in one week, you write 5,000 words. In the freelance world, a writer might charge about $75 to write 200 words. Therefore you can estimate the value of your contributions at about $1,875 dollars for the week. Of course, this method assumes that research, SME interviews, explorations of the system, and other non-writing activities are all quantified in that initial word output.

Most of these measures connect with a financial value, but if establishing financial value isn’t important, you could still measure a great many things related to your role.

What you track, you focus on

One of the problems with metrics is that we technical writers are so detail-oriented, we often get discouraged by the inability to track our contribution to the bottom line with a fair degree of accuracy. Consequently, we often don’t track anything at all — while still remaining passionate that our contributions make a significant impact.

If we dismiss metrics because they are slippery and inaccurate, we are selling ourselves short. Here’s the secret about metrics: what you track, you soon care deeply about. At work I started tracking the number of words I publish every week. As a result, I’ve noticed that I have become more focused on my output. During the day, if I haven’t published anything, I start to feel lazy and unproductive. I have to get something out there, something written and published. I also don’t let half-written things languish. I see them through to publication.

But here’s the problem in tracking word count. Most of the non-writing activities I do lose their value because I am no longer tracking those activities. This can be an important consideration when you consider that technical writers don’t actually write much of the time. I don’t know if this is a travesty of the meeting-filled corporate life, or just the nature of the job. But take a look at this graphic that Mike Landry sent me last week:

What technical writers actually do

As you can see, technical writers spend very little time writing, maybe at most 10 percent of their day. Often the more senior level you are, the less you write. This graphic accurately describes my life as a technical writer. It’s easy to let my day fill up with non-writing activities, such as the following:

Attending scrum meetings
Meeting with developers to talk about how an application works
Discussing content that interns are writing
Figuring out if I should jailbreak my iPhone to record mobile app screencasts
Discussing IP omissions with released applications
Talking about social media strategies we don’t have (e.g., should we engage shallowly on multiple channels, or deeply on one?)
Working on team mission statement
Printing out latest Intercom magazine issue on information architecture
Figuring out how to add captions to linked images in Mediawiki
Reviewing the latest changes to the wiki
Gathering accomplishment highlights for previous month
Reviewing forum posts from volunteer testers for applications in beta
Editing existing help to include gotcha notes and known limitations clauses
Strategizing about upcoming projects and wondering how to get funding
Responding to various e-mail messages to clear out inbox

And before you know it, it’s 5:30 pm and the day is over without having written or produced anything substantial. However, if you have a metric you’re tracking, you suddenly become accountable. All those non-writing activities lose their value. If your goal is to publish 1,000 words a day, everything else you do is no longer the first priority. That’s what’s interesting about metrics: what you choose to track changes how you prioritize the activity. Therefore, you must think carefully about what you want to track.

The question, then, is not only what can you track, but what should you track. I am convinced that everyone should track something. Tracking can help you dramatically improve your performance in what you track. This year, in reaching to find some meaningful metric, I am currently tracking anything I can easily measure. Since I play both technical writing and marketing roles at work, I have more things available to track: words published, overall site traffic, individual article traffic, articles published, volunteer word count, RSS followers, Twitter followers, Facebook likes, Google + joins, the number of social media updates, the number of articles published, the dates for publication, and the number of volunteers who joined projects.

Of all these metrics, what is the most important to focus on? What is it that turns the wheel to make all of these numbers move forward? What is the driving force that accelerates social media growth, new visitors, and subscribers? Published content plays a huge role in driving these numbers — good quality content that aligns with our reader’s/user’s interests. The more I publish, the more each of these numbers goes up. So are words published the most important thing to track?

The consensus is against word count

Despite the grueling focus that tracking word count provides, the literature on the subject is decidedly against word count as a metric in tech comm. In fact, I have not read a single article or blog post that recommends tracking word count at all. Here’s a bit of research on the subject that I’ve culled from Intercom, Technical Communication Journal, LinkedIn, and elsewhere:

Research indicates that no industry standards are available for technical writer productivity rates. Some practices, such as page counts, have proven to be counter-productive in our experience. If a writer is evaluated by number of pages, page counts may tend to increase to the detriment of quality. In many projects, reducing page count should be the goal. Page counts also do not take into account the varying complexity levels of different deliverables; realistically, it takes longer to produce a page of highly technical material compared to user help. (“Measuring Productivity,” by Pam Swanwick and Juliet Leckenby. Intercom. September/October 2010. p. 9. URL: http://intercom.stc.org/2010/09/measuring-productivity/)

One group sees productivity metrics as dangerous. They once tracked pages per year per writer, but found the algorithm of little value. They believe that focusing their efforts on customer satisfaction is more important than counting departmental pages-per-week throughput. (“Documentation and Training Productivity Benchmarks,” by John P. “Jack” Barr and Stephanie Rosenbaum. Technical Communication Journal. Volume 50, No. 4, Nov 2003. P. 470)

The obvious, easily measured metrics are generally not very useful. For instance, there’s a temptation to measure technical writers by the gross output or superficial productivity—pages per day or topics per hour, respectively. These metrics are seductive because they are easy to calculate. But it’s an axiom of management that people will focus on whatever is measured. If you judge people by page count, they will produce lots and lots of pages. (Many of us succumbed to the “make the font bigger” approach in high school to fill out required pages for writing assignments.) If you measure writers by the number of topics they produce, you can expect to see lots and lots of tiny topics. Furthermore, this raw measurement of productivity doesn’t measure document quality. (“Managing Technical Communicators in an XML Environment,” by Sarah O’Keefe. Scriptorium.)

At Sabre Computer Reservation Company, for example, Blackwell (1995) shows how task analysis by a team of professional writers resulted in reduction of the number of pages in one manual from 100 to 20–and the consequent savings in production costs of nearly $19,000, more than paying for the effort that went into the task analysis. Note too the importance of measuring writing productivity in units other than pages per unit of time–had such a measure been used here, writer productivity would appear to have plunged. In fact, the rest of the article makes clear, the shorter manual was a great improvement on the original, and resulted in improved customer acceptance of the product. (“Measuring the Value added by Technical Documentation: A Review of Research and Practice.” by Jay Mead. Third Quarter 1998, Technical Communication Journal. p. 361-2.)

A question posted on Linkedin – What metrics do you use for technical writing? – had a number of responses that dismissed page count as a measure as well:

If writers are evaluated on the number of pages they produce, they’ll give you as many pages as they can churn out, not as many as the deliverable needs in order to be optimally useful to readers. Douglass H.

I would first agree that page count has no place in the discussion. There is frequently an inverse relationship between quantity and quality — at least when viewed in the context of two versions of the same document. Paul M. A.

Measuring “page-count” is ridiculous. Writers can churn out pages and pages of drivel and gobbledygook to generate “pagecount”. Editors can delete pages and pages of content to generate “pagecount”. A better measure is the readers’ view of the documentation. Do they like it? Can they use it to solve their problems? Dave G.

As you yourself (and several responders) have commented already, page count is a terrible way to measure productivity, especially as shorter often means better. For example, I spent several months *reducing* a user guide from 240 pages t0 80, removing the repetition and waffle… The only useful matrices for documentation are those that measure comprehension. Julian M.

Finally, perhaps nothing is as persuasive against tracking word count as this simple Dilbert cartoon.

Metrics need to measure quality

Besides the points raised earlier, measuring word count has other drawbacks. If you’re focusing only on word count, you’re not focusing on the problem. You may just be publishing more and more text, without analyzing whether the text is solving a business need or problem.

If you’re going to measure word count (quantity), you need to include some other important factors into your metrics. Jack Barr and Stephanie Rosenbaum define productivity with this equation:

(Quality X Quantity) / Time = Productivity.

(“Documentation and Training Productivity Benchmarks,” by John P. “Jack” Barr and Stephanie Rosenbaum. Volume 50, No. 4, Nov 2003. See p.471)

This is the problem with measuring only word count: without a measure of your word count against some sort of result, there’s no way to determine whether you’re being productive. You can only be productive if you make progress toward an intended result. Merely publishing more content isn’t necessarily a worthy goal in itself. The goal needs to tie to a larger objective, such as reducing support costs, increasing customer satisfaction, or improving user performance. These are all measures of quality.

To judge quality, some connection with users must be factored into a measurement; otherwise the quality measure is hollow. (Technical writers could measure the quality of each other’s work, but it’s better to have the actual user’s feedback.) The problem is that measuring the effect on users is hard to do, so we often skip it. Instead, we make a leap to believe that publishing content will affect users in a positive way.

The widespread omission of any kind of user testing with help content has been unfortunate. In our discipline, had we been conducting user tests with our help content all along, we would have probably abandoned many unproductive forms of documentation (for example, maybe the long manual) and sought other solutions earlier (such as multimedia instruction).

Saul Carliner notes that although testing for documentation usability is important for measuring quality, “the majority of those that did said that they test less than 10% of their products” (“What Do We Manage? A Survey of the Management Portfolios of Large Technical Communication Groups.” Technical Communication Journal, 51:1. Feb 2004. p. 52).

However you do it — testing content with users in usability labs, surveying satisfaction ratings among users, or embedding surveys into help topics — it’s important to measure quality through some kind of user interaction. Did our efforts reduce support calls? Were users pleased with the help material? Did it increase usage and adoption of the application? When you can introduce a quality measurement in the metric, it makes the tracking activity meaningful.

Can we still measure word count?

I wouldn’t dismiss measuring word count altogether. Instead, I would multiply word count by the weight of the deliverable. A quick reference guide might be multiplied by 10, and a video by 20 — or something similar. It wouldn’t be hard to draw up a list of deliverables and multiply them by an appropriate weight measure to render them into output units. I mentioned quick reference guides and videos, but I could equally include other activities, such as social media updates, branding of help platforms, or formulation of strategies.

There are plenty of metrics that incorporate complicated algorithms to define a unit of work. For example, Pam Swanwick and Juliet Leckenby use the following formula:

(# topics or pages) x (complexity of deliverable) x (% of change)

+ (% time spent on special projects)

x (job grade)

(“Measuring Technical Writer Productivity.” Feb 2011. Writing Assist, Inc. http://www.writingassist.com/newsroom/measuring-technical-writer-productivity/)

Converting any kind of output into a unit of work helps you avoid deprioritizing every non-writing task. (On the other hand, if you want to prioritize writing so that you don’t end up like the Mike Landry graphic shows — with writing occupying just a sliver of your day — then you might consider counting words alone. It all depends on what you want to prioritize.)

Since measuring quality is integral to a metrics analysis, I plan to embed surveys into help material to gather feedback from users. Our usability group uses Loop11 to conduct regular usability tests (such as this affinity diagramming study). If I could embed this Loop11 survey into a template on the wiki, and then insert the template into specific wiki help pages, this would help me assess the quality of the content. I could also bring in people off the street, so to speak, and ask them to evaluate the help material based on a list of questions, but my preference is for real users to assess the help in an actual scenarios.

Conclusion

In most articles, metrics are used by managers to evaluate employee performance. Or they’re used by tech comm departments to justify hiring and budgets. Few approach metrics as a way for individual contributors to establish a meaningful measure for their productivity and success. Yet for me, this is perhaps the main motivation I have for tracking metrics. I know that what I track, I can improve. And this improvement can take me to the next level.

I am interested to hear what metrics you track, and the results of the metrics in your company.

Blog Sponsors

STC Certification: An In-Depth Interview with Steve Jong

Tom Johnson — Fri, 27 Jan 2012 04:11:47 +0000

The following is a guest post by Steve Jong, chair of the STC Certification Commission.

What does the certification program involve?

First, for an introduction to the subject, I recommend the Wikipedia article at http://en.wikipedia.org/wiki/Professional_certification. Our Certified Professional Technical Communicator™ (CPTC) credential provides assurance to employers and the public that the certified practitioner possesses the knowledge, skill, and ability expected of a competent technical communicator to meet the demands of technical communication projects, today and tomorrow.

To become certified, a candidate must submit a packet of material covering five areas of practice: (1) user, task, and experience analysis; (2) information design; (3) process management; (4) information development; and (5) information production. The packet is given a double-blind assessment by a team of evaluators according to objective criteria. If the packet meets or exceeds the criteria, the applicant is certified.

Once achieved, certification is good for three years; to maintain it, certified practitioners must continue their professional development, through continued learning, attending programs and conferences, or other professional activity—the choice is theirs.

What led to the development of a certification program?

It’s been a long and winding road. The first recorded discussion of certification was an STC Annual Conference all the way back in 1964! STC formed an ad hoc certification group in 1975. Certification languished as a chicken-and-egg problem: members wanted proven value before embracing it, but without a program there was no proven value. Repeated member surveys showed majority support for the concept, though always with a vocal minority in opposition.

In 1985 the committee reached the point of presenting a proposal to the STC Board to undertake a one-time certification of members. Extrapolating from another poll, the plan would have exactly broken even. Given what they felt was a lack of consensus, the Board decided to postpone a decision for two years, which in the end turned into more than 20. During that time certification became much more common among other professions, with plenty of successful examples.

Five years ago, STC commissioned a study that told us we needed three things to be considered a profession: a code of ethics, a body of knowledge, and certification. Independently, we saw that certification is a key characteristic of thriving associations. We already had a code of ethics; we began the BOK work, and certification took on new urgency.

The incarnation of the certification task force that I chaired was able to define overarching areas of practice that are unique to our profession yet shared among our many subgroups. We also came to realize that the certification market was much more than STC members; that certification was not a one-time event but an ongoing operation; and that STC would benefit not just from application fees but also from recertification and training. From this three-dimensional perspective, the economics of certification made sense, and in April 2010 we wrote a proposal that the Board could accept.

Has anyone completed the certification program yet?

We are collecting packets right now. When we have enough we will calibrate the scoring system. We expect to announce the first group of certified technical communicators at the STC Summit in Chicago.

What are the goals of certification?

At the 2009 STC Summit, a group of STC thought leaders brainstormed a list of drivers, or reasons for certification. The STC Board subsequently accepted the list as fitting STC’s strategic goals. This is what the certification program is trying to achieve:

Legitimize the contributions of, and respect for, our profession
Establish uniform worldwide performance standards
Increase the employability and salary of certified practitioners
Satisfy employers’ expectations
Reduce hiring risk for employers
Generate non-dues revenue for the Society

What kind of resistance have you experienced in starting the certification program?

I’ve been presenting the program to audiences for several years now, and a few common themes have emerged. Some people question whether any meaningful assessment can encompass the diverse specialties within our profession. Some people cite a poor doctor, teacher, or plumber they once encountered as proof that all certifications are meaningless. Some people think there’s no need for them to get certified because they personally either have a strong portfolio (when job-hunting) or conduct interviews well (when hiring). Some people say they cannot show their work because everything they do is internal, proprietary, or secret. And some people think the program is just plain too expensive.

How do you respond to some of the objections people have made to certification?

Like other professions that offer certification, technical communication is a broad field. But we are not certifying expertise in subject matter, which employers may determine themselves, or specific tools, which vendors may certify. That narrows things down considerably. What we are assessing is competency in the unique skills we offer, and at that level technical communicators share a core set of knowledge, skills, and abilities regardless of job roles.

We can all think of someone who couldn’t do the job. Ours is not going to be a perfect system, and I’m sure that on occasion someone less than competent is going to slip past us. But that’s no reason to abandon certification. Despite individual examples of incompetents with credentials, no one in the real world seeks out an uncertified doctor, teacher, or plumber. In actuality, that’s the first thing we ask for!

Certification will not replace a strong portfolio or a skillful interviewer. But when we apply for a job, our résumé is only one of dozens skimmed by a recruiter or HR person. In the moment of consideration it gets, certification makes it stand out, which can give you the opportunity to show that portfolio. And at the other end of the process, when a hiring manager has to choose between equally qualified candidates, certification can be the tiebreaker. Our certification is an independent, objective, third-party assurance, and in time it will become a meaningful distinction.

Evaluators must sign blanket non-disclosure agreements, drawn up by our legal counsel, to protect applicant submissions. However, we set up the process so that you can become certified without ever showing a piece of real work. You can use older work, redacted samples, recreations, even simulations. Of course, it’s easiest to use samples drawn from your own portfolio, but you don’t have to.

Finally, certification is an individual decision, and there is no guarantee you that if you get certified your salary will increase or you’ll get a promotion. But in the professions we’ve studied, the average certified practitioner enjoys a salary premium that far exceeds the cost of certification. Compared to certification programs for comparable professions, the cost to obtain and maintain CPTC certification is midrange or slightly lower. So I dare say it’s a bargain!

Who is the target audience for certification?

The CPTC credential is available worldwide to experienced technical communicators who work in English and wish to demonstrate that they have the ability to meet the North American standards for practice. That’s a mouthful, so let me unpack it a bit. We require a combination of experience and education to qualify. While a bachelor’s degree is plenty, if you have five years of experience you really only need a high-school diploma or its global equivalent. (This is how PMI certification works as well, by the way.) With a specialized degree (such as technical communication), the experience requirement is reduced to as little as three years.

You don’t need to be an STC member to get certified, and you won’t need to get certified to be an STC member. Our evaluators work in English; in future we hope to expand to other languages. The mix of knowledge, skills, and abilities we’re looking for were qualified for the North American market, though we’re working to qualify the mix outside North America.

Is the BoK comprehensive enough to be the foundation for a certification program?

Yes and no. To quote its charter, the Body of Knowledge is “attempting to organize, make accessible, and connect together the plethora of information necessary to train for and practice within the profession.” That certainly fills the bill! But the BOK will take time to flesh out. And the BOK team is cataloging material as it arrives, not concentrating on the subset of information we’re certifying. For now we are evaluating submission packets prepared by candidates, which better fits the portfolio model familiar to practitioners. When the BOK is ready we will switch to exam questions drawn from it. So if you’re nervous about taking tests, I suggest you get certified now.

How much does certification cost?

For charter applicants (until 14 February 2012), the application fee is $99, the assessment fee is $495, and the yearly maintenance fee is $49. Additionally, if you return your submission packet by 14 February 2012, we will rebate $100 of the evaluation fee. After that, prices will increase, more so for non STC members. So if cost is a concern, or you’re not an STC member, consider applying now.

What would be the advantage for established professionals to go through certification?

As I mentioned before, certification is a tiebreaker both for setting an interview and for getting an offer. I’m not blowing smoke here: this is what we’ve heard from HR professionals and hiring managers. In uncertain times, certification program applications go up. That’s because people look for every edge they can get.

For a gray-haired veteran, certification won’t make as much difference as it will for a mid-career professionals. But as the Wikipedia article puts it, professional certification stands above your résumé (which is you writing subjectively about yourself) or a reference (which is someone speaking to your role in one place) as an independent, objective, third-party assurance of your competence.

There’s something else to consider. Take my personal example: I was named an STC Associate Fellow this year, and—how shall I put it?—I’m most of the way through my working life. I am not in the target demographic for certification. But I am at the point where I think in terms what is good not just for me but for STC, the profession, and my colleagues. Certification will transform the Society, the profession, and the careers of people working today. To me, anything I can do to help accelerate the growth of the program is worthwhile.

Is there a way to participate as a trainer in any of the certification courses?

Yes! In other professions, the typical certification applicant spends more for training than for the certification process itself. By starting CPTC certification we are establishing a market for certification courses. STC plans to participate in that market, but it won’t be exclusive. Anyone can offer training in the areas of practice.

Steve Jong is a life-long technical communicator, an Associate Fellow of the Society for Technical Communication, a former STC Director at Large, and a former president of the STC Boston Chapter. He is the chairman of the STC Certification Commission, which has been established to oversee the STC certification program. You can read more about certification here. You can follow Steve Jong’s blog here.

Blog Sponsors

What I Learned About Tech Comm During 2011

Tom Johnson — Wed, 28 Dec 2011 15:31:48 +0000

This past year I learned a few things. As I approach 2012, I’d like to note what 2011 taught me:

Writing documentation in a wiki suits me for the same reasons I enjoy interacting on the web. The web is interactive, alive, dynamic, collaborative, fresh, and unlimited in potential. A wiki, being online, allows me to partake in the same game-like, community-rich environment that I thrive in.
It’s much better to focus on just a few key projects rather than spread myself too thin. I made the mistake of extending my reach into too many projects this year, sometimes taking them upon myself because the applications needed help. As a result, I wasn’t as informed as I usually am about the most important projects, and it showed. Later I pulled back and ignored everything but my two main projects, and I felt much better with this strategy.
I need to set goals to write at work. It’s astonishing how non-writing tasks can eat up the day. Lately I’ve set a goal to write for 4 hours a day at work. I rarely achieve this, though really this goal has caused me to reflect on what writing actually is. If I’m reviewing forum threads to detect issues to write about, or experimenting with a test system to determine steps for documenting a task, isn’t that writing? The typing part comes at the end and is fairly minimal. Regardless, just setting a timer on my iPhone prompts me to dig into the documentation topics and produce something tangible.
Content marketing, played out in the form of corporate blogging, is kind of boring. Corporate blogging isn’t what I thought it would be. Mostly the corporate scenario is stifled by lack of creativity and freedom to explore. You’re expected to toe the line, to avoid controversy, to vet each post through five levels of approval. Comments from readers are usually brief, unenlightening, and often don’t match the topic of the post. I find technical writing more engaging.
A centralized help authoring system is a neat idea, but I hate the lack of control. The idea with a centralized help authoring system is that you install the system on a server with all your styles defined in one central location; an administrator sets up everything to be a push-button publishing solution, and then everyone else just “focuses on content.” However, when you’re used to designing your own help solution, learning to rely on one (often remote) person is discomforting. I like having some control over the design, layout, style, and publication of my help material.
Community collaboration is extremely tough to pull off. I can’t just assign a volunteer writer a topic and let them run with it. I usually have to either gather the information from a subject matter expert or connect the volunteer with a subject matter expert — and then see them through the process with more hand-holding than I want to provide. Still, community volunteers can generate momentum by the sheer number of assignments I have to follow through with. Overall, I have no idea how to engage community volunteers in an effective way, but I think I can eventually figure a strategy out.
Sitting embedded with my project team is more effective than sitting with other technical writers. Sitting with my technical writing team, I end up collaborating a lot on standards, goals, styles, and other issues — which can be useful and important. However, the core substance a technical writer relies on is project-related information. No matter how many IRC meetings, scrums, iteration reviews, and other interactions, nothing replaces the information and rapport you get through proximity to the project team. However, proximity to the project team is just one element. Proximity to end-users is even more important. (See my post on The Proximity Problem for more analysis.)
Just because my job involves sitting at a desk all day with little movement, it doesn’t mean I’m fated to become a couch potato. By counting calories and following a whole-foods, mostly plant/fruit/grain diet, I can actually lose weight while improving my overall health. I’m not becoming a vegan or anything, but I had no idea how poor my eating habits were. The My Fitness Pal iPhone app gave me a wakeup call. The Forks Over Knives documentary on Netflix also made me question the integrity of the traditional food pyramid.
I’m not that interested in fiction. In the fall, I went through a fiction phase that lasted a good three months. During that time, I read and wrote more fiction than I have for the past 10 years. I eventually lost interest and realized I was more attracted to non-fiction for reasons I can’t entirely explain. I like the immersion in ideas (not that fiction is idea-less, but the ideas are shown rather than explained). I enjoy the sense of being “on top of the game” when I’m immersed in non-fiction (such as findability topics) and blogging about these same ideas. It infuses me with a lot of enthusiasm for my job, this blog, and my overall career.
Metadata is the most compelling strategy for findability, but I don’t know how to harness it yet. I experimented with the Semantic Mediawiki extension in a help system, and I liked the ability to tag and query topics in new ways, but I didn’t explore this strategy enough to be successful with it. I feel that I’ve only scratched the surface. There is so much more to discover. David Weinberger’s book Everything Is Miscellaneous, which explores metadata in depth, was the best book I read in 2011.

Based on what I’ve learned, as I go into 2012, I plan to do the following:

Use Mediawiki more.
Set goals to write more at work.
Focus on fewer projects.
Possibly hire an intern to help with the corporate blog.
Leverage community volunteers for non-writing tasks.
Eat smarter.
Read more non-fiction books.
Figure out metadata and findability.

Note: I do change my mind frequently, so no doubt this list will evolve as the months in 2012 pass by.

Blog Sponsors

Technical Writing – Making Resolutions for the New Year

Tom Johnson — Mon, 27 Dec 2010 06:35:05 +0000

As 2011 approaches, Lynda at WritingAssist.com encourages technical writers to make technical writing resolutions for the new year:

A new year means you get the chance to do things over, to do things better. Whether you’ve been happy with your technical writing team or you think things should improve, it’s time to look back on the past year to see what needs to improve and what needs to be removed from your company for the year ahead. (Technical Writing – Making Resolutions for the New Year)

A few of her recommendations were on the conservative side, in my opinion. Update your software, modernize your style guide. Nevertheless, this got me thinking about new directions I’ll take in 2011. I’ve been moving in some of these directions for a while. Here are the top 10 technical writing resolutions I have for 2011.

Use wikis rather than traditional HATS to author help content.
Give users quick reference guides rather than long printed guides.
Include more visuals, especially concept diagrams, in my help content.
Master Adobe Illustrator and increase my understanding of visual techniques.
Read more of my RSS feeds online and use them as a way to generate ideas for posts.
Start negotiating with project managers using an official user education plan rather than informal agreements.
Implement an official workflow of post-release documentation efforts based on user feedback, bugs, questions, and other unforeseen situations.
Solidify our team with standard approaches and processes as well as build unity through proximity.
Contribute to corporate blogging efforts for IT site.
Interact with community through forum, feedback, and other participation channels; stay abreast of needs and questions.

These aren’t so much resolutions as directions I’m heading.

Blog Sponsors

Lying in a Hammock, or, Having a Single Goal without a Purpose

Tom Johnson — Fri, 31 Jul 2009 14:24:11 +0000

Every week our team has a team meeting. In our manager’s office, we sit around a table and talk about our projects, our concerns, and whatever else we want to talk about. Recently, during one of my colleague’s turns, he talked about his goals. Apparently he’d made some goals about video tutorials, and I can’t remember exactly what they were, just that he was reporting on them, his progress, what he needed to do to achieve some of the substeps of his goals.

Listening to him made smile, because here he was, evaluating the progress on his goals in a detailed manner, as if talking about a project he knew intimately and worked on every day, whereas I couldn’t remember any of my goals, not one.

In every company I’ve worked for, goal setting has been an annual event, a couple of months before the annual merit increase. It’s an activity that I procrastinate, like most other employees do, until the afternoon it’s due, and then I come up with a list of reasonable sounding goals that fit into a nice grid, with a few milestones and steps, separated quarterly.

I endure the business speak about the goals being “SMART,” which people always emphasize with smugness, and then I save and send the document to my manager. And since I’m not required to do much with the goals until the next year, they soon evaporate into the air. Which is why I listened to my colleague in awe. How did he remember his goals? Has he been carefully tracking his progress toward achieving them? Has he already achieved some goals on his list? Why do I not have any idea what my goals are?

As I drove home after work, I thought about the goals I should have. I do have some general goals in my mind, but they are nothing extraordinary. Read more, exercise more, budget more prudently, help out around the house, and so on. But one goal I have keeps coming back to me with more importance than the others: write a page a day. It seems like such as simple goal, one that wouldn’t take much time. It doesn’t seem particularly important compared to the other goals on my list. But when I listen to myself, this is the only true goal I have.

I have no real purpose behind the goal. Sometimes I think by writing every day, I’m honing my writing skills for some future assignment, the details of which I’ll learn later. At that point, everything will be clear: the late nights, the endless editing, the typing and typing and typing. Or perhaps I’m building up a brand and a readership base, so that I may be a key player in some future twist of events.

But really, writing may turn out to be only a maniacal obsession, one without purpose. The purpose of writing may only be … writing. In that case, the activity itself is the goal, which means I’m living in the moment, rather than postponing fulfillment for some distant achievement.

In most business contexts, the goals and purposes behind every activity, especially copywriting, are clear: you want your customers to take action, usually to buy your product or service. In fact, just this week I listened to a podcast by Jason Van Orden on this topic. In the Community Building Blueprint, Van Orden traces the steps for achieving action in reverse order. To get customers to act (which is your goal), you need influence. To have influence, you need trust. To earn trust, you need a relationship. To form a relationship, you need repeated engagements. (Jason defines engagements as “regular interactions that deepen the mental, emotional, and physical investment that the market has in your brand.” Please try to refrain from throwing up from the business speak.) Before you can engage, you need the customer’s permission. And before you get the permission, you need to get their attention.

I’m not sure why he stopped at attention, because I was really getting curious to see how far back he could trace it.

Putting that logic in sequentially forward order, Jason says that after engaging in meaningful social media, building relationships, and gaining trust, you can then leverage your influence to encourage your followers to use your service, buy your product, or hire you as a consultant.

You can listen to the videocast, watching Jason draw this upon a whiteboard like a university instructor here. I admit that although I poke fun of his business speak — the calls to action, branding, the “relationships and trust” — I can’t discount the accuracy of his model. It should no doubt describe my clearly formed plan to reach my goals, right, especially as it relates to my writing and this blog?

In thinking about action and influence, I pondered what I could possibly influence people about, or get them to act upon, and why, so that I could justify the time I spend writing posts and recording podcasts, but I came up blank. Although I write posts encouraging people to embrace online media over print, or to become link journalists on Writer River, or to check out podcasts, ultimately I don’t care if you “accept the call to act.”

To put it more bluntly, if my blog has influence, I have no agenda. There’s nothing I want you to buy. There’s nothing I want you to believe. There’s nothing I want you to do. I don’t care if you listen to me or reject me. If you subscribe, unsubscribe, or keep on clicking somewhere else, that’s okay. I’m not worried about “my brand.” Whatever course of action you take, I still go to work in the morning and come home in the evening. Certainly blogging might be leveraged for influence and action, but it’s not my goal.

My goal is simply to write a page a day. I’m not always good at it. I may not always publish the page. It may be total crap. But most of the time I do it. And I don’t try to look too far into the future for purpose.

The problem with goals is that, whatever the goal, it puts you into a future state of mind. You’re always working toward some end state of achievement that forces you to live in the future. When you’re always looking forward, you become blind to the present.

But many activities don’t need goals and purpose — such as riding a bike. I have a cruiser, which I bought for comfort. When I go on a ride, I’m not training for a future triathlon. I’m not trying to become healthier. I’m just riding the bike for the fun of it. I’m listening to my iPod. I’m weaving through the striped road divider. I’m looking at the river or grass beside me, occasionally stopping to explore new areas.

I have the same mindset playing basketball. I’m not playing to hopefully make a team somewhere. I’m not training to dunk the basketball. I’m just playing for the fun of it, because I like the feel of the ball in my hands, the sense of elation when I shoot a perfect three pointer, or drive past a defender to the basket. When the game is over, I go home, and I don’t remember the score.

And when it comes to my relationship with Jane, I also don’t have clearly defined goals, with a plan for influence, built upon trust, gained by repeated engagements, for which I first attempt to secure her attention. Anything that calculated is phony.

Learning to live in the present, I once read, is actually a major factor in happiness and life satisfaction. I think many of us have forgotten this. Our culture is too goal-driven. We force ourselves into postponed enjoyment of life. We trick ourselves into thinking that happiness comes only after we achieve our goals.

Although I do make goals (mostly to prevent laziness and degeneration), sometimes I just want to live in the present. To remove the long-term purpose and instead enjoy the moment. To enjoy doing something for purely personal enjoyment of doing that thing, without worrying about anything more.

When you live in the moment, completing the activity itself is the success. And because writing is so multifaceted in effect — the effect both on me and others — having an open purpose doesn’t limit the results. I’m not narrow-mindedly searching for a specific achievement to happen. Instead, I’m open to unconsidered possibilities, if any of those possibilities decide to unravel. And if not, I’m happy just to type and type and type.

It feels right to conclude with “Lying in a Hammock,” by James Wright. It is my favorite poem.

Over my head, I see the bronze butterfly
Asleep on the black trunk,
Blowing like a leaf in green shadow.
Down the ravine behind the empty house,
The cowbells follow one another
Into the distances of the afternoon.
To my right,
In a field of sunlight between two pines,
The droppings of last year’s horses
Blaze up into golden stones.
I lean back, as the evening darkens and comes on.
A chicken hawk floats over, looking for home.
I have wasted my life.

Blog Sponsors

Wrapping up 2008 – Successes, Failures, and Goals for the Next Year

Tom Johnson — Wed, 07 Jan 2009 03:42:03 +0000

As 2008 ended, I neglected to write a year-end wrap-up post because it seemed so trendy and cliché at the time, but now that 2009 has started, my muse has been prodding me to write it.

A lot of good things happened in 2008. We bought a house in Eagle Mountain, moving from an apartment to a two-story home that fits our little family of five perfectly. Jane started blogging more frequently, writing witty, engaging posts about so many things. Her readership shot up at least 300%. I started advertising in my sidebar, after much encouragement from Jane. I also began providing more WordPress consulting (in my spare time) rather than training, because it’s easier and more profitable.

I launched and redesigned writerriver.com, a community site that now has about 175 members. I also started a readscripturestogether.com site, which allows me to stay motivated spiritually. My proposals to the STC Summit about quick reference guides and product blogging were accepted, and I’m pushing further into these areas at work. On the basketball court, I once again found my shot.

As for our children, Sally (7) read nearly all of the Harry Potter books and has transformed into a bookworm, a perfect model of her mother. She’s quickly maturing into a young woman. Susan (4) continues to be the assertive middle child. We found out Spot (2) has Duane’s syndrome, which means one of her eyes doesn’t turn all the way to the left (but you hardly notice it). Spot exploded with speech this year, being more precocious with language than the previous two children.

Spot and me (her eye only looks a little cross-eyed when she looks left without turning her head, such as in this picture)

As for the year’s downsides, we ordered a subscription to DirectTV, and have all been spending far too much time watching the television. Jane and I had a few senseless arguments that I still regret. The snow in Utah turned out to be a lot less fun than the sandy beaches in Florida. We had to pay two months’ rent to break our apartment lease and move into our house. In our new location, I now carpool to work an unthinkably early hour in the morning, which often leaves me tired when I come home. We still struggle to find best friends in our new neighborhood. And we both fell prey to Twitter and the “release-high” that 140 characters shot across the Internet provides.

What’s next for 2009? Like most people, I have a few goals. Although my goals are essentially the same sort of goals that others make, I try to spin them with a unique angle to encourage surprising results.

Goal #1: Clean when Jane cleans. Being a good husband means sharing in household duties. By also cleaning when Jane is cleaning, I’ll ease the tension that arises when I remain stationary. Of course this is something I should have been doing all along, but alas, I am male. In co-cleaning, I’ll also gain more empathy for her hard work, and maybe stop leaving my socks lying around.

Goal #2: Post daily. Writing daily on my blog keeps my mind invigorated. It helps me stay engaged and improves my writing. It also makes me feel like I’m moving forward. I’ve found that posting daily (or, more realistically, posting multiple times a week) is easier than posting just once a week. The muse speaks loudest when I exercise it regularly. And so much good has come from my blog.

Goal #3: Run on my treadmill 3 times a week. We borrowed my sister-in-law’s treadmill and put it right near our TV in the living room. When I’m lying down on the couch, watching football, or Life, or some other show, it’s hard not to look over and feel a natural desire to run on the treadmill a bit. I doubt I’ll give up TV, and rather than feel as if I’m wasting my life watching some overly dramatic cop, doctor, or terrorist show, I can offset the guilt with the good feelings of exercise.

Goal #4: Comment daily on my readscripturestogether.com site. This is my spiritual goal. I’ve found that commenting on chapters posted on readscripturestogether.com site keeps me spiritually awake and enthusiastic in this arena. Who would have guessed that writing itself is the key to overcoming the spiritual yawn?

Goal #5: Dual-task and take hourly breaks to read a little from Safari. This goal is in the high experimentation phase. My goal is to increase my efficiency while also increasing my knowledge and awareness. I basically pick two main tasks I want to accomplish, and switch working on them every hour. As I switch, I take a quick break to read a few pages from a book in the Online Safari Library, which I have free access to. The library has a tremendously good selection of tech-related content. Because I keep switching between the two tasks, I maintain my attention level high. And when reading tech books becomes a treat, it makes the experience sweet.

That’s it. A modest set of goals, and not outside the traditional social-intellectual-spiritual-physical categories that underlie so many others’ goals. But hopefully I’ve given them a unique enough slant that some unexpected and beneficial consequences may result.

Blog Sponsors

The #1 Reason Why People Fail at Their Goals

Tom Johnson — Wed, 02 Jan 2008 03:49:49 +0000

In light of New Year’s day and goal-making (I used to be an obsessive goal-maker), here are two stories that relate to motivation and desire.

Story 1: Socrates

A young man visits Socrates in search of wisdom. To the young man’s surprise, Socrates takes him out to a lake and dunks his head under water. As the man’s struggle to come up for air, Socrates holds him under. Later, after recovering, the young man asks Socrates why he nearly drowned him.

Socrates replies, “What is it you most wanted when you were under water?”

“Air,” the young man replies.

Socrates responds, “When your desire for wisdom is as great as your desire to breathe, you will find wisdom.”

(Here’s another version of the story.)

Story 2: The Rat

In a bizarre scientific experiment, a researcher found that a rat preferred a sense of pleasure to food or water, even to the point of self-exhaustion. Adam Keiper provides more detail:

James Olds was a Harvard-trained American neurologist working in Canada when, in 1953, he discovered quite by accident that a rat seemed to enjoy receiving electric shocks in a particular spot in its brain, the septum. He began to investigate, and discovered that the rat “could be directed to almost any spot in the box at the will of the experimenter” just by sending a zap into its implant every time it took a step in the desired direction.

He then found that the rat would rather get shocked in its septum than eat—even when it was very hungry. Eventually, Olds put another rat with a similar implant in a Skinner box wherein the animal could stimulate itself by pushing a lever connected to the electrode in its head; it pressed the lever again and again until exhaustion. (The New Atlantis http://www.thenewatlantis.com/archive/11/keiper.htm)

(This story was mentioned in “History’s Strangest Science Experiments,” a Science Friday podcast. For a more detailed explanation of the experiment, see this article on the Brain Connection or this book from Amazon.)

Commentary

These stories contrast nicely. In the first example, the young man in search of wisdom lacks real motivation. His quest to find and interview Socrates may seem genuine, but his motivation is shallow. His desire is milk-warm. Socrates shows him that when his desire for something is intense enough, he’ll find way to obtain it.

In the second example, the rat has a strong motivation to push the lever. The rat’s motivation stems from the pleasure it gets from the activity, and it continues to perform the task nearly until death because of the pleasure it finds. Unfortunately, the task has no real value — it’s a worthless way to spend a rat’s time.

The problem with goal-making is that our desires and pleasures often contrast with each other. What we desire often has no pleasure connected with the activity, and what we find pleasing is often at odds with our desires.

For example, look at exercise. Almost everyone makes goals to exercise more at New Year’s. We may truly desire to exercise, but the activity lacks the pleasure that would see us through. Consequently, we do what is more pleasing — sit around watching movies. But deep down we don’t desire to watch so many movies; it’s just pleasing.

Another example is finances. Many people desire to spend less and save more, but there’s not much pleasure in frugality. Naturally, we do what’s more pleasing to us — make a bunch of unnecessary purchases at the mall. However, while pleasing, few people really desire to spend all their money on unnecessary things and rack up credit card bills.

To make good goals, you have to align your desires with pleasures — either by making the activity you truly desire fun, or by turning pleasurable activities into something you actually desire.

“The great new tool for writing a book today is a blog …”

Tom Johnson — Mon, 31 Dec 2007 03:46:49 +0000

In a recent episode on The Engaging Brand podcast, business coach Anna Farmery interviews Mark Sanborn, author of You don’t need a title to be a leader, on the topic of self-confidence. Farmery says many people have aspirations to write a book, but lack the self-confidence to do it. Sanborn says you can use a blog as a tool to build confidence and write a book. Sanborn explains,

Book writing is more about initiative and effort than confidence and creativity. …

Confidence is acquired in tiny doses… You ski a few feet on the kiddy hill after you get some good instruction …

The great new tool for writing a book today is a blog. I blog on a regular basis. …. Part of the reason I blog is to discipline myself to continually be thinking and writing. When I can do a 50 or 100 or 200 or 500 word blog and bang it out and realize that I can always go back and polish, improve, and change it later, no harm done, that’s a good example of skiing 3 feet without falling down on the kiddy hill….

Writing a good book that you’re proud of, that finds you standing on top of the mountain with the ability to make it all the way down, comes from doing all those little things, those tiny doses. Because if you don’t start small, I guarantee you 99 out of 100 people will never start. (17 min. mark, “The Art of self-confidence, show #130″)

In other words, writing a book may be too challenging of a goal in itself, but writing a blog post is easy. If you write scores of blog posts during the course of a year, you’ll build up the confidence to actually write a book.

If you compile your research into little blog posts, the blog can also function as a tool for writing the book. Although blog posts individually probably don’t cohere into a book, you’ll have all the research ready — the facts, quotes, and ideas — which you can then print out and arrange on little index cards (or whatever) so you can write the book. (It’s not as if you can just string together the blog posts into a book, unless you’re writing them as mini-essays that magically link together.)

I wrote about the topic of blogging and writing a book earlier with this post, Guy Kawasaki’s Impossible Burden: After Blog and E-mail, There’s No Time to Write the Book. For Kawasaki, the blog is a distraction to writing a book.

But the blog can be a tool you use any way you please. You can use it to write your book, post by post. You can use it to distract yourself from writing the book. You can use it to gather feedback from essays you post from the upcoming book. You can use it as a chapter-by-chapter fiction writing project. You can use it to compile your research. Or you can use it to write about everything and nothing. Blogging is essentially writing.

What I like most about Sanborn’s point is the approach to tackling large problems. At this time of year, everyone makes grandiose goals — lose 25 pounds, write a best selling novel, be elected governor — whatever. These goals might be more easily accomplished with little steps.

Personally, I want to write engaging non-fiction essays, and were it not for this blog, I would probably devote more time to them. My goal for the upcoming year, then, is to use this blog as a tool for creating the kind of non-fiction essays I want to write.