Transitioning from Technical Writer to Business Analyst


With evolving economic and technological needs, career moves are practically universal in today's job market. Some of these career moves are actually leaps, such as an accountant transitioning to become a nurse, but others are much closer jumps, such a technical writer or documentation specialist moving into the often similar business analyst's role. Indeed, in smaller organizations (or larger organizations eyeing their bottom line) one person may handle both the business analysis and technical writing roles since the required skills often overlap so smoothly.

Even if you are perfectly content in a current technical writing role, most of us can benefit from at least considering other organizational roles and making ourselves marketable for more than one position. Additionally, in many companies, a business analyst position is in a higher salary range than that of a technical writer, making the transition financially appealing.

If you are a technical writer wondering what you might have in common with a business analyst, consider these commonly shared skills and character traits:

  • Both roles require diligence in tracking down subject matter experts and locating existing research. Like you, a business analyst must likely develop a roster of experts that he routinely turns to in order to accurately document his work.

  • Both roles require strong interviewing and listening skills. A business analyst also has to ferret out details, continually ask "Why?", and read between the lines to discover what they can't afford to miss.

  • Both roles strongly benefit from close familiarity with the inner-workings of an organization's products or services.Like you, a business analyst has to know every possible occurrence of a product or service (and know how to document those occurrences in clear and understandable ways).

  • Both roles require the ability to write clearly and precisely, including the ability to describe products or functions graphically (such as diagrams, tables, charts, etc.). Indeed, your step-by-step help manual probably requires much of the same creative thinking as a business analyst's use case diagram.

  • Both roles must actively solicit reviews and feedback for their work. Both also require the ability to evaluate and integrate that feedback as appropriate, and to keep detailed records of what changes were made and why.

  • Like you, business analysts are sticklers for details. Methodical thinking through every aspect of a company's business is also part and parcel of a business analyst's work. Whether a writer is creating a how-to manual, help copy, or requirements, she has to pay close attention to all of the steps and features of the service or product and their potential interactions with other services or products, including the lesser-known ones. 

Despite these similarities, becoming a business analyst may not be the right choice for every technical writer. The role of a business analyst requires effective oral presentation skills and no small amount of diplomacy. If the following are a natural part of your work persona, you will want to do some careful consideration before applying for a business analyst's position:

  1. You enjoy working alone most of the time, spending most of your day reading, writing, and editing. Throughout a project, business analysts continually interact with stakeholders, project managers, developers, and even training and customer care.

  2. You do not enjoy oral presentations, or explaining concepts to larger groups. Requirements are normally presented to all stakeholders in meetings, and the analyst must be prepared to explain and defend them.

  3. You do not want to host multiple meetings to facilitate a project from scope to conclusion. Depending on the company, meetings to define scope, business reviews, usability reviews, and technical reviews are all part and parcel of an analyst's work.

  4. The thought of working to resolve conflicts between stakeholders sounds disagreeable you. Almost no business analyst enjoys resolving conflicts when stakeholders offer contradictory wish lists for inclusion in a requirements document, but such conflicts are often a regular part of the requirements cycle, so one must at least be amenable to addressing them.

If you're still wondering whether a business analysis position may be a good fit for you, the answers to these three questions may reveal the answer:

(1) Would I enjoy business analysis work?

If you enjoy technical writing, the chances are pretty good that you have the temperament to enjoy business analysis. But one easy way to find out is to volunteer for a small business analysis project within your project management division. (Most analysis groups are overloaded and would be glad for the help.) Go through the entire process of discovery, writing your requirements documentation, soliciting feedback, and getting final approval. Not only will this reveal whether you have an affinity for business analysis, but if you decide to pursue it as a career, it will give you some experience for your resume. Of course, before you can "try on" the role of the business analyst, you may need a bit of training.

(2) Where will I find the proper training and resources to make such a career transition?

You don't need a degree in business analysis. (I know business analysts with degrees ranging from accounting to English literature.) And although it will help, you don't need a college course to get started. You will, however, need to familiarize yourself with industry terminology, the process of requirements discovery, and the standard templates for requirements documentation. One industry-acknowledged resource is BABOK 2.0, available here. Although your organization may use slightly different terminology or processes than those described in BABOK 2.0, the basics will serve you well.

(3) Can I become a business analyst in my current industry?

Industry familiarity helps when you enter any job, but particularly so in the role of business analysis, where details are king. If you can make the move to analyst in the industry you're already trained in, you're ahead of the game.

If the answers to these questions whet your appetite for business analysis, naturally your next question is going to be, "As a technical writer, how do I market myself as a candidate for business analysis when experienced business analysts may be competing for the same position?" Three ways: (1) If you're not already doing so, attend your organization's requirements reviews. Pay close attention to the style of your organization's requirements as well as the requirements process. Note what you could bring to the table that might enhance what is in place, and be prepared to highlight that in an interview. For example, "I've noticed that the discovery stage is sometimes rushed because of our current production schedule. I bring five years of experience of painstakingly documenting our services, and I don't need a long discovery process." An outside business analyst candidate is not likely to offer that. (2) Volunteer for smaller analyst projects to gain experience with discovery and writing requirements. (3) Highlight your transferable skills to the analyst position (listed at the beginning of this article) on your resume and in your interview.

Most of my business analysts colleagues and I began our careers as technical writers. We each benefited from our technical writing stints because they afforded us deep, necessary knowledge of our organization's services. Also, in our technical writing research, we each read numerous requirements documents to help us understand the services we were documenting. Most writers learn to write by reading, so by the time we became analysts, writing requirements was almost second nature. If you decide the move to business analyst is one that is right for you, take advantage of every opportunity in your current role to prepare yourself for what may lie ahead. As far as job transitions go, you're likely to find this one a natural.

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at

Like this article:
  29 members liked this article


Tony Markos posted on Wednesday, September 30, 2009 10:15 AM

I have significant experience both as a Tech Writer and as a BA. Here is some additional info related to your article.

Tech Writers have there own "version" of Business Analysis. It is called End-User Task Analysis (for further info, refer to the the classic book on the subject by JoAnn Hackos). The primary difference between Task Analysis and Business Analysis is that Task Analysis is done in a very bottom-up fashion, whereas, Business Analysis is done in as top-down a fashion as possible. Therein lies a very important consideration for a Tech Writer considering making a transition: Willingness to work to a higher level of abstraction (i.e., proceed in a top down fashion).

There is safety in being grounded in the implementation details (i.e., working bottom-up). Most Tech Writers are not comfortable working to higher levels of abstraction (actually, neither are alot of BA's).

Especially, in the age of Agile analysis, the time required for a bottom-up analysis is a luxury that many projects can not afford.

Tony Markos
Ritika posted on Tuesday, March 16, 2010 6:39 AM

You explained the shift from being a technical writer to becoming a BA very well.

However, as an entry level BA I wanted to ask, how beneficial do you think it would be for a BA to do a Technical Writer's certification?

Technical Writer's certification is something I have looked forward to doing. But before I invest in it, I want to understand the benefits.

Also can you advice on some recognized certifications for the same?

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC