A Technical Writer with Extra Privileges? Responding to a Question about Roles (Videocast)

Download in iPod format

Jim from Iowa writes:

I was doing some career research involving technical writing and stumbled upon your website.  I had a question about that sort of thing, and you seem like a good person to ask. To be frank, I have two main interests–writing and technology.  I love to read and write, but I also love engineering, working with computers, etc.  So, I guess at this point, one would say technical writing is the logical career choice.  Yeah … but I’m not sure if that would satisfy my tech cravings.  I realize you’ve mentioned things along this line in your previous posts.  But let me explain a little further ….

Let’s say I get schooling in engineering and, say, English.  Would I be able to be a technical writer who also had some extra privileges?  And by that I mean helping with the design process, helping with whatever problem is trying to be solved or whatever item is trying to be created, etc.  What do you think?

Thanks for submitting your question, Jim. I responded in a videocast below.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

12 thoughts on “A Technical Writer with Extra Privileges? Responding to a Question about Roles (Videocast)

  1. Writer Zero

    I’d like to add…

    Yes, often times the TW is responsible for content management and distribution tasks. The more complex the documentation, the more automated (see: executed as a computer program) the workflow must be. A lot of TWers have moved in this direction.

    Tom’s right, I have never seen a hired-as-tech-writer responsible for coding tasks (apart from content management needs).

    As far as getting the right job, the larger the company or project, the more compartmentalized your job will be. Smaller companies will probably give you more latitude in defining your role and tasks.

    Finally, if you can find a job where the product you document is meant for use by engineers, then that might satisfy you. For instance, some tech writers create content like this:


    This is what I live for! :)

  2. Tom

    Writer Zero, thanks for adding your comments here. I agree that someone who has a bent for engineering and writing may be better suited for heavier tech writing like the example you mentioned. There’s definitely a whole field of API and SDK technical writers out there. Jim — walk into any bookstore and browse the computer books section — lots of books written just for developers.

    Also, Writer Zero makes a good point about company size. At small companies, you may be the copywriter, marketer, web designer, technical writer, trainer, and support staff. At large companies, you may be designated as the content manager for documentation only, and not even write content.

  3. Dave Johnson

    I like the videocast format, but you might want to consider facial makeup, and think about how hand gestures might be distracting, especially when they are magnified by being closer to the camera.

  4. Robert Nagle

    Writing is a secondary skill, not a primary skill. It’s an excellent addition to someone who is primarily an engineer. Writing proposals, doing presentations, technical requirements, posting on newsgroups, etc.

    As a technical writer, I am used to having technology thrust upon me (including the toolchain). For example, in my latest gig, I recommended DITA, and my company said no, we’re using their own in-house toolchain. Oh, well.

    Technical writers are interviewers, researchers, organizers and information gatherers. They don’t really do too much innovation on their own.

    Another thought. It’s easier to get technical training and later drift towards technical writing than vice versa.

    One common thread to both is understanding users/basic design principles/understanding project management.

  5. V. Smith

    Good points.

    Robert Nagle stated: Technical writers are interviewers, researchers, organizers and information gatherers. They don’t really do too much innovation on their own.

    I would disagree. Innovation comes to Senior Technical Writers, Document Managers and the like via Content Management, Document Management, Usability aspects and development of writing standards.

    It is advisable that you know the tools and products of the trade. You can and will influence projects as opportunities present themselves. I am technical and have no desire to program; however, I have the respect of the developers, because I can help them solve technical problems. This works two fold in that when I work a project and need additional information they are will to provide and in fact, may seek my counsel.

  6. Jason C

    As someone whose career path has followed much of what “Jim from Iowa” is asking about, I’d like to add my experience to the conversation. But, I should be clear that my perspective is from that of a traditional engineer (i.e. – mechanical, civil, electrical, etc. engineering). That is, not what is often referred to as a “software engineer” (who was called a programmer in the engineering department, now also called a coder or developer). I don’t mean to disparage either role, just to mention that the term engineer gets used rather loosely and it is worth being specific. Jim doesn’t really say what kind of engineering he is interested in (and he may well not yet know).

    I have two degrees in structural engineering and practiced professionally for six years before getting into the field of technical writing. I had the good fortune of being able join a company looking for an experienced user of their software to help with their documentation as well as user communications. I now have a wonderfully rewarding job in which my loves of engineering, writing, web technology, and engineering software are all put to good use, professionally.

    If Jim is indeed interested in working with “traditional” engineering software, then I would suggest studying that profession in college. He will learn programming and some technical writing along the way while gaining the technical fundamentals in a highly specialized field. But it takes a large time commitment to gain that level of skill specialization (15 years in my case; and one could argue that is still a bit shallow for real expertise in the field of engineering). And though that may sound a bit daunting to someone considering what to study in college, I would be remiss if I didn’t also state that the education and career in engineering is very rewarding in of itself. I wasn’t waiting around during all that time hopign to finally reach a goal (it never really occuring to me then I might do this for a living, quite frankly). It was time well spent.

    However, this isn’t to underestimate the importance of learning language skills. In fact, communication is the most important skill an engineer can have. After all, what good is a solution if it cannot be expressed to others for implementation? An engineer who can effectively communicate in both the written and spoken form is highly valuable – no matter where they work.

    Lastly, as to the question of where to work. I actually work for a relatively large software company, though in a fairly small division. I’m allowed a great deal of liberty in how to approach my role. Also, as a former user of the software I now write documentation for, my input is often requested on usability, interface design, workflow, etc. Obviously, it isn’t always followed but I do feel that I am able to contribute to areas of the product outside of writing which Jim asked about. Though the advice by Writer Zero on company size is mostly true, I’d add that focusing on finding somewhere you can help add value by using your talents is really what to focus on. If you feel strongly about product usability then look for a place to work that wants to talk to you about that. Or, perhaps if an interview focuses solely on reviewing your writing examples or your RoboHelp skills – and they don’t even want to discuss what you might be able to add in the way of features or APIs – then you might want to keep looking (It sounds like Jim has a while before he reaches that point, so I don’t feel quite as silly giving that kind of advice in the current economy.). I was fortunate in that I found a place where all things I’d love to try doing (video screencasts, creating and managing wikis, multimedia help systems, and more) seem to be just what they wanted someone to do for them.

    So best of luck in finding a path that is right for you, Jim.

  7. Jim

    Thanks a lot for the help! Most people wouldn’t take the time to answer this thoughtfully.

    I like the idea of being able to gather data on user feedback. That’s pretty cool. And I get a sense from this that technical writers are often doing more than their title implies. V. Smith, you’re lucky to have such an influential role where you work. If I decide to enter into this field, hopefully I’ll gain that sort of responsiblity.

  8. Bruce Curley

    If you study the history of technical writing, years ago, ALL technical writer’s were engineers.
    However, it turned out that many engineers, although technically adept, were not great writers. Therefore, companies began to hire writers to convert the technical language of engineers into plain English so technicians and customers could understand it. Also, technical writers usually were paid less than engineers.
    That said, an engineering degree and technical writing degree are an excellent foundation for both careers.
    Or, take a technical writing class along with your engineering courses.
    When my son was getting his mechanical engineering degree at the Clark Engineering School at the University of Maryland, the school required him to take a technical writing class. He was not happy about it then, but he is now doing sound and vibration engineering and prepares many proposals and studies.
    I explained to him at the time that the best engineers (and most successful) I had met over the years were also good writers.
    Why? Because all that engineering knowledge is usually lost if the engineer cannot communicate it to his boss, his co-workers, his workers, and his internal and external customers. For example, study Google for a company that knows how to get its engineers to communicate.
    Guess which class he uses the most each day? Yes, what he learned in the technical writing class.
    If you get both an engineering and technical writing degree, you will be a great hiring prospect.

  9. Robert Nagle

    V Smith,

    I’d like to respond to your point about innovations. My experience may not be typical. And I think that innovation takes many forms, not just technical. Creativity and resourcefulness is certainly part of the job description.

    But would a company pay a writer to produce a new tool (even if it doubles or triples the total time to produce the manual)?

    Would a technically-minded company listen to its programmers or its technical writers about how help is implemented? I’ve had multiple opportunities to make recommendations, and 9/10 of the time, my recommendations are carefully considered…and then ignored. In a job from a few years ago, I presented a way to migrate from Winhelp. My boss (the director of Technical Pubs) backed it, and even the techies understood the value of my suggestion, they just regarded it as a lower priority than other software improvements. A lot of times, this had to do with end-of-life plans for a platform; i.e., why bother continuing to build ontop of this platform when the company wishes to migrate away from it; or the converse: why adopt a new technology when the existing platform is “good enough” and “predictable” with regard to change management.

    Sure, job situations differ and some management teams have more incentive to change. But my experience has been that software teams don’t expect or accomodate innovation from technical writers. Sure, they listen (and I don’t feel ignored, despite my occasional sense of frustration). And if something you propose provides a low-hanging-fruit benefit, the team will probably say, go for it! (as long as you don’t fall behind on the project schedule). But I haven’t seen much innovation coming from the documentation team; plus, I think the “political influence” of technical writers in agenda setting is fairly weak.

  10. Ben

    Hi Tom,

    Just wanted to comment a bit on the format of this post. I like it, and I think it’s a very personal way of responding to Jim’s question.

    The only suggestion I have is to either not read the letter in the video or not post it. I read the letter and then listened to you read it back to me, which was a little redundant. :)

    Great idea–keep trying different things. That’s another way that blogging helps with your creativity.

  11. Bob

    I appreciate your podcast since I am enrolled in a Tech Writing Certificate program at Vancouver Community College, and have chosen to write one of my papers on the role of the TW beyond being a proofreader. Your podcast really shows the different dimensions and gives future needs of tech communicators better than some of the academic papers I’ve read. I’m focussing on the changes of writers over time, and especially appreciated the comments on the need to get involved in teamwork early, and to insert yourself into project plans in such a way where you can make a difference, exert influence, no matter how small, without pretending to be an expert in the product development or design fields.
    Your podcast needs to be heard by other students, as well as rookie writers! Thank you.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>