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.
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.
My boss keeps telling me that the great thing about startups is that everyone wants to do everything. And the worst thing about startups is that everyone tries to do everything.
I should have listened more closely. Heroic efforts are good sometimes. But you can’t base realist plans on that. If you do, it’ll bite you in the ass. That’s what happened to me.
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…
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.
After the great response to my previous post, I should probably write another post about something else that tech writers are doing wrong. And although there is a part of me that would love to write a purely contrarian article for the hell of it (“Structured writing: Threat or menace?”), the responses to my post were so intelligent and reasonable that I need to focus on positive contributions.
In D&D and related role-playing games (Dungeons and Dragons, and yes, I’m going full geek), the Bard character class gains a ton of skills: They’re a bit fighter, a bit thief (or rogue, if you prefer), and also have a bit of magical ability.
The point is: They’re flexible. They’ll never hit as hard as a fighter, aren’t as sneaky as a thief, and won’t cast as many spells as a wizard. But because they don’t specialize, they’re useful in many situations, and they’re often an asset to adventuring parties.
Lots of skills, very versatile, an asset to their team…just like technical writers!
Ok, I sense your doubt. Let me explain.