Monday, September 5, 2011

Seeing my work through others' eyes

A few days ago, I got to the office and popped in for a look at BlobCo's intranet - meaning it was a pretty typical morning. At least it was until I spotted a post by our trainer.

The trainer's post was a compare-and-contrast piece explaining the difference between training and documentation. Having been unaware that there was any confusion on this point, I was interested enough to read it. Sometimes I find out that my assumptions (such as "everyone knows the difference between training and documentation") are completely mistaken, and I was willing to believe that I had reached one of those moments.

Except that wasn't what was going on.

The post mentioned training briefly, then focused on what documentation is: It's reference material, it's purely descriptive, it's not something you read all at once.

I fully agree with that last one. But the first two aren't an accurate depiction of the work that I've focused on at BlobCo: Task-based help. It's not about describing the menu items and buttons. It's about getting people from being stuck to getting our product to do what they want it to. It's also about jogging people's memories when they've forgotten what they learned in the training sessions.

I took away a handful of insights from this:
  • Lots of people still don't know what I really do.
  • Lots of people think they know what's in the documentation before they even look, so they don't bother to look.
  • Even if you're positive that you know a thing, it's always worth researching it before you write about it...because you might still be wrong.
  • It's really easy to irritate people by mischaracterizing their work.
  • Getting irritated means you're paying attention to the wrong things.
  • Having your work mischaracterized is a gift: it's your signal that you need to get better at your 30-second explanation of what you do and how it contributes to your organization's overall goals.
OK, that feels better. I got some constructive ideas out of this, and I came out of it with my sunny side up.


  1. I always describe the difference thusly:

    Training gets people up to speed ASAP.
    Documentation supports them when they are using the product.

  2. I like what Gordon says. Basically I look at it this way: documentation closes the gap between what can be covered in training and what you need to know to actually accomplish something.