The diversification, not death, of technical writing

It’s been a month of organizational changes at work. Actually, just a particularly chaotic month, after about 5-6 months of changes. Which is stressful in general, and I’m finding it also saps my will to blog, and leaves me with few new things to blog about. The “document the product” part of my job has taken a distant third place to customer support and establishing a training program.

It also means that I have to make decisions about what I want to do. And, again, stop being a damn hero and trying to do everything every day. I want to be a “working manager”: Leading a team, but also doing a bit of day-to-day work (content development, ideally, but that could also include customer support). And although it’s different from when I started as a tech writer, it seems like the working manager is now the norm.

Continue reading “The diversification, not death, of technical writing”

Advertisements

Documenting for a lack of patience

I’m writing this in a theater that’s filling up with people. I’m here for my youngest daughter’s dance recital. She’s dancing in two groups, both at the very end of the first act. I’ve got a long time to wait.

Continue reading “Documenting for a lack of patience”

What users are looking for (hint: FAQs)

I spent last week researching support and learning management systems, working on a documentation delivery schedule for the rest of the year, and responding to a few complex support cases.

Those support cases, along with some comments from other users, have made me rethink my opinion of FAQs. Maybe it’s more accurate to say that this feedback is pushing me in a direction that I’ve been trying to avoid, while I knew that I was fighting the inevitable.

Continue reading “What users are looking for (hint: FAQs)”

Why you shouldn’t do it all

Responding to my post about startups vs. large companies, Anindita Basu asked, “I am curious why you don’t recommend stepping up and taking on as many things as we can (when in a small company).”

Not too long ago, I would have replied that it’s exactly what you should do. I would have explained that it’s important to try to do as much as possible because that’s how you establish and maintain your relevance and authority in your company.

But that’s the wrong answer. Doing that will lead to burnout, frustration, and disappointment. Let me explain…

Continue reading “Why you shouldn’t do it all”

Responding to Craft vs. Commodity

Connie Giordano has an interesting take (and a reader poll) on technical writing as a craft vs. a commodity. She’s writing something of a rebuttal to my post about the same topic. When I checked before posting this, the results were tilting towards “Tech writing is a hybrid profession,” slightly ahead of “Heck yes we’re craftspeople!” I voted for “hybrid” even though I’m not entirely sure what that means. But I think it’s closer to my argument.
Continue reading “Responding to Craft vs. Commodity”

I wrote a guest post for MindTouch

While I was at the Write the Docs conference, I ran into some of the MindTouch product team, one of whom I’ve worked with before (and on a personal level, I like the team; they’re really friendly people). This led to an opportunity to write a guest post for the MindTouch blog, which I very eagerly agreed to.

I worked with MindTouch’s Content Strategist (and that comment about “funny new titles” comes back to bite me…again!), who suggested a very interesting topic: “what businesses / management should be doing to help their techcomm writers deliver more value to customers.” I took that idea and ran with it: 8 Ways Management can help Techcomm Writers Deliver Customer Value.

Structured writing = commodified writing

While researching doc tool and process options, I’ve been interested in developments in DITA, especially a call for simplified DITA. I’m just surprised that it’s taken this long to get started. But I’ve seen at least one DITA expert say that simplified DITA is good for engineers and other transient contributors. Again, people are stuck in the mindset that only professional technical writers can write “correctly,” and we’re doing everyone a favor by allowing them a peak into our walled garden.

But here’s the thing about DITA, and structured writing in general: It commodifies technical writing. And while that might not be a bad thing, we have to acknowledge that if we go to a fully-structured writing world, one of the consequences is that we turn tech writing into a commodified skill, making it easier for everyone to write acceptable documentation.

Continue reading “Structured writing = commodified writing”