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”
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”
A question that comes up regularly on Linked in forums is “What are the most important skills for a technical communicator to have?” I used to have a quick answer for that, but I realize it was based on how I learned to technical writing. But now many people in techcomm won’t be using a complex desktop publishing program to write manuals designed for print. They won’t be relying on the work of editors, illustrators, and a production team.
Continue reading “Quick thoughts on useful skills for technical communicators”
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”
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”
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”
In my last post, I suggested a few reasons why technical writing is dying. And it is, at least as a career with a single focus on writing documentation for end users.
What’s happening, and what do we need to do?
Continue reading “The death of technical writing, part 2”
For a few years now, I’ve been worrying about the future of technical communication as a career. Not that user docs will disappear (as much as most people might want that), but techcomm as a unique job title, as opposed to one of many tasks that someone might have. I remember hearing Noz Urbina telling us that we were doomed, back at Lavacon 2012. And I attended a few webinars at that time that were also very negative about future prospects.
They’re right: We’re doomed. Pack up your pens and find another use for that English degree.
Continue reading “The death of technical writing, part 1”
I usually work in a tactical writing mode: documenting new features and workflows in an agile development environment, or writing special content for training or specific customer requirements. I’m very comfortable working at a tactical level. But in the iron triangle of fast/cheap/good (where you can pick any two), going for fast/good incurs a cost that’s very easy to miss for a while: losing sight of the strategic goals…or failing to create them at all.
Continue reading “Fast. Good. Cheap?”
Everyone who uses tools for a living loves their tools. And has strong opinions about them. Most programmers are happy to talk about their favorite coding languages and development tools, for example. For tech writers, we get to argue about content management systems, authoring tools, authoring formats, documentation structure…And that’s after we’ve battled over grammar, font choice, and glossary terms. Seriously: Glossary battles are the worst.
Now I find myself needing to change my writing process, and probably adding a tool or two to my workflow. Oh joy.
Continue reading “In search of the perfect (or perfectly adequate) writing tool”