I'd Rather Be Writing » corporate http://idratherbewriting.com The Latest Trends in Technical Communication Fri, 25 May 2012 16:20:03 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 What I Learned About Tech Comm During 2011 http://idratherbewriting.com/2011/12/28/what-i-learned-during-2011/ http://idratherbewriting.com/2011/12/28/what-i-learned-during-2011/#comments Wed, 28 Dec 2011 15:31:48 +0000 Tom Johnson http://idratherbewriting.com/?p=10339 more »]]> What I Learned During 2011, and What I'll Do During 2012This past year I learned a few things. As I approach 2012, I’d like to note what 2011 taught me:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.)
  8. 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.
  9. 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.
  10. 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

]]> http://idratherbewriting.com/2011/12/28/what-i-learned-during-2011/feed/ 23 Three Solutions to the Corporate Blogging Paradox http://idratherbewriting.com/2011/09/02/three-solutions-to-the-corporate-blogging-paradox/ http://idratherbewriting.com/2011/09/02/three-solutions-to-the-corporate-blogging-paradox/#comments Fri, 02 Sep 2011 14:26:55 +0000 Tom Johnson http://idratherbewriting.com/?p=9753 more »]]> The corporate blogging paradox

The corporate blogging paradox

Corporate blogs suffer from an almost insurmountable paradox: you can write something interesting to readers, but it will make your company uncomfortable. You can write something that will make your company comfortable, but it won’t be interesting to readers.

The corporate blogger has a difficult decision to face. Do you want to gain an audience, build relationships with readers, and strike a cord of authenticity — while at the same time drawing heavy fire and criticism from your company? Or do you remain under the protection and guidance of the company (which pays your salary, remember) by writing safe content that supposedly furthers their goals but which connects poorly with your readers?

It’s not an easy decision to make. It appears that most corporate bloggers stick with the latter. And the results are telling. A recent Forrester poll found that only 16% of people actually trust corporate blogs. That means that more than 8 out of 10 people pretty much feel corporate blogs suck. If you can’t trust a blog, it’s hardly worth reading. And equally problematic, it’s hardly worth writing.

I usually tend to assume corporate bloggers are second-rate marketers who don’t understand the social media world or writing. But I’m a corporate blogger (I run LDSTech) who first started out as a personal blogger.  My I’d Rather Be Writing blog is supposed to be an innovative technical communication blog. Yet I can’t really ignite a corporate blog despite having time and energy (and billing code) to do it. Why? What is the secret sauce to corporate blogging that I haven’t figured out yet?

Sometimes I believe I’m trapped by the paradox I’ve described. I’m not writing the real stories. Unlike with my personal blog, I’m not following my own instincts for what would be interesting. This is because the juicy stuff doesn’t get approved; it doesn’t align with the business scope and plan and purpose. The articles die with the product managers who shy away from the hot topics.

Once as a teenager I had the opportunity to visit with Steve Benson, a cartoonist. He was also the son of Ezra Taft Benson. Steve said that as a cartoonist, his job was to “afflict the comfortable and comfort the afflicted.” This advice has always stuck with me. Applied to corporate blogging, it puts the blogger in a precarious position. Do you afflict the company and comfort the reader? I’m not sure how long such a writer lasts in that position before the company decides it has had enough, no matter how many hits the articles are getting.

Industry Expertise

The only corporate blog I honestly follow is Scriptorium, and I’m not sure it counts as a corporate blog. Scriptorium is an XML publishing consultancy. I think their blog’s business-case purpose might be to get readers to see them as a trusted, go-to source for XML needs. But I find that their blog looks outward much more than inward. They write as industry experts, commenting on trends, technologies, news, and other industry topics. I don’t think I’ve ever read a post that overtly advertises what Scriptorium actually does. In fact, sometimes I’m not even sure what they do (is it DITA, XML, content strategy? content management?) Still, I really like their blogging model — positioning themselves as general industry experts.

To be an industry expert, you have to keep a pulse on what’s going on. You have to immerse yourself in other blog posts and releases and trends. As an industry expert, not everything you write will tie back to your company’s specialization, products, or services. It will merely relate to your field as a whole. For example, Scriptorium’s latest post is on the Perversion of Indexes. The post touches on the difficult of creating indexes with XML editors and modular content. I don’t know what Scriptorium does with indexes in their consulting, or if they have any kind of indexing tools or practices. But the impression I get is that Scriptorium is up-to-speed with index trends. And I begin to trust their voice.

Would such an approach work with other corporate blogs? I’m not sure, but it might be a more fruitful approach than writing about topics that make the company uncomfortable. Commenting on tech in general, and analyzing its relevance to the audience, might be a good way to stay relevant without making everyone in the company avoid speaking with you. As long as the focus is outward, rather than inward, you can avoid the marketing speak and heavy promotional tone, as well the self-inflicted martyrdom that a true journalist would probably undergo.

Customer Focus

Another common strategy in corporate blogs is to focus on the customer. Spotlight how your customers are using your products, their tips, tricks, questions, experiences, etc. This focus can shift the attention from the company to the customer, giving the impression that as a company you care about your users.

The problem with this focus is that spotlighting users no doubt involves a filtered selection of happy users, and ignores the angry customers or the ones who are sallying against your company with ugly shouts. And will you really address their true pain points and struggles? Or their road map demands? Essentially this focus can come across not too unlike a list of testimonials that companies sometimes display — a carefully selected list of people who have only the best praise for you. Other readers know this, so the appeal of the content remains low.

How-to Information

A third approach around the corporate blogging paradox is to avoid journalistic topics altogether and instead focus on help information, in the form of how-to’s, best practices, tutorials, and other instructional material. This approach may make the most sense: if you can’t write the real stories, why write any stories at all? Writing lukewarm stories that aren’t appealing to anyone is hardly any way to embrace the life of a writer. If you have this kind of all-or-nothing writer personality, you’ll probably find more space to breathe in the safe arms of help material.

Help material is almost never offensive. The biggest offense is explaining a bug, or admitting a quirk that isn’t yet fixed. Additionally, help material is universally welcomed into the world of useful information. Its content value is immediate and undeniable. Is it interesting? Maybe not. But it’s sure to keep you far from the edge of corporate danger, while at the same time not forcing you to sacrifice your journalistic ideals to tell the real story. That’s probably why being a technical writer is a good career for me. Because I’m too stubborn and bent on controversy to fit into the corporate blogging mode with any kind of comfortable fit. At least as a technical writer, I can avoid stirring up controversy and work on something productive. I can save my controversy digging for the off hours, on my own blog. Meanwhile, the challenge of solving technical problems, coming up with solutions, and figuring out the unknown can keep my attention and provide some level of creative fulfillment.

Blog Sponsors

]]> http://idratherbewriting.com/2011/09/02/three-solutions-to-the-corporate-blogging-paradox/feed/ 13 Implementing a Department Wiki? A Writer Shares Some Dos and Don’ts (Guest Post) http://idratherbewriting.com/2009/06/30/implementing-a-department-wiki-a-writer-shares-some-dos-and-donts-guest-post/ http://idratherbewriting.com/2009/06/30/implementing-a-department-wiki-a-writer-shares-some-dos-and-donts-guest-post/#comments Tue, 30 Jun 2009 13:33:10 +0000 Tom Johnson http://www.idratherbewriting.com/?p=3949 more »]]> This is a guest post by Cathy Wildhaber about her experience implementing a wiki in her department. Cathy is a technical writer in Kansas City. For the past 4 years, she has worked for a company that provides computer systems and services to financial organizations.

Ever take a look at some slick wiki technology and think “Wow, that’s really cool…I want one”? I did, and the results (an internal wiki for the documentation department where I work) were…less than stellar. Here’s how you can avoid my mistakes.

I had been working on a continuing education SharePoint site for the department. There was a wiki webpart available in SharePoint, and I became intrigued. What better way to help department members increase their knowledge about the profession than by harnessing our collective brainpower and talents! We could create collaborative summaries of training we’d attended! The intern could create a “new hire” section! We could have a knowledge base! How cool!

Wiki Dos (and Don’ts)

I immediately set up the webpart, learned how to create and edit pages, and provided a training session for my coworkers. I gushed about the endless possibilities, and then sat back and waited for the quality content to roll in. It didn’t.

Where had I gone wrong? Through the power of hindsight—and the research I should have done before I launched the wiki—I’ve come up with a few guidelines to follow next time. Perhaps you’ll find them helpful, as well.

Start with a clear purpose (a.k.a. Avoid the “if you build it, they will come” fallacy)

If you get starry-eyed over a wiki and then try to come up with ways you could use it, adoption is likely to be weak, as was the case in our department. If, however, you have a genuine process inefficiency or lack of resource that a wiki could help solve, you have a much better chance of success.

This phenomenon is best described by Mark Shead. He defines two types of technology users. Members of the first group identify a problem and then seek a technology to resolve it. Members of the second group, on the other hand, start with a cool new technology and then look for a way to incorporate it into their lives. When members of the first group adopt a technology, they are more likely to stick to it. Members of the second group often abandon the technology after a short time.

Prove how the wiki can benefit users

To embrace a wiki, users must first see how it will benefit them. Provide examples of how their real-world work could be moved to a wiki, and show how it could result in more efficient processes.

Ease existing fears about the wiki

People unfamiliar with wikis may fear that a platform in which any person can edit or delete any page will be chaotic. They may feel concern that a wiki could easily devolve into a free-for-all.

In a company wiki, the accountability for contributions and edits is much higher than in a major public wiki like Wikipedia—no one could leave anonymous spam. And while a small company wiki would likely not have the system of checks that Wikipedia employs, most small wiki communities tend to be naturally self-regulating. Chaotic editing and questions of ownership tend to be non-issues.

Provide proper training

If members don’t understand the broad concept of a wiki or the specifics of creating pages and setting up links, they won’t use it. Be sure to train users on what a wiki is (its purpose and what it’s good for) as well as on the wiki tool itself (how to create pages and set up links).

Don’t make it a chore

Don’t force the wiki upon department members. A lack of posts or edits by a particular member does not necessarily mean that the member is not finding value in the wiki.

Nurture your wiki

A wiki needs care and attention. Having an official “administrator” could imply that content is being policed, but you should ensure that someone performs a few maintenance functions:

  • Introduction of a loose organization or structure (perhaps in the form of a home page that links to broad categories).
  • Periodic checks to ensure that all pages can be found easily through links to a main page.
  • Periodic checks to weed out any spam or mean-spirited contributions.
  • Acknowledgement of good ideas, sorting of feedback, and implementation of suggestions.

Use metadata

To keep your wiki well-organized and usable, incorporate metadata. Metadata allows users to sort by category to quickly find what they’re looking for. Many wiki programs allow you to require that metadata be selected and allow you to define your own metadata. Other possibilities for metadata include content stages (can indicate whether the page is new, developing, or complete) or audience tags (can indicate whether the page is primarily for management, administration, or developers).

Broadcast updates

A system that notifies members when information has been added or changed will remind users that the wiki exists, and it will help ensure that the content is current, correct, and relevant. Notifications could come in the form of an RSS feed, or they can be as simple as an email alert. Users may prefer to receive a daily or weekly digest of changes, rather than notifications about every single change.

Encourage participation

A good way to encourage participation in the wiki is to enlist the help of a select few. You may select the most well-respected and established veterans of the department, or the enthusiastic early adopters of each new gadget, or the department members most willing to share their opinions. Often these individuals can pave the way for the rest. Recruit them to help get the wiki started; the rest of the group may well be more willing to participate after ground has been broken.

Blog Sponsors

]]> http://idratherbewriting.com/2009/06/30/implementing-a-department-wiki-a-writer-shares-some-dos-and-donts-guest-post/feed/ 8 Company blogging 101 http://idratherbewriting.com/2009/01/13/company-blogging-101/ http://idratherbewriting.com/2009/01/13/company-blogging-101/#comments Tue, 13 Jan 2009 14:11:40 +0000 Tom Johnson http://writerriver.com/?p=661 Company blogging 101

Blog Sponsors

]]> http://idratherbewriting.com/2009/01/13/company-blogging-101/feed/ 1