Tell me about your career as a technical writer...

by Tom Johnson on Nov 4, 2015
categories: beginners

• Can you describe a day in the life of a Technical Writer?
• Do you primarily work alone, or is collaboration a big part of your job?
• What skills does one need to be successful at Technical Writing?
• What do you think it means to be successful in the Technical Writing field?
• I read on your website that you were an English major. Is there anything that you learned from a liberal arts- based curriculum that connected with your career goals as a technical writer?

A reader asks a few questions:

Can you describe a day in the life of a Technical Writer?

Sure, here is my typical day:

• Take kids to school, then ride bike to work (just 3 miles from home, hooray!).
• Check latest activity on JIRA, Confluence, email (a remote team in Sri Lanka works in an opposite time zone, so there’s sometimes lots of activity during the night).
• Load up several items of work. I’m trying out a technique called “kanban.” You limit the number of work items on your plate to a set number of cards, which I have displayed as Post-it notes taped at the bottom of my computer monitor.
• Attend Tech Docs standup, Project 1 standup, and Project 2 standup (standups are supposed to be short, but they often last 30 minutes as people get to sharing info about various issues).
• Update docs with info about the new features for upcoming releases. As much as possible, I prefer to stay immersed in same project. There are lots of details to keep straight in help docs. Context-switching between projects on a daily basis is unproductive, in my opinion. But you have to do it.
• Coordinate with team members about our authoring and publishing process. One team member says the TOC is not changing with the build commands. I start to troubleshoot but then he figures it out anyway.
• While working on a project, I see a jekyll-metadata file in my root directory, which creates a merge conflict with the content I just pulled. What’s this new metadata file? I turn to google, and then see that it’s part of the latest release. I add the file to an ignore list in Mercurial.
• I eat lunch with former colleague; we talk about content reuse strategies and projects and life. He tells me stories about a year of extremes. He has had unbelievable success as a Flare consultant.
• After lunch, I test out the latest code from dev to see if it actually works. While testing things out, I talk to QA people about Tomcat servers and when or if they need to be restarted with our deployment process.
• In testing out payload contents, I discover our internal testing tool is broken, but there’s no note or warning. A developer explains a cumbersome workaround.
• I realize that one of our reference implementations is not going to meet the needs of the audience. I start a discussion that leads to an email thread with the product manager, customer experience manager, and other stakeholders. It remains unresolved, so I can’t finish this part of the doc.
• I decide to simplify the doc for one of my projects. I have too many variables going on and it’s just getting confusing. I have conditionalized and single sourced this content too much, and now it’s practically uneditable.
• Little by little I realize that the developers have coded some stuff that I hadn’t identified in the upcoming release. I look in JIRA to see if the changes were noted or mandated somewhere, or if the developers just made them autonomously and silently. I assume the latter. Those darn developers…
• I reply to a couple of Twitter conversations and IMs with my wife about kids to pick up.
• I ride home and help with dinner (mostly standing in the kitchen and trying to help but not really). I tell the kids to do their homework.
• Sitting on my butt all day makes me eager for exercise. Later in the evening I ride to a nearby gym and play basketball with a group of friends. On the ride there and back I listen to the American Assassin by Vince Flynn. In the book, a banker decides to open a safe containing passwords to Swiss bank accounts containing terrorist funds rather than have Mitch Rapp (unofficial CIA assassin) pluck his dog’s eyes out with a knife. My lackluster day job requires this kind of vicarious adrenaline!

Do you primarily work alone, or is collaboration a big part of your job?

I work alone in an open office surrounded by people (kind of like a loner in a sea of people). I’m the only tech writer on site (for a group of 30 IT people), but there are two other tech writers in Arizona, and we’re hiring some more technical writers in the UK.

We meet and interact regularly through IM, Go to Meeting, Confluence, JIRA, and email. The virtual team actually works out quite well.

What skills does one need to be successful at Technical Writing?

You need to be technical and a problem solver. Here’s a test. When you can’t figure something out or when something breaks, what do you do? Does it gnaw on your mind until you figure it out? That’s a good trait to have as a technical writer.

It also helps to be meticulous in creating instructions. A good technical writer reduces the word count to just the right brevity without being obscure.

In deciding on a technical writing career, you also might ask, do you enjoy writing? I’m now not sure the answer has any bearing on the field. Most technical writers don’t seem to write other than during their day jobs. A few write novels on the side, some write blogs, but the majority are too busy, and they’re tired of writing after working in front of a computer all day.

Thus, if you enjoy writing, working as a technical writer all day might zap your creative energy. Or it might give you just enough writing to be fulfilling without being completely demanding. My career does seem to give me a lot of fodder for my blog.

What do you think it means to be successful in the Technical Writing field?

Success means you’re earning a living, meeting deadlines, providing fully documented code with each release, getting funding and headcount to grow your team, etc. Your users don’t complain too much, and you’re able to unplug at 6pm. Okay, this is a somewhat evasive answer. I really don’t know.

Maybe success is empowering your users to be “awesome” through the instructional materials you create? (Except you rarely get to see or hear from those users, so there’s a real disconnect in terms of feeling satisfaction in helping people learn.)

Another definition of success would be to increase adoption of your software product tenfold by enabling users to quickly learn it and move up to the power-user level. As your product becomes wildly successful, your company gets major venture capital funding, goes public, offers you a serious cut of the shares, and you cash out in 10 years and are able to make a down payment on a 1 bedroom home in East Palo Alto or Gilroy. (Inside joke for those living in the Bay area …)

I read on your website that you were an English major. Is there anything that you learned from a liberal arts- based curriculum that connected with your career goals as a technical writer?

I’m not sure. I majored in English and got a masters in Creative Nonfiction Writing. At some point I learned to be technical. I think I learned to be technical through my side work as a WordPress consultant building websites.

I do love to write and always have, even in high school (I kept a regular journal since 9th grade). I guess my college experience taught me to love to write, and taught me how to write (academic essays, thoughtful/analytic pieces, reports, etc).

But my experience working as a technical writer taught me to shape that writing into more instructional material (with subheadings, lists, screenshots, visual media, etc.)

That said, what you learn in any field could probably translate into some helpful skill as a technical writer.

Some parting thoughts. As you move forward in your technical writing career, keep these nuggets of wisdom in mind: Learn continuously, test everything, be skeptical of anything anyone tells you, triple check your instructions, don’t take anything too seriously, blog regularly about your experiences or thoughts, sell your car and ride a bike everywhere, listen attentively to people, and try not to stay up too late at night.

About Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.