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”

Advertisements

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”

You should work for a (small||large) company because…

When I was talking to people at the Write the Docs conference, I had a couple of interesting conversations with people who were weighing the costs and benefits of moving from a large company to a small startup. I prefer working for smaller companies, but I’ve been through this decision process a few times, and I’ve seen the good and bad of both large and small companies.

I can’t tell you much about being a contractor, though. I’ve only dabbled in it, and all I can tell you is that it made my tax returns slightly more confusing.

Continue reading “You should work for a (small||large) company because…”

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”

The death of technical writing, part 1

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”

Fast. Good. Cheap?

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?”

A few ideas and one scandalous revelation

My last post was number 25 (sorry about missing a week). That means that I’ve been posting for 6 months (I missed a week). My goal is to reach 100 posts and then…well, I’m not sure. If my posts by then are “let’s look at the things on my desk and make them metaphors for technical writing,” then I’ll pack it in. But now that I’ve hit a round and arbitrary number, I’m going to write down some ideas and plans. And I’ll reveal Shocking News!

Continue reading “A few ideas and one scandalous revelation”

In search of the perfect (or perfectly adequate) writing tool

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”

What did I expect to get from conferences?

I really like Tom Johnson’s recent interview with Pawel Kowaluk, who is organizing a techcomm conference in Poland. After a much appreciated compliment, he explains that he’s trying to include topics that show how techcomm is a vital component of a company’s business practices, and not an afterthought, a bolted-on requirement that gets included because it’s just how things are done.

Which is what I’ve been trying to get to, and why I keep wandering around the point of why I think techcomm is important. And also why I’ve been frustrated when conferences become advertisements for tools or specific processes, without really explaining how we make the business case for our existence.

Continue reading “What did I expect to get from conferences?”