Almost 17 years ago, I had my last annual review at my first job as a technical writer. My manager was on maternity leave, and months of bad news about the company (caused by illegal financial manipulation) led to poor morale and attrition. But this post isn’t about that.
Continue reading “How I finally understood and overcame “You’re not good enough!””
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.
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?”
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”
I’ve been at my current company for a year and a half, and my role is a mix of technical communications and customer support (which is really technical communication with a specific person instead of a group of current customers and prospective customers).
As my company is growing and taking on more customers, I need to build a team. I’m figuring out what that team will look like, and what sort of skills and personalities I need to fill those roles.
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…
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…”
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.
