Things I learned at STC12 on Sunday

Even though I only arrived at the STC Summit 2012 on Sunday afternoon, I learned a lot already, despite missing the pre-conference workshops and certificate courses.

Planning good, worrying bad

My worries about congestion and heightened security due the NATO summit in Chicago were unfounded. Immigration and everything else at O’Hare were as smooth and easy as I’ve ever seen it.

STC Chicago rocks

Separate from the conference registration, there’s a hospitality desk which I believe is run by the Chicago chapter of STC.

Hospitality Desk at STC Summit

They are courteous and competent and point you in the right direction, whether you’re looking for food outside the hotel, directions, transportation options and sights to see.

Use twitter, before and during

Whether I’m attending a rock concert or a conference, I like myself a pre-show buzz where the excitement builds before the event. Following the twitter #STC12 hashtag, I’ve found updates, a pre-show buzz – and lots of faces to meet as I roam the halls! (Many attendees add their twitter handle to their conference badge which also helps to put faces to the names.)

It’s all about community

The opening general session outlined where the STC and the industry at large is at. I’ll just mention one detail that impressed me: The immense work and care of the conference committee who put together a program that ensures that we all get the most out of STC 12. Conference chair Paul Mueller and Program Chair Alyssa Fox did a great job – and still have the time and energy to make newbie speakers like myself feel right at home.

Creativity works sideways

Scott Berkun’s opening keynote was not specifically geared to tech comm, but his session about the myths of innovation was entertaining and engaging.

Scott Berkun looking at tech comm's bright future... :-)

A common theme for me was how creativity thrives when you look for solutions sideways, instead of staring a problem straight in the face:

  • Most ideas don’t come from spontaneous flashes of insights, but from other ideas, whether they’re smaller ideas combining into a bigger whole or an existing idea that you apply in a new domain.
  • Most of your ideas won’t succeed because they’re innately brilliant. Look sideways to informercials how you can pitch your idea: Start with customers and their problem for context, then show how your idea solves the problem.
  • Many teams who get stuck while implementing an idea won’t benefit from more resources or rules, just like a truck stuck in a rut won’t get out with more people in it and better maps. Instead, make the team smaller, give it more authority, and choose people who thrive in uncertainty.

Don’t forget to party

I had a grand time at an afterhours party. I made friends among seasoned tech writers (Hi, John!) and budding ones (Hi, Elizabeth!). The one mistake of Day 1 was a Sam Adams “Cherry Wheat”. It’s a mystery to me how this can be called beer. 🙂

Advertisements

How efficient is your documentation?

To gauge the efficiency of your documentation, consider the time spent to create it plus the time it takes to use it.

That’s the lesson I learned from applying Scott Berkun’s make vs. consume ratio to documentation. Scott’s idea is generally that it takes time A to create a tweet or a poem, a book or a movie, and time B to read or watch it. Scott relates the two measures and points out how you can easily consume in a few hours what authors and publishers, actors and movie people have spent months fabricating.

“make + consume” in documentation

When it comes to documentation, I think you can add both measures to gauge efficiency of documentation – though not its coverage or quality!

But just for time, I try to keep in mind these tactics:

  • Minimize the total time required for you to create your documentation and for customers to find, use and apply it.
  • Consider spending more time to make your documentation faster and easier to use, especially if you find that customers have trouble with it.
  • Consider spending less time with documentation tasks that do not help your customers in using the described product.

Of course, time isn’t the only yardstick. Accuracy, completeness, legal and contractual obligations are just some of the other factors.

Still, I’ve found “make+consume time” a useful benchmark to stay focused on what ultimately benefits the user and what doesn’t.

Further reading

If you’re concerned about documentation efficiency, you might also find earlier posts of interest:

Your turn

How do you gauge the efficiency of your documentation process and output? Can you credit your efforts towards making your documentation faster and easier to use? Please leave a comment.

How important is your manager?

… pick your manager first. A great manager will negate most other work problems, whereas an awful manager will negate most other work pleasures.

I found this in a post on Scott Berkun’s blog, and it is oh so true! It’s the single most important factor in my satisfaction with a job. Nothing else shapes my memory and my judgment of a past job as much.

A couple of caveats apply to tech writers:

  • Unless you’re working in a dedicated documentation department, even a good manager may still need to learn a thing or two about good documentation. You can spot a good manager if he’s willing to listen, but still keeps you on your toes.
  • I guess few tech writers actually get to pick their manager. Yet all else being equal, go for the better manager, when choosing between two departments – or, hey, two job offers…

What do you think? How important is your manager to your satisfaction and sense of progress in a job?