Challenges and accomplishments

Hello again, everyone! And also to people who started following my blog despite a complete lack of blogging. I appreciate the gesture of faith, and also the weight of guilt.

Last year I was buried under a mountain of work, family responsibilities, and the feeling that I’d said pretty much everything I had to say in 50-odd posts.

Continue reading “Challenges and accomplishments”

Advertisements

Where do your docs fall on the documentation spectrum?

I read an interesting article (which is itself a response to another article) that discusses how data analysis companies define themselves (or are defined) by the software-consulting spectrum. Basically, will the company be more focused on training users and sending them off to analyze their data, or will the company focus on a high-touch model where consultants do most of the work?

Continue reading “Where do your docs fall on the documentation spectrum?”

There’s no excuse for withholding information

I was recently approached by a company that recognizes that they have a knowledge management problem. They’ve just realized that there’s a lot of information held by individuals, and they need someone to solve the problem of insufficiently distributed information before it gets too big to handle.

This is great, and I love it when companies realize this (not least because it keeps me employed). But then I thought about times I’ve encountered people who zealously guard the information they’ve collected. This is bad. This is expensive. And there’s no excuse for it.

Continue reading “There’s no excuse for withholding information”

It’s not my job

I hate the phrase “it’s not my job.” It’s something I’ve heard in the darker corners of large companies, and it’s a big reason why I exchanged security for the chaos of smaller companies. That phrase is loaded with a lazy, irresponsible attitude and flags the shiftless lout uttering those words as a roadblock as clearly as any safety orange traffic barrier festooned with flashing lights.

It’s also a mantra that I’m trying to embrace.

Continue reading “It’s not my job”

Fulfillment and change

Empire State Building at nightAt the beginning of the year, I reviewed the goals that I set for last year. The results were hugely disappointing. I hadn’t fulfilled any of them to the degree that I’d hoped. I had started making progress on a few of them, but I was never able to make enough progress to consider any of them a success.

I was in a career situation that wouldn’t allow me to succeed in the way that I wanted to. I was frustrated and looking for a change, and found an interesting opportunity.

But not as a technical writer.

Continue reading “Fulfillment and change”

The case for Minimum Viable Documentation

I attended the TCCamp conference…er…unconference last weekend. Short review: I enjoyed it (again!). I attended Tom Johnson’s great intro to API documentation, I talked to some interesting people, and I got some practical advice during the three discussion sessions.

And I won an iPad Air 2 (thanks to XMetaL/JustSystems), which is FREAKIN’ AWESOME.

But I want to focus on one topic that came up during the “Technical Communication in Agile” discussion: the concept of Minimum Viable Documentation.

Continue reading “The case for Minimum Viable Documentation”

(Not my) predictions for 2015

It’s the time of year for technical communication industry predictions, but that’s not my speciality. I don’t have my finger on the pulse of techcomm; in fact, I’ve been feeling like I’m in an isolated backwater. When people learn that I’m using ZenDesk for documentation they think that I’m either very brave or very masochistic.

As Luke Skywalker would have told me, “Well, if there’s a bright center to the [technical communications] universe, you’re on the planet that it’s farthest from.”

[Speaking of, what sort of help system would you write for a lightsaber? “Point shiny end away from face and good luck”?]

Getting back on target…

Continue reading “(Not my) predictions for 2015”

Working well with others

A big part of a technical communicator’s job is research. The information we use to create content comes from a wide variety of sources: technical specs, product research documents, business proposals, white papers, internal wikis, customer support tickets…

And even from actual people. There’s lot of good info locked away in our coworkers’ heads. Getting to that info isn’t always easy, but I’m honestly surprised how often one question comes up both in interviews and in discussions with other tech writers: “How do you work with engineers?”

Continue reading “Working well with others”